Backwards compatability and javascript fragility

So, first of all. I do like Opencart for the administration design and ease of use. Compared to a lot of other e-stores Opencart is miles and miles ahead, still with a lot of improvement possibilities though!

Been working with Opencart, pro bono, for a couple of years now and I just get so frustrated with the shortsightedness of the solutions.

Trying to upgrade from 1.4.x to 1.5.x was a real hassle in rewriting my entire template, basically from scratch. Why? Because the upgrade was littered with renamed variables, like the common/head variable filter_name that was previously called keyword. Sure a few renames may have been called for but far too many had no obvious gain or reason.

So keeping in mind that some users actually use the variables when happily changing names and functionality is a good practice.

Next, I was not pleased with the checkout flow. Sure it looks nice and probably does it for most stores. However it seems a bit complicated for my small store, so I wanted to remove the steps to choose all the addresses over and over, the main goal must be to make the sale.

So I started to have a look at the solution and I must say I was blown away by the design. It's really impressive that it actually does work! But really, inline javascript and generating all errors and posts in javascript, not a really flexible and rigid solution, you must agree?

Also there's the aspect of availability. Having a button that is actually not a button and not selectable when navigating with the keyboard is not a user friendly solution. Some people actually have to navigate just by keyboard.

So instead of just being one of those guys whining about it I thought I cook up something more flexible. Of course risking to have to rebuild everything in the the next upgrade is kind of off-putting. So perhaps I could submit something to the codebase? We'll just have to wait and see..