Published 2010-12-28 00:00:00


There's been quite a demand recently for online shops, While I do have a custom online shop, It's currently quite specific to a client, and does not have a generic frontend. So any kind of re-purposing involves creating a new design. Obviously this looks like a good long term plan, along with open sourcing it properly.

However in the meantime, I discovered opencart a few weeks ago, and for a quick and dirty shop delivery it's not to bad.

On the positive side, installation and basic setup of products is very simple, we checked the code out into git-svn and ran through the installation process, commiting changes, then used the git-ftp code to upload it to the target server.

This gave a managable installation, with full revision control, and after adding the clients logo to the site, setting up things like paypal and shipping etc. we let them loose adding their products.

All of this was quite smooth, but then came the real fun. "But can it do this..." the classic second sentence after you get started..

Their first request was to add extra fields on the product description.

In a perfectly designed system (eg. the shopping system I had already designed), this would be a matter of.

  1. add some extra fields to the database (eg. lead_time VARCHAR(32) ) - eg. in a local_mods.sql file.
  2. add some extra HTML  to the two templates or using app.Builder.  (in the 'overridden templates' folder) - which Template_Flexy supports
This would be feasible as the model layer would not need to understand much about random extra columns in the database that did not really mean to much to the application, but are always essentail  for the client. This is all possible as FlexyFramework/DataObjects/Template_Flexy combo handles extra columns without any modification to controllers or models. No more than 10 minutes work..

To follow the same approach with opencart however would have involved
  1. modify the database
  2. modify the model code for the product (checking each method to make sure they added any relevant hand coded SQL)
  3. modify the admin model code for the product (checking each method to make sure they added any relevant hand coded SQL)
  4. checking the controller class so that it added extra variables to the view layer, the controller layer for just viewing a product is over 400 lines, in what should be done in around 50. 
  5. checking the controller class for the administration side to see if it correctly send the data without understanding the model had changed (which actually it did)
  6. adding some HTML (and lightly sprinkled PHP) in the template for the frontend, using rather verbose, non-templated language, and ensuring it's all correctly escaped.
  7. adding some HTML (and lightly sprinkled PHP) in the template for the backend, using rather verbose, non-templated language, and ensuring it's all correctly escaped.

In the end I concluded that even making all these changes would result in a forked codebase that would become increasingly more complex to maintain, as the client demanded more changes, and the opencart released more versions.

What I ended up doing was using their category mechanism, and creating categories for different lead times, then modifying the front end controller to read the hidden extra categories, and creating a forked template for the frontend.

Even this is still a problematic fork, as SQL needed modifying in model, and extra code was added in the controllers

Having said all that, the experience was far smoother than the mornings job of creating out a development version of a Joomla site, that suffers from the horrific problem that the codebase can be modified by the Web frontend making revision control an absolute nightmare. It's a even better lesson in poor design....

Add Your Comment

Follow us on