Frequent OCMOD Changes

<RANT>

Seems with each recent version things keep changing in OCMOD. Continuous micro-changes in MINOR/BUILD/REVISION updates means we have to keep tracking down what you guys are changing with each new release.

I just finished a mod that had to work with the new admin path for the customer controller (moved in 2.1.0.1). While that would have been insignificant, you also changed the path delimiters from COMMA to PIPE. This could only be tackled with duplication of the exact same OPERATION code to cover both potential PATHS of the same file. OCMOD pathing was also affected not too long ago by the removal of GLOB earlier in 2.x.

For those of us making a decent amount, providing ongoing support, and keeping our extensions updated... this is becoming a pain. How about we stop changing OCMOD until 3.x? I have yet to run into any issue that cannot be done with a firm understanding of how the OCMOD system works.

Those who don't get it should read the code in admin/controller/extension/modification.php ... if they still don't understand it, well maybe it's time they actually learn PHP

</RANT>

There are better alternatives to OCmod:

• External VQmod or Integrated VQmod
• Override Engine
• Opencart Events

JNeuhoff wrote:There are better alternatives to OCmod:

Opencart Events

Well .. maybe.
But these events are also changing more often I can change my underwear!
For example, starting with 2.1.x the methods are completely different - to compare see https://github.com/opencart/opencart/wi ... 29-2.0.0.1

And the wiki page for the 2.1.+ events look like as it was written by an 8 year old child and is not complete.
And I am missing a fully working example there.

So who is preventing Kerr to change that again with the next version??
Since 1.5.x it can be frustrating to develop extensions that need VQMod, OCMod or Events.
Or every developer has to build for each subversion a new module - a good cashcow for some as can be seen at some extensions in the extension store.

About the Opencart events: The big changes for these are actually about to be introduced in 2.1.0.2_rc or later. And while it will require changes to be made for the event trigger names, it won't be difficult. The new events system will be much more powerful, as it allows events to be triggered for any of these:

before and after any controller action
before and after any called model method
before and after any view

For example, you could define events for any of these triggers for the frontend category page:

'controller/product/category/before'
'controller/product/category/after'

'model/catalog/category/getCategory/before'
'model/catalog/category/getCategory/after'
....
'model/catalog/category/getTotalCategoriesByCategoryId/before'
'model/catalog/category/getTotalCategoriesByCategoryId/after'

'view/product/category/before'
'view/product/category/after'

I am pretty certain that this new event system will be much more useful, and will stay like this for a long time.

Mind you, the Override Engine is still more powerful IMHO , but for many simple cases, like adding entries to the admin backend menus for new 3rd party extensions, the events system will do its job now!

JNeuhoff wrote:About the Opencart events: The big changes for these are actually about to be introduced in 2.1.0.2_rc or later.

Does this mean the events are not working now? I am trying to code an event for Version 2.1.0.1.
Trigger = admin/controller/catalog/product/getForm/before.
Action = module/mymod/my_method

but it never triggers, I can see it in the database but the trigger is completely different than the one that is in there by default:

Trigger =post.order.history.add

Am I missing something or is this events notification system just not up and running yet?

Grandstand wrote:

JNeuhoff wrote:About the Opencart events: The big changes for these are actually about to be introduced in 2.1.0.2_rc or later.

Does this mean the events are not working now? I am trying to code an event for Version 2.1.0.1.
Trigger = admin/controller/catalog/product/getForm/before.
Action = module/mymod/my_method

but it never triggers, I can see it in the database but the trigger is completely different than the one that is in there by default:

Trigger =post.order.history.add

Am I missing something or is this events notification system just not up and running yet?

That is exactly what I meant.
The wiki pages are outdated and incomplete.
Events are currently not useable - or did I missed some?

OSWorX wrote:Events are currently not useable?

Well isn't that wonderful! Events aren't working and OCmod only works to a limited extent! Sounds like v2 isn't really ready for production use yet.

OpenCart 2 is fine -- just use vQmod. Almost all extensions are either vQmod-only, or provide both vQmod and ocMod files for edits, so you should be good if you install vQmod.

Slightly unrelated, but it was my rant so here goes...

Would love it if things would stop moving from one controller to another between MINOR version updates. Took me a while to figure out the zone() function had been removed in favor of country() for loading localization drop-downs.

It really is a huge pain to keep having to track all this down when it is not easily found in the changelogs.

Johnathan wrote:Almost all extensions are either vQmod-only

Lazy devs... I defended OCMOD early on when people were complaining about how it didn't work. When it fact it did, just had $#!t documentation and was not exactly the same as vqmod so they had to LEARN something new.

rmullaney77 wrote:Lazy devs...

That's a pretty broad blanket statement to make. All my extensions are vQmod-only --- by choice --- and I think you'd have a hard time finding anyone who would call me lazy.

For more discussion on why developers prefer vQmod over ocMod, you should read this topic:

http://forum.opencart.com/viewtopic.php?f=183&t=149484