To further explain the grievance I posted last time about OpenCart NUC changes and how harmful they are to the ecosystem around OpenCart, I though it would be useful to post an example.   We’ll look at how the language file is loaded in Better Together for OpenCart.

The first version of Better Together for OpenCart was created to work with OpenCart 1.5.  The controller for this module is created in

admin/controller/total/better_together.php

which defines the object

class ControllerTotalBetterTogether extends Controller

Here’s how a language file was loaded in that version:

$this->language->load('total/better_together');

But in OpenCart 2.0, this changed!  The code had to be refactored as follows:

$this->load->language('total/better_together');

Again, in OpenCart 2.3 – supposedly a minor version update – the code changed again, because the file system was restructured:

$this->load->language('extension/total/better_together');

Not only that, but the class itself had to be renamed – and this happened in a minor version update.

class ControllerExtensionTotalBetterTogether extends Controller {

Language loading did not change in OpenCart 3.0, but many, many more things did.  The net result is that to fully support my open source contribution, I would have to maintain separate, different copies of all the code files for Better Together for

• OpenCart 1.5
• OpenCart 2.0
• OpenCart 2.3
• OpenCart 3.0

Such a shame.  A little discipline – or technical project management – could have prevented this situation from arising.

NUC – not upwardly compatible – means you’ll have problems using older code and data on a newer version of the code.  Most software developers take great pains to avoid NUC changes, or at least document them carefully so that upgraders won’t be stung by them.

But not OpenCart, sadly.  This post from long time Zen Cart developer RodG sums it up:

I initially created Better Together for OpenCart to work with OpenCart 1.5.  I came back several years later, and found that it needed significant changes for OpenCart 2.0.  OK – then came OpenCart 2.3, and again, significant changes were required, and the old code was not upwardly compatible.  OpenCart 2.0 to 2.3 is a minor version number update, and there should never be a NUC change in a minor version update (per semantic versioning). Is the expectation really that I should maintain multiple copies of the source for each minor version change?  As Rod points out, this would be unique among the open source carts I have worked with.

So a few years pass, and along comes OpenCart 3, which contains – you guessed it – yet more NUC changes.  Guys, you’re killing me.  But at least there will be compelling business drivers to encourage people to do this upgrade, right?

Well, no, not really, according to Martin Boss of MultiMerch.   He says vendors considering  upgrading from OpenCart 2.3 to 3.0 face significant drawbacks and limited advantages.

So where does this leave independent software vendors like That Software Guy?  In a pretty bad spot – I am actually getting requests to support Better Together on OpenCart 1.x, because people don’t want to upgrade to 2.3, never mind 3.0.