Opencart Theme Development – My Opinion

Opencart theme development, in it’s current state is flawed in my opinion. Opencart is a great platform for any type of ecommerce store, having a plethora of features for users and a low entry point for developers. As a result, Opencart has plenty of themes available for download, just take a look on Themeforest. Occassionally, to test out various things out I’ll install such themes locally. More often than not the theme will break the store completely, or render parts of the site completely broken.

9 times out of 10 the issue will be down to the theme developer not sticking to basic Opencart theming guides – they’re very basic to say the least. The main point to note is that Opencart, like other ecommerce platforms, uses a fallback technique on the “default” theme. So, for example, if Opencart doesn’t find a template for a category listing page, it will fallback to the template from the default theme. If the latter is not adhered to, and it isn’t – look at some of the so called “premium” themes out there, it makes upgrading very, very painful. There are theme developers out there that are copying over a files for the sake of it, when no changes are made. If your theme literally only has changed the color/layout of the footer, apart from the default stylesheet folder, image folder and header template you only need the footer.tpl in your theme folder.

The Current State of Opencart Theme Development

The main issue with Opencart theme is development is latter mentioned, low entry point. Whilst it is generally thought as one of Opencart main benefits (ease of development, compared to say Magento), it is also one of it’s main drawbacks when it comes to third party themes. Comparing Opencart to Magento, where the entry point for theme is higher, there are fewer god awful themes out there, purely because the developers see the significance of the markup used.

As the theming guide is so loose, there is no set standard to theme development – something which Opencart urgently needs. As a result, the Internet is littered with lots of attractive, but god awfully written themes. This reflects poorly on the Opencart community and platform as a whole.

What follows are a couple of solutions that, in my opinion, would increase the quality of themes available.

A Standard for Opencart HTML Elements

The Opencart developers should publish a standard and globally accepted guide for HTML elements, classes and IDs used throughout the store. This guide could explain the significance of each HTML essential HTML element and would cut down of the number of themes that “break” Opencart. In my experience, a lot of these errors happen when theme developers try to change elements of the theme that interact with JavaScript – the one page checkout and mini cart drop down for instance. This would do a lot to discourage developers in using their own classes or IDs. Granted, some themes require this as all Opencart stores would look the same, but there is no guide to refer to, so it’s a kind of “free for all” when it comes to coding your HTML.

This brings me onto my next point and is something I’ve heard mentioned on the Opencart forums before. Like many other pieces of software on the Internet, have a special prefix for essential elements of the page. For instance, in the header of the default Opencart theme you have a wrapper with the ID “cart” for the cart summary and mini cart drop down. For all essential elements like this prefix them. For instance, “cart” would become “opencart-cart” or “oc-cart”. This way, you could leave the JavaScript untouched and add (and emphasise) one very important line to the Opencart theme guide, that would prevent a plethora of errors:

“Do not remove or rename any element whose class or ID is prefixed with [chosen opencart prefix]”

As an example, although in a slightly different context, the insanely popular Fancybox 2.0 does this, prefixing all it’s CSS with “fancybox-“. Furthermore, Opencart could also include a develop,ment version of it’s CSS files that comment each all the essential classes and set out their purpose. A minified, production version and undocumented could also be provided. Whilst this is big task, I feel it would benefit theme development.

A Suffix for Opencart Features …

This prefix approach could also be carried out to other elements. All Opencart modules, or any module for that matter, should include this prefix and be named accordingly. For instance, take the default “featured” module for Opencart. The generated HTML makes no reference to the module at all, simply using “box” as the class. I personally do this when theming Opencart for finder control, but adding a class titled “opencart-featured” is much better practice. Yes, I’ve added another class, and the page speed Nazis will be screaming at me for increasing the page size somewhat, but by adding a simple identifier a theme developer can add styles targeting that module alone, whilst still being able to make site wide changes by alerting the “box” class. Additionally, I can easily apply for some JavaScript specifically at that element. People could also develop standard extensions to target that feature alone. I’m personally bored of seeing themes come packaged with a totally separate module for something as simple as a content slider, simply because they’ve used a different slider.

A Globally Accepted Boilerplate Theme

Whilst there are a couple of those around, Opencart has no standard “bare bones” theme. This is comparable to the famous HTML5 Boilerplate theme. There is no globally accepted basic and semantic theme ou there. I propose that the said theme base it’s markup on HTML5, use minimal CSS3 and include all the relatively new micro data, that Google uses for rich snippets (reviews, breadcrumbs etc.).  A boilerplate theme would avoid a developer having to copy the “default” theme. There would be an instant bare bones template, fully semantic (E.g. lost items for lists instead of dividers, use of the new HTML5 elements etc.), with all the latter Opencart specific prefixes. The template could also be take one step further to neaten up the templates – my pet annoyance is the lack of indentation and use of PHP’s short tags. Additionally, apart from some styles to provide a basic structure, the boilerplate would have no styling applies.

The boilerplate could even be be responsive out the box, simply by using set class elements. Something like the popular Getskeleton CSS framework would provide a great starting point and be a great base feature for Opencart to have. Currently, responsive themes come at a premium and I feel is something that is pretty essential with the rise of small device usage amongst shoppers.

The theme could be bundled with the vanilla Opencart download and updated when Opencart is updated.

A feature that has always stood for me is the custom Twitter Bootstrap download feature, that amongst other things, allows you to customise basic CSS styles using less variables. If there was a basic boilerplate theme Opencart could easily have this feature and allow a user to instantly apply styles to their bare bones theme. As less is being used, changing these styles in the future would be easier still.

I’m sure a plethora of other benefits exist, but the main one to take is away is a set standard for theme development.

In conclusion, some of the above may seem fairly personal choices and on a couple of instances you may be right. However, as a platform, Opencart needs to have a much more rigid standard when it comes to theme development and build on the extremely loose structure currently set out.