The Deadly Sins of OpenCart: complex upgrades, destructive releases and lack of integrity

This will be a short series of blog posts on some of the flaws of OpenCart.

By this I don't intend to bash OpenCart – this horse has been dead for quite some time. I wish to merely state my personal opinion on things.

We're all a big OpenCart family, after all.

If you're an OpenCart developer or a store owner running an OpenCart store or a marketplace, you already know what I mean.

• How's that upgrade to OpenCart 3 going so far?
• In fact, did you get to upgrade your store to OpenCart 2.3.0.2 yet?
• By the way, how'd you like that overhaul of OpenCart events in version 2.2 compared to 2.0 and 2.1?
• Oh, and have you moved all of your code changes from vQmod to OCMOD?

And if you're with OpenCart for more than a few years – what did you think about the upgrade from OpenCart 1.x to 2.x?

In most cases, the answers to these questions look along the lines of this.

And these aren't isolated incidents – each new OpenCart release causes massive issues for both store owners and developers.

It is also not only the case with major version upgrades – try upgrading from 2.0 to 2.1 to 2.2 to 2.3 and see how well it goes.

The point is clear:

OpenCart is a huge pain when it comes to updates. Why?

Some of this is due to the quality of third party themes and extensions – I'll cover this separately.

Some of this is also an issue with OpenCart itself. Like new versions being released with no clear upgrade instructions, with broken upgrade scripts or even with broken builds altogether.

Also, minor releases introducing major changes that break backward compatibility.

This is a huge issue for store owners, since you don't usually expect a regular update to bring down your whole store and make you scramble for a solution to get it back online.

This is a huge issue for developers, since you have to waste most of your precious time fixing compatibility issues, creating and maintaining a dozen different versions of your themes and extensions instead of actually selling and supporting them.

Combine this with a lack of a clear OpenCart development roadmap and release schedule and you just may find yourself asking "why not drop the whole thing and switch to something like WordPress or Magento?".

It feels that more and more of our beloved theme and extension developers are doing just that.

Don't get me wrong, WordPress has its own issues – and so do all other systems to a lesser extent. But this doesn't mean it's something to accept and come to terms with. This is not fine.

From our side, we had to drop every other OpenCart version except for 2.3.0.2. This is a decent release and we still happily use it ourselves and recommend it to our marketplace users.

We also never switched from vQmod to OCMOD. I covered the difference between vQmod and OCMOD in my blog post a while ago – and I still hold the same opinion. In fact, we have our own modification system in works for MultiMerch, that should finally put an end to low level code edits.

We also don't intend to switch to OpenCart 3 in the foreseeable future. In my opinion, it is not a step forward for OpenCart and Twig is not something that was needed. I will share my thoughts on where OpenCart should have gone in a separate post.

What can be done about it?

1. Create a clear roadmap for OpenCart development – AND FOLLOW IT.
2. Keep the community in the loop and actually listen to feedback – not dismiss it with degrading remarks.
3. Make updating simple. Make sure upgrade scripts actually work. Don't break backward compatibility for no apparent reason – this will keep developers happy and productive.
4. Create a set of guidelines and rules for theme and extension developers – AND ENFORCE THEM. Changing the templating engine to Twig (or changing anything else) will not solve the mess that has become of themes and extensions in OpenCart as long as there are no rules whatsoever.

MultiMerch is not perfect either – but we acknowledge the problem and are working on solutions.

This is why we're working on a clear MultiMerch roadmap with strict feature separation between core, themes and addons.

This is why we're creating our own extension/modification/event system to get rid of low level code edits and encourage creation of MultiMerch addons.

This is why we're building our own automated update system that will make MultiMerch updates a walk in the park.

This isn't easy, but it really isn't rocket science. And OpenCart deserves so much better.

Update: second part of the series is now available here: The Deadly Sins of OpenCart: poor core feature set