I'm working on NopCommerce 2.60 and I have extended Affiliate Module in NopCommerce 2.6 by adding two new fields like "WebsiteURL" and "Picture Upload".
For that I have made changes in Affiliate Services, Affiliate Controller, Affiliate.cs, Affiliate Map, Affiliate Model files. Now If I want to integrate these changes in upcoming versions of NopCommerce.
So What is better way to make changes in NopCommerce code and easily integrate in upcoming versions of NopCommerce?
There is no any way in nopcommerce to upgrade custom functionality in higher version. instead of that i would suggest right you function independent to nop means write separate classes for all Affiliate functionality, copy it in next version as you see in nopcommerce2.65 they have change some service, properties name.
I have recently looked into this since our company wanted to make sure nopCommerce could be upgraded at later dates if needed. The best solution we found was to make our modifications into plugins so that we could refrain from modifying the core as much as possible. Like Shivkumar said, it's not really possible to make nopCommerce upgrade proof.
Hope this helps.
Related
The current latest Joomla! v3.9.14 (August 2019)
The integrated tinymce is v4.5.11
Tinymce released the new V.5.0.0 in February 2019, including major improvements and a great new API
I want to use a plugin written with the new V5 API in Joomla!, so I wondered if it's possible to upgrade Tinymce to V5 in Joomla, or if we have no choice but to still use the old ugly Tinymce v4.x?
I tried to replace/edit files in media/editors/tinymce, just to see if it could lead to something, but of course it doesn't seem to be the right direction.
Rather than replacing the files (which could be overwritten in any future update), you're probably better off writing a new plugin for Joomla that installs Tiny 5.
The source code for the (v4) TinyMCE plugin is a good place to start to write your own - replicate how this plugin works, and you'll need to extend its functionality.
Doing it this way also means you could choose to use the Cloud version of Tiny, meaning you don't need to host the files locally, and receive updates as Tiny push them live. You do need a Tiny API key for this, but IMO, I feel it is a smarter way to host Tiny given that even during 5's life in 2019, some really useful features have been deployed, and if you're hosting all the files yourself, you'll need to keep updating them as you go.
The challenge with writing your own Tiny 5 Joomla plugin is that the core TinyMCE plugin for Joomla does not make it possible to have externally hosted Tiny plugins (such as a custom one you've created). So you would need to extend both the configuration and the instantiation to be able to store external plugin configuration, pull it in to Tiny's config, and also be able to manage your toolbars.
At Joomla Day Australia 2019 I spoke about developing external plugins for Tiny 5 in Joomla 4, and have a plugin that uses the cloud version of Tiny, and allows for external plugin configuration - but this was for an alpha version of Joomla 4.
Joomla 4 will come with Tiny 5, and I did a pull request to get external plugins in to the Editor config, so just waiting for Joomla 4 could be a more passive option.
I need to have several textfields (may be articles, but not neccessarily) on a page, that is easily edited from frontend for registered users.
How do I best achieve this?
It is for Joomla 3.1
You can go several ways:
Use a cck: this is the easiest, no coding required, browse the JED for Sobi, K2, Zoo, Content builder...
Write a simple component: using componentbuilder or the like it won't take long and you'll only need to write very little code if this is the only requirement.
Upgrade to J3.2 and use the bundled FOF (by akeeba, introduced in Joomla core as of 3.2); Joomla! 3.2 will be available in 3 days, but you can already download the beta. With FOF you can achieve much the same as 2. by writing a simple xml file.
Depending on what you plan to do with this data, and your coding skills, the right answer may be any of the above.
I am not even sure how to ask this question. I am absolutely willing to research this myself, but I don't even know what exactly my options are.
I'm fairly new to programming in general, and I'm the sole developer on an ASP.NET MVC3 web application. We're about to upgrade to a new version which has a lot of addition to the data model. There are a couple new entities and some of the old entities have new properties/columns.
We've finished beta testing and now we're going to try to get everyone moved over to the new version running parallel to the current version, that way if there are show-stopping problems, users can easily switch back to the old version. The problem is that we can't hook both up to the same db because of the data model differences.
Can I make the old version use the new version's schema or something? I'm not really sure what my options are. I'm not asking you to write this for me; I'm just looking for some direction. Thanks!
You should be able to disable the metadata checks and then use two versions against the DB assuming the models use a schema that is compatible between both.
http://revweblog.wordpress.com/2011/05/16/ef-4-1-code-first-disable-checking-for-edmmetadata-table/
Another option is to use entity framework 4.3 code first migrations and actually use an upgrade script that it will generate for you. If it fails you can roll back the script to a prior version and use your prior code base. This would imply you upgrade to 4.3 first before doing anything else though although you could still disable metadata checks.
I am pretty new to Virtuemart and now I do have to set up my first Webshop for a Customer.
As there is already a Virtuemart 2 Version I am now not shure which Version to take.
Well I think I am going to use VM1, because it is stable. But now I am asking myself:
What are the advantages/features of VM2?
Are there already Plugins out there for VM2? (Because I assume that
they'll need to be rewritten for VM2)
When can I expect a stable version of VM2?
Do you already have experience with VM2?
Advantages/features of VM2
For faster and more secure programming they use now more abstract classes.
Completly redesigned table layout.
Added hooks for plugins (own views, own customer number system, and so on,...), look in the wiki for more information ( http://dev.virtuemart.net/projects/virtuemart/wiki/Plugin_system )
Added registering while checkout
New backend design
Hardened against hackers
New js (jQuery to avoid Mootools incompatibility problems)
Customfields for the computer/pizza configurator
Real multicurrency, real currency format defined by currency
Prices displaying configurable by shoppergroups (also rounding)
Various sorting and searching options
Update system using Akeeba Release System (ARS, more information akeebabackup.com/software/akeeba-release-system.html)
Extensions for VM2
The extensions directory contain a lot of extensions for VM and some were updated for VM2 ( http://extensions.joomla.org/extensions/extension-specific/virtuemart-extensions )
Stable version of VM2
There is no clear data about this now. The current version at the moment is a release candidate which means a sable version is coming soon after sufficient users and developers test it and report the bugs.
Experience with VM2
I've used VM1 and migrated two websites for VM2 before. VM2 definitely worth the try, templates is way much better than the old table based ugly coded layout. Everything is perfect except if you are going to use Joomla 1.6 The modules does not work without glitches. Other that it's working with Joomla 1.5 perfectly.
Try Virtuemart 2 only if you are not planning to use any custom shipping module like canada post or UPS.
Or have enough knowledge to build it on your own.
VM2 performs shipping and payment system using plugin and trying hard to follow MVC structure of joomla.which is still under development.
Unless, VM2 is great and flexible.
i want to port my application to CodeIgniter but i am wondering whether i should use their v2.0 or v1.72 (then when they release 2.0, upgrade it).
i have never used a framework before so i don't exactly know what implies when upgrading a framework: what does it mean practically - i just move the folders and it will work? or do i have to change a lot of settings, file structure etc? could someone enlighten me about the upgrade process.
and what would you use: v.1.72 or v2.0?
if i'm using the latest version, is there a good documentation for it somewhere so you can read about how to use the new features: packages, drivers and so on.
thanks
You can read about some of the changes in 2.0 here.
I would image the upgrade process should be straightforward as long as you do not use any features that are different/removed such as plugins. Just take your models, controllers, etc and drop them into the 2.0 framework. Then regression test you whole app, fixing any problems as you see them...
If you are selling this app or making something mission critical then of course v1.7.2 is the best choice. That said I have PyroCMS running on v2.0 and since some of my bug-fixes were merged it seems stable enough.
One should consider time frames for deployment:
If it is one week, then stick to v1.7.2
If it is three months, go with v2
Assuming three months is approximately to time for a release to stabilise?