Ability to Override Core Code

A bit late to the game here, but I have just been looking at OpenCart recently as a potential platform to use in the future. Since I've yet to find one client happy with how shopping cart systems work "out-of-the-box," the first thing I do when I check out a new system is open up the code. The first thing I fell in love with was the simple MVC structure. The sites I usually develop use either Ubercart or Magento, neither of which I particularly like developing for because one has a very under-mature codebase, while the other has way too much of a codebase to make non-enterprise level development completely unfeasible for sites.

Anyway, I was all happy with OpenCart and all of its native features, and then I realized that there's no real hook system to override core functionality. The one thing I will give Ubercart is that, since it piggy-backs on Drupal, you can usually use hooks to override core functionality.

One example I have, is a client who sells products that come in different dimensions... which would be fine as a drop-down box of options, but the problem is that there's another option for material type (e.g. marble, glass, etc.) that ultimately dictates the cost per square inch and the final price. For a better user experience (and easier administration), it would be better to have two separate drop-downs rather than a giant list showing all ~40 different combinations in one giant drop-down list. Now, to make matters even more complicated, the client also wants a preview image of the selected option to show up as well (e.g. the preview of the fully-dimensioned product with appropriate material).

I've been able to irk Ubercart (begrudgingly) into doing this by creating a custom module that hooks into the product view page and throughout the checkout system to do all of this, all without touching the core... meaning I can usually upgrade without any issues.

So, the problem is I have yet to find a way to do this in OpenCart, which is the one single thing holding me back from using it. This isn't a complaint, I am mainly just curious at this point and looking for more information. The closest thing I've been able to making modifications without touching core code is vQmod. I've looked into it and appears like an on-the-fly sort of diff tool, but why not just take advantage of the core MVC platform and employ a hooks system? Does it benchmark better through caching?

The biggest downfall with osCommerce (other than its lack of security) was the fact that all extensions required doing find/replace operations to the core, and eventually hacked systems would no longer be upgraded. And while vQmod appears to do it virtually (much cleaner!), I'm just wondering why the find/replace idea is being used.

It would seem to me that hooks are far more upgrade-friendly because you're not depending on the same static find/replace methodology for patching (whether virtual or non-virtual) core code. Plus the entire software is based on a programming pattern that would pull it off so well.

I know this is really starting to sound like a whining post, but I have to assure you it's more curiosity that just might be coming off as blunt. I'm hoping I'm just wrong and that there is some sort of override system out there that I just haven't been made aware of... or that there's more to the find/replace mods that makes it worth it for doing extensions this way.

Thanks!

p.s. if anyone took offense, I probably deserve the backlashing coming to me. I'm 100% aware that I could get responses like "Well if you want _____ code it yourself."

I think its been discussed many times.

No you're not missing anything. A hooks and override system has been talked about and might eventually make it in for version 2.0 or something. vQmod was created as a sort of brilliant solution to the problem of not having a hooks or override system. The biggest problem is that Daniel the lead developer is somewhat resistant to a hooks/override system, though not as vehemently as he is to other logical things. All approaches seem to have their drawbacks. A hook system you have to figure out where you want your hooks. Do you put one after every line of code? An override system how do you handle multiple mods overriding/extending the same class? I agree with you that something like this needs to be in place, but also understand that it's never really going to assure worry free upgrades. I mean that was magento's number one claim when they were first creating it you can do anything you want with plugins mods etc and never have to worry about upgrades it won't break anything. After the first major version upgrade if they still claim it they have it buried somewhere that you're not likely to see it because every major version upgrade breaks everything all to crap.

Thanks for the response, all very valid points. There tends to be a snowball effect with hooks. I'd say one hook per major operation/component, after all data has been processed internally, is a good way to go usually (e.g. after a product page's data has been compiled, after a cart's data has been tallied, etc. to allow to massaging of data between the model and output). Though honestly, with an MVC structure it might be far more efficient to have controllers yield control to other classes that extend those base classes... little re-writing of code in that scenario.

I agree with the Magento assessment. Too many times have I had things break due to upgrades. Their problem is they decided to completely re-write components in minor version updates, something people don't anticipate usually unless it's a security issue. Plus they just had so many damned pieces to their framework that it's literally a house of cards.

In any case, while nothing is upgrade proof, I think hooks have more flexibility than find/replace ops. But if the author isn't taking too kindly to the hooks, that's fine with me. His software, his rules. I don't quite understand how it'd be marketable that way, but then again oscommerce saw quite a lot of initial success for being a very unscalable piece of software. It's a bit of a shame though, as this is quite possibly the closest thing I've seen to PHP-based shopping cart nirvana.

I might just go ahead and take the software and integrate hooks and see how well I manage with each update to the core... then, at the very least I just need to update the software around the hooks I write and not all of the extensions I write as well. Or I just might write a more simple one from scratch using Kohana or CI if it's worth the time... but if that's the case I'll still keep an eye out on OpenCart to see how it evolves in the future. Thanks!

vqmod already does this.

Daniel wrote:vqmod already does this.

