OpenCart: Review of What You Should Know Before Using It
OpenCart, a free e-commerce solution, has quite an interesting reputation on the internet. Experienced developers are generally avoiding it, but it has a large user base.
For me it has always been a no-go. But having my work requiring me to develop in it for a project, I now acquired hands-on experience. Did I change my thoughts?
In this article I will review the main things that caught my attention and whether I would advocate for this system in the future.
My experience has been collected on programming the following work:
- Custom import page dedicated to spreadsheets (with around 10 sheets)
- Changed filter functionality queries
- Custom work on downloadable files and limit them per user
- Mail changes
OpenCart: Is it good? Is it bad? Should you use it? You be the judge.
Read on for the things you should know before using it.
This article uses code examples and links for version 3.0.3.6.
Don’t expect modern quality code
OpenCart does not have much modern quality code. It is very traditional functional programming. There are classes, but they are just a collection of functionality.
You will find:
- a lack of abstraction
- not much use of existing frameworks
- no dependency injection
Due to these choices, there is duplicate code.
There is a lot of duplicate code
Most shared code is copy-pasted. You will find duplicate logic. Duplicate queries. And duplicate initialization of dependencies.
For example in the admin model ModelCatalogProduct: Adding a product is
~130 lines of code. Editing a product is ~155 lines of code.
Using so much duplicate code for just adding and editing is insane. Adding or updating an existing product is a matter of an existing id/entity or not.
Another example would be the initialization of the mail client:
$mail = new Mail($this->config->get('config_mail_engine'));
$mail->parameter = $this->config->get('config_mail_parameter');
$mail->smtp_hostname = $this->config->get('config_mail_smtp_hostname');
$mail->smtp_username = $this->config->get('config_mail_smtp_username');
$mail->smtp_password = html_entity_decode($this->config->get('config_mail_smtp_password'), ENT_QUOTES, 'UTF-8');
$mail->smtp_port = $this->config->get('config_mail_smtp_port');
$mail->smtp_timeout = $this->config->get('config_mail_smtp_timeout');
Doing a simple search over the project reveals 27 occurrences of the above code.
$ grep -Rio "\$mail->smtp_timeout = \$this->config->get('config_mail_smtp_timeout');" upload/ | wc -l
27
Duplicate code will impact the extensibility of the project.
It is not build for easy extensibility
By default the system is not managed using composer. Though you can still use composer for libraries.
The system encourages modification of the core. Because there’s no abstraction and dependency injection, it’s hard to extend classes. For this matter the system relies on a mechanism to search and replace PHP code.
There’s a mod called vQmod. It acts as a proxy for PHP and Twig files. For
example if you would like to add a Reply-To header to a order alert mail, you
could do this search and replace:
<file name="catalog/controller/mail/order.php">
<operation>
<search position="after"><![CDATA[$mail->setText($this->load->view('mail/order_alert', $data));]]></search>
<add><![CDATA[
$mail->setReplyTo($order_info['email']);
]]></add>
</operation>
</file>
Furthermore, plugin files are stored over multiple folders. This means managing a plugin is challenging. Personally when I created a new plugin I made symbolic links for all my files across the OpenCart folders. This way I was able to keep my plugin files in a single folder.
Data integrity seems to be an issue too. Saving a simple varchar field in the admin generates html entities. Characters such as “&” are saved as “&” in the database. This is not desirable, since you will have trouble searching an existing category by name.
Due to these factors. Updating this system is not straight forward as other systems.
Not a community you can rely on
A good open-source system has a powerful community on GitHub with good and free extensions. What struck me the most is that I couldn’t find much GitHub repos for simple changes. The eco-system seems fully focussed on the market place with a lot of paid plugins.
For this reason I preferred to develop more functionality myself. I couldn’t risk not delivering by using paid plugins that only had like 16 sales. They would lack and cost time.
The OpenCart project is entirely in the hands of a single man.
The creator of OpenCart itself is quite an interesting person too. He likes to argue in an unhealthy way. Even swearing to people who report issues is not uncommon.
Security and updating might be an issue
Because of the reputation of the creator not taking security issues seriously at times, security might be an issue in the future.
For both the security and updating issues there seems to be a community fork of the project. Though I don’t have experience with it and I would really suggest looking for other projects instead of going this route.
It is easy to understand
A plus side of this system is that it is very easy to understand for any beginner programmer. The reason for this is because there is no abstraction, but duplicate code instead. It makes most code very easy to read top to bottom.
My guess is that this is the main reason OpenCart is still quite popular because it attracts early developers.
Reading the code of OpenCart reminds me of students I ask to write a small project to test their knowledge. It is similar code and after this small test I would teach them about common design patterns and re-using code.
OpenCart could be an interesting project to teach students about the effects of duplicate code.
It might affect your reputation
For me personally, if a person or company is a big fan of OpenCart, I know what I can expect from them regarding their developing experience.
Consider, with the quality of this project, what it means for you and your business when promoting such a system.
OpenCart might affect your reputation or has effect on the people you attract working with you.
Conclusion
OpenCart is quite popular and has been around a long time. It is managed by a single person and therefore it seems to have not aged well.
I discovered hands-on that:
- it lacks modern quality code
- there is a lot of duplicate code
- it is not build for easy extensibility
- the community lacks code sharing
- security might be an issue
- it is very easy to understand for beginner programmers
- it might affect your reputation as a person or company
Personally I would not advocate for this system in the future. My experience was in line with what I have read in the past on the net. Though it was interesting to use it for real.
I have respect for the creator though. It is not easy to build and maintain something successful on your own. Aging software well is hard with limited resources (time). I am sure, regardless of swearing to other people, the creator knows this and understands some of the critics.
I find that the project is interesting for showing students an example of real life code that could be improved with some common design patterns, because the duplicate code in OpenCart is quite consistent and easily detectable.
With writing this article I hope I helped you decide whether to use OpenCart in your next project.
Happy coding and thanks for reading!