Very few projects that we have ever worked on have not required some form of modification or customisation. It is very much the case that customisation is what we spend our days doing.
It may be that a client wants to slightly adapt the way product information is viewed by shoppers - or it could be that the site needs to be integrated into another system. Or maybe a whole new social media community element needs to be added.
But whatever the need is, nearly every site has some form of customisation.
So the question of how easy a framework is to modify becomes very relevant for several reasons.
If a framework is difficult to modify, then the cost of the modification increases. And further, at the point when a new version of the framework is released, applying the modification to the new version is also more costly. In practice, this often leads to clients failing to update the framework because the cost of modifying the new version to incorporate the changes made to the previous one is not insubstantial. This means that vital changes such as new framework functionality, security enhancements, support for new standards, bug fixes etc. are not deployed.
But the good news is that nopCommerce makes the modification process as easy as possible. It has always had a plugin facility so that new pieces of functionality can be added to the framework easily. There are very clearly defined mechanisms and a whole bunch of documentation on how developers can leverage plugins.
It’s worth pausing a moment and comparing nopCommerce’s plugin architecture with the architecture of less upgradeable frameworks. Many ecommerce framework vendors have one thought when it comes to upgrades - they want you to download the source code for the framework, and then modify it (it’s worth pointing out that in some cases, a very substantial payment is required before you can download the source code).
This may seem perfectly logical - and it sort of works OK, but if this is the only choice you have then fine, but you are going to find it difficult to apply your changes to future versions of the framework. It makes the process of managing upgrades very hard because before you can begin, you need to find out which files you have modified. If you’re thinking this isn’t a big job, allow me to disabuse you of that idea. It’s not unusual for a framework such as nopCommerce to have tens of thousands of files (and I’m not including images in that number) and a moderately complex customisation may touch a few hundred of these.
So, you end up having to use an automated tool to find out where the changes are, and then working through the new version of the framework and patching the equivalent files with your changes. And quite often, the patching process is much more than cut and paste because something fundamental has changed so you end up kind of having to rewrite quite a lot of code.
Now, with the plugin architecture, things are MUCH nicer - this works by defining common interfaces, so if your code honours the interfaces, you can plug it right in. All you have to do is tell the framework to use your code and not the standard code (this uses a programming principle called Inversion of Control - IoC - and is nowadays regarded as best-practice, though a lot of code still has to catch up and adapt it).
This means that when it’s time to upgrade the framework, first off, all your code is in one place (the plugin) so no need to hunt around for it. And if the interfaces that the code framework has defined haven’t changed between versions then there’s relatively little to do. Sometimes those interfaces do change and some work is needed but it’s minimal and constrained.
I’m sure any human beings reading this (as opposed to programmers) may well have glazed over by now - so let me try and explain with an example.
It’s not uncommon for a client to want to change how a price is calculated for an item. There are many reasons this can be desirable, so the good news is that in nopCommerce there is a thing called the Price Calculation Service - which as the name on the tin suggests, calculates prices. I won’t bore you with the inner workings of IoC, but suffice to say that this service is used everywhere in the framework where it’s necessary to calculate prices (hint: that’s about 100 different places), so by creating a customised version of this service and telling nopCommerce to use that customised version, every single one of those 100 places will use my shiny new functionality. All without having to change a single character of the core nopCommerce code.
When a new version of the framework is released, all I have to do is copy my plugin, tell it that it’s now for a new version of the framework and in many cases, that’s it. OK, sometimes more things are needed, but it’s still many times quicker and easier than altering core code.
I also should point out that not all nopCommerce developers use plugins the way they should. I’m not going to name names, but we’ve inherited projects where the original developer didn’t use a plugin and simply hacked the core code. This has cost the client significantly more to maintain than had the modifications been done in a plugin.
And as nopCommerce has matured, it has become easier and easier to do wild and wacky things with nopCommerce plugins - right now, I can’t actually think of anything I cannot do with a plugin. Again, an example is instructional.
In nopCommerce, it’s possible to define product attributes which are used to describe variations of a product e.g. colour and size. And one of the things you do when defining an attribute is say how you want that attribute to display on the product page. For example, you can opt for a drop down list, where the shopper has to select from a menu, or a date picker, where the shopper has to select from a calendar.
In fact, there are ten standard ways for attributes to show themselves. A client wanted us to add another four - and we did this without editing a single line of core code. It was all achieved in a plugin - this includes the modifications to the admin interface to allow admins to choose and control the new plugins as well as the front end.
If you’ve read this far without falling asleep, you hopefully will appreciate that what may appear to be a boring thing of interest only to programmers (i.e. the plugin mechanism) actually translates into real world cost savings and advantages.