well not exactly. With vqmod you have to do as he said search and replace. So yes you can add code in, but what if in the next version you decide to change the line that the vqmod was searching on? It will no longer work. With a hook system you simply add something into say the product info hook. No matter what you do in the next version as long as you don't remove that hook then your code still goes in, and there really shouldn't ever be any need to remove hooks once they are in place. New ones may be added, but all the old ones should still exist as well. That is of course baring some sort of major logical structure update, but things like that should be rare and only happen on major version updates anyways.

If I wrote myself a hook system then I'd only have to keep track of one extension (the hook extension that I write), whereas vQmod would have to keep track of several and continually compile the new code on the fly, which seems a bit resource-intensive for me. I'd rather do hooks than hack up the core or bottleneck my resources with vQmod (and then run the risk of things breaking next upgrade). It really seems like a scalable idea, and as long as the hooks are tempered and used in only logical insertion points they'd really contribute to scalability, marketability, and happiness for the extension developers.

i agree.. vQmod is more flexible but not without some limitations if the main code changed like xsecrets said.

I'd still like to see a proper plugin/hook system that would be guaranteed to always trigger at certain times (e.g. new account, new order, choose payment, add to cart, checkout, etc.)

maybe we could use vqmod to implement a hook system and have community maintained for now like vqmod is then later on if Daniel liked it he could integrate it into the core. I know it seems kind of redundant, but you could set vqmod to cache mode and it would be like the hooks system was in the core. Then like the op said all you would have to worry about on upgrade was the vqmod for the hooks system.

I'd be a fan of that interim solution... it minimizes the amount of issues that could affect scalability.

i'm thinking of adding vqmod. i just know there will be loads of people reporting problems when they have installed to many of the mods.

It doesn't really address the root problem of scalability. If I end up using OpenCart, I am probably just going to hack the core and create the hooks myself to execute at key controller points, and then develop my own mods to take advantage of those hooks. Then, if a new release of OpenCart comes out, I will just have to update my hooks mod and rarely have to touch the other mods that use those hooks. I just don't understand what the problem is with having hooks, since every successful, scalable framework and library now uses them in one form or another.

kabojnk wrote:It doesn't really address the root problem of scalability. If I end up using OpenCart, I am probably just going to hack the core and create the hooks myself to execute at key controller points, and then develop my own mods to take advantage of those hooks. Then, if a new release of OpenCart comes out, I will just have to update my hooks mod and rarely have to touch the other mods that use those hooks. I just don't understand what the problem is with having hooks, since every successful, scalable framework and library now uses them in one form or another.

+1

I don't know if daniel has a problem with them. I know none of the other developers around here do, as a matter of fact many of us want them, however I would say there needs to be some discussion on where they need to be exactly before anyone just goes and hap hazardly throws them in there.

Page states are probably the best place to start... preprocess, prerender on any major controller actions (i.e. browse category, load product, add to cart, view cart, checkout).

Edit: Drupal has always done a good job with their hooks. They even allow module devs to make their own hooks so people can hook into those third-party modules.

Hi guys,

What about adding some kind of trigger or event system? This is possibly less intrusive and easier to implement whilst it may solve a substantial number of customising requirements?

For instance for a customer I need to implement some kind of post-order-complete mechanism to create a new user account in another application when an order has been completed succesfully. At the moment I am thinking of adding a simple call from the core order->confirm code to handler code i'll write.

What do you guys think about adding triggers/events?

Willem

A lot of us are in favor of a hook system for triggers and events. Daniel is not so easily persuaded on this topic.
There was some plan to basically a write a plugin handler and use vQmod to put it into place for demonstration purposes. Perhaps if that was done, it would push him over the fence into adding it to the core.

For now, vQmod is the alternative and one that Daniel is backing as a viable solution, so at least we have that.

Fair enough. He must have his reasons.

I am wondering if and/or when OpenCart eventually will be more community 'driven' i.e. more people contributing to core? It will be very hard to protect the excellent status of the code as it is but it would certainly give 'growing' a big push.
For us it would probably allow for a more democratic approach to making changes.

I kind of like the event/messaging system in for example CMSMS. Modules (or core) can just push an event on a queue and (again) modules or core can listen for certain events and elect to handle them. This would be an excellent addition imho.

The core will likely never be out for public submissions. I don't see why it should need to be tbh. Multiple people adding code in their own style and with conflicting design patterns and features will just get messy. Modules, payments, shipping, themes, etc are the community driven pieces currently. The extension system was designed so that new features could be added without touching the core, and that is how it should be.

But I think we need to expand more on the extensibility to allow dynamic expansion for more than just the "extensions" area. A plugin/hook system would be best for that as then people could add hooks for events and triggers, based on the location.

Ideally, the core code should not ever need to be touched if done correctly.

I think I agree. My only hesitation is because of what happened to osCommerce. That was a similar situation and it's dead now.

Anyway I would love to have some kind of event or trigger or even hook system to be able to add specific functionality. I am certainly not a fan of vQmod but maybe that's because I have never used it. From a systems design pov it sounds awful though.

If I'd want to stay clear from vQmod, is there any way you can think of how to implement a post-order-handling extension?

Thanks
Willem