Should we bring OCMOD back?

[danielkerr]

I can create a new type of ocmod that uses the generate files and keep them in the extension folder and then use events to override the the original files.

please let me know if its worth doing?

[Cubuss]

yes is it the same idea as vqmod?

[FelipoAntonoff]

OCMOD yes, similar to vQmod, but it is in Extensions -> Modifications and the cache generated in the storage/modification folder, in addition to small changes in the XML.

[cartbinder]

I can create a new type of ocmod that uses the generate files and keep them in the extension folder and then use events to override the the original files.

please let me know if its worth doing?

Yes, that would be awesome!! Because you can't do everything with just events. And it's so time-consuming to do debugging via events.

[stalker780]

@cartbinder If you read carefully, these are still going to be events.
I suppose this system will have same issues.

1. Hard to debug
2. Impossible to modify hardcoded SQL code
3. Impossible to modify core library and engine files functionality
4. Lots of bugs when multiple extensions try to overlap same core functions
5. Unable to modify template source code before it is rendered with TWIG

[cartbinder]

Yes true. Pure event system have those big drawbacks as you said. 100% true.
And till now I don't see any way in the Opencart core to fix that.

But If ocmod comes back it would be a positive thing.
As that can solve the issues to some extent may be.
Because if maximum developers use Ocmod then the above points would be solved.

Currently, it's so time-consuming process via events that developers are not even starting the process.
Plus the drawbacks of the event system cause more delay to start the shifting process.

[FelipoAntonoff]

The case is that Event has a more specific, niche use, while OCMOD has a much broader use.

I have been using vQmod/OCMOD since Opencart 1.5 for more than 10 years and it has 100% met all use cases and that is why we create very complex Apps/Modules and made as close to the Opencart standard as possible, I use a lot of XML for changes made to files platform natives without having to touch 1 line of them, being easy to update, activate or deactivate.

I think the most important thing in the case of OCMOD is knowing how to use it correctly, because it is super simple, you learn its use in minutes or hours, but only with experience that you learn to make beautiful XMLs that avoid the excessive use of offset and use the correct lines.

It's a pity that there were developers accusing the tool of bad code, when in fact the problem is clearly bad professionals and never the tool, after all they can make bad code directly or with events and it will be even worse to solve and discover.

[stalker780]

@danielkerr Events/modifications system definitely requires an upgrade.
It cannot replace ocmod/vqmod in the state it has now.

[FelipoAntonoff]

Exactly, there's even a topic debating about #10883
They are tools with very different proposals that should be used together and not Events replacing OCMOD.

[goro-gh]

I'm very new to OpenCart. This ocmod/vqmod techology is strange to me. Why people just not using diff + patch if core file change is needed ?

[FelipoAntonoff]

Simple, because few stores use Git and the like and OCMOD/vQmod makes it much easier to install, enable, disable or apply new changes.

It's very easy for you to open an XML and make the adjustments and everything is documented in the XML itself, informing which line was changed and what was done, it's like a documentation that does the action.

[markimax]

Ocmod must be in Opencart
This is a joint development tool !
"microgit" for store and developers this store

[mhcwebdesign]

No to OCMOD!

But what's needed are more event triggers, especially for singleton library classes (cart, customer, currency, etc), and also for the loader class.

For example, when a library class is loaded (instantiated) have an event trigger there which could also load subsequent decorator classes wrapping up the library class instance, containing some modifications for the methods.

[markimax]

Question...
And how will you change the templates of developers given that they are often updated?
OCMOD - a joint development tool
OCMOD must be along with events
And I agree with you - there are not enough events for the libraries

Developers are very missing OCMOD

Due to the fact that there are no ocmod, developers prefer NOT to use Opencart 4, and use Opencart 3

Many developers are thinking of making fork 3 because of this
How to change the template of the developer theme without changing its source code (important when updates)

[FelipoAntonoff]

@markimax The problem, as I have already mentioned for years, is that Events never replaces OCMOD/vQmod, they are tools with different proposals and to be used together or just OCMOD/vQmod.

The Event basically works as a trigger, there is no way to change Opencart's native files and create their cache.
OCMOD, on the other hand, serves precisely to change native files without touching 1 line of their code, all with logs and generated cache, relatively easy to debug, adapt, install, activate, deactivate or remove any changes made.

The cool thing about it is also that it is a documentation, as it shows the changed files and what was done by looking at the XML itself.

And those who want to use a lot of PHP inside can use it together with Model, I create complete Apps/Modules just with OCMOD + Model and if necessary Controller + Model + View + OCMOD.

Events is a very interesting tool too, but its use is more like a trigger, for example I want a code to be called when an Order was created, then it would be a good use for Events.

[bunin-a]

No to OCMOD!

But what's needed are more event triggers, especially for singleton library classes (cart, customer, currency, etc), and also for the loader class.

For example, when a library class is loaded (instantiated) have an event trigger there which could also load subsequent decorator classes wrapping up the library class instance, containing some modifications for the methods.

				$product_data = [
					'product_id'  => $result['product_id'],
					'thumb'       => $image,
					'name'        => $result['name'],
					'description' => oc_substr(trim(strip_tags(html_entity_decode($result['description'], ENT_QUOTES, 'UTF-8'))), 0, $this->config->get('config_product_description_length')) . '..',
					'price'       => $price,
					'special'     => $special,
					'tax'         => $tax,
					'minimum'     => $result['minimum'] > 0 ? $result['minimum'] : 1,
					'rating'      => $result['rating'],
					'href'        => $this->url->link('product/product', 'language=' . $this->config->get('config_language') . '&path=' . $this->request->get['path'] . '&product_id=' . $result['product_id'] . $url)
				];

				$data['products'][] = $this->load->controller('product/thumb', $product_data);

I need to add some fields to my template like sku or ean
What event should I write/apply?

[punitkumar]

Agree with @mhcwebdesign
No MORE OCMOD!!

We just need more event triggers as said by @mhcwebdesign

One more require - have twig file raw content in view.before event.

[punitkumar]

@bunin-a A simple event handler for trigger catalog/view/product/thumb/before instead . By this way you can add ean, sku to $data variable. As for trigger catalog/view/product/thumb/before you will have whole $product_data as $data['product_id'], $data['thumb'], $data['name'], etc.

[stalker780]

@punitkumar
Yep. Events do not allow to edit twig source code. You can only modify compiled HTML after it was rendered with TWIG.

[chulcha]

@punitkumar WHERE $data???

$this->load->controller('product/thumb', $product_data);

WHERE extra fields?

$product_data = [
					'product_id'  => $result['product_id'],
					'thumb'       => $image,
					'name'        => $result['name'],
					'description' => oc_substr(trim(strip_tags(html_entity_decode($result['description'], ENT_QUOTES, 'UTF-8'))), 0, $this->config->get('config_product_description_length')) . '..',
					'price'       => $price,
					'special'     => $special,
					'tax'         => $tax,
					'minimum'     => $result['minimum'] > 0 ? $result['minimum'] : 1,
					'rating'      => $result['rating'],
					'href'        => $this->url->link('product/product', 'language=' . $this->config->get('config_language') . '&path=' . $this->request->get['path'] . '&product_id=' . $result['product_id'] . $url)
				];
				```
				
What "before" event are you talking about?
catalog/view/product/thumb/before 
Input array - product_data

[FelipoAntonoff]

Guys, these examples are super simple use cases that Events meet, but Events can't meet all the use cases that OCMOD can meet 100%, it seems that many still don't know the magic and fantastic tool that OCMOD/vQmod is if used correctly and wisely and best of all Cache is the end result, while Events run realtime.

For example you create a change in a Twig in OCMOD, it will generate a copy of the change made, saving all the original twig + the change in storage/modification.

I doubt any developer will create all the Apps/Modules that I create with OCMOD using only Events, many of the things will need to be edited directly in the original file which would be a mistake and backtracking.

OCMOD is what makes Opencart unique in the development part and a tool that I miss in any system, Magento and Prestashop will never be as good in development precisely because they don't have a vQmod/OCMOD or something and just hooks and events that greatly limits the development of good Apps and Modules with more customization.

We have to understand that each tool has its use, the Event is for triggering and the OCMOD for changing any line of a file generating the cache and logs.

[pashast]

@bunin-a A simple event handler for trigger catalog/view/product/thumb/before instead . By this way you can add ean, sku to $data variable. As for trigger catalog/view/product/thumb/before you will have whole $product_data as $data['product_id'], $data['thumb'], $data['name'], etc.

And this requires another DB query for each product to get the EAN? What happens if there are several modules here? Each module will create an additional DB query?
We should be able to work with the $result, $product_data etc.. arrays

[chulcha]

Yes!!!! Extra query!!!
I once suggested that thumbnails be given a "raw" result, but they didn't hear me

foreach ($results as $result) {
   $data['products'][] = $this->load->controller('product/thumb', $result);
}

[BuslikDrev]

2 modules will be able to make changes to the template?

[IP-CAM]

For all those (like me) fully unfamiliar with events, OcMod would/could be an easy Solution to all those fellows, eager to participate, but yet unable, to actively participate.

[FelipoAntonoff]

Yes, I am 100% in favor of returning OCMOD or a similar tool to Opencart 4 and all future versions.

I find the idea interesting, but it would be necessary to analyze what would be the real improvement vs OCMOD traditional.
I'm more in favor of returning OCMOD to how it was before and evolving from it, because we need something that is saved in the Cache and not that runs in real time, as this improves performance and facilitates debugs and tests, since the OCMOD generates a log of modified locations as well as a cache, making it easy to parse.

Perhaps what is needed to improve OCMOD is having a native editor and that the theme editor works together with OCMOD and not disabling it.

I made this topic a long time ago asking to keep OCMOD in Opencart 4 and it contains many reasons for this: #10883

The vQmod will come back strong in Opencart 4, that's why I think it's better to have native OCMOD or something like that in Opencart 4, even to maintain the biggest differential in the development that Opencart has vs other E-commerce platforms and that make it unique and higher.

[decMuc]

What is one of the most outstanding and powerful tools in OC? OCMOD!

I could understand Daniel's decision not to integrate OCMOD in its old form into OC4, but I still believe it was and continues to be a mistake.

Which other shop system offers such a brilliant tool where you can customize your things at lightning speed with just one single tool as you need it? As far as I know, no other shopping system does.

So why not retain an absolute usp?

[danielkerr]

fine. this is my todo list.

release asap because of length since last one has been a while
finish subscriptions,
finish blog,
add back ocmod

[punitkumar]

Please read Newest discussion on following thread
#10251

Kindly advise how can we attach PDF file in order alert mail without rewrite whole code?

It's merely impractical to rewrite whole code just for single attachment, also, another drawback is, other events will not works on override.

[FelipoAntonoff]

Excellent @danielkerr, looking forward to the return of OCMOD, I easily consider it the best current development technology and one of the biggest differentiators of Opencart for years, even though it is simple in its use and concept. In the future perhaps we can think of a way to improve it even further, in my use of vQmod and then OCMOD over more than 10 years, it has met 100% of the use cases, I even use it to version the codes and avoid excess files, very useful to use in conjunction with model and controller.

One detail is the use of the Theme Editor, at least in Opencart 3, when using the Theme Editor, it stops picking up the modifications, as the changes are saved in the database and not the files, perhaps an interesting upgrade would be for OCMOD to be able to handle these files edited by the Panel as well.

Regarding Blogs, if Opencart were to be native, it would be interesting to use Markdown as a marking system, as it is simple to use and very well known.

[sv2109]

Hi @danielkerr .
It is a pity that I saw this topic late, although I have been working with OpenCart for more than 10 years. I hope it's not too late.

Events are definitely the best thing that has appeared in OpenCart in the last 10 years. Events make OpenCart qualitatively better and without Events further development of OpenCart is simply impossible.
The problem is not Events itself - it is a very good tool, it is a programming pattern that is used by almost all engines, CMS and frameworks and is used not because they are very stupid and cannot invent their system based on ocmod, but because the system of extensions based on Events is a very correct system that has many advantages over ocmod. Ocmod is an anti-pattern and directly contradicts even the principles of S.O.L.I.D., especially the second Open-Close principle, which says that "software entities (classes, modules, functions, etc. ) should be open for extension, but closed for modification" Because this will create a lot of conflicts and problems in the future. The principle says rather about some rare cases of modification, but in OpenCart ocmod is the core of the entire extensions system and is used for tens, hundreds and thousands of changes of the code of OpenCart on each site. And it's extremely bad.

Your biggest mistake was that you removed ocmod too fast. You added Events to the system, which could be used to solve only part of the tasks, but not all of them. And at the same time, you removed entire ocmod. And what should developers do now if, when writing modules and themes, they had a lot of tasks that simply could not be solved without ocmod, absolutely not at all!

How should it be done?

1. at the beginning announce that OpenCart gradually! will switch to a new extensions system that will work on Events. Therefore, from now, everything that can be done using Events must be done on Events, it is a priority now.
2. also announce that from today ocmod has "deprecated" status, it will be completely replaced by Events in the future, and for now it can be used for situations, if something cannot be done using Events.
3. create a topic for developers, where they can write about problems they face in their work, which cannot be solved by Events.
4. based on feedback, improve Events until they cover, for example, 99% of all tasks. And it can be done!
5. after that, it will be possible to create a new version of OpenCart, where ocmod will be completely replaced by ocmod, because now it's ready fo it, it's very well tested on previous version and using Events developers could solve about 99% of all problems.

It is now possible to return ocmod as a temporary measure that would close the gap in Events capabilities and which will eventually replace ocmod in the future as an anti-pattern that creates many problems.
If you return ocmod to keep it forever and remove Events, I believe this will just kill OpenCart in the near future.
Because without a good extensions system it's impossible to build a good engine, and on the basis of ocmod it will never be possible to build a good extensions system, never, because it creates a huge number of conflicts and problems that even developers are tired of constantly correcting the same mistakes, and what about ordinary users? Why should they do all of this? If there are dozens of online services now where they can create their stores in few mouse clicks without any programming knowledge and not only create a ready-made store, but also extend it with new modules and themes also with few clicks. And they are ready to pay a lot of money to protect themselves from this hell with constant mistakes and conflicts. And it will be impossible to get rid of all these errors if you do not get rid of the ocmod.
Modern engine needs modern technologies, and they definitely need a good extensions system, which can be built exclusively on Events. Without it, OpenCart simply has no future.
IMHO

[mhcwebdesign]

@sv2109
I fully agree with you. XML is a structured markup language for documents and protocols, it's not a programming language. What's really needed for OpenCart as soon as possible are more event triggers for the many singleton library classes (cart, customer, mail, etc)

[FelipoAntonoff]

@sv2109 I disagree with your points.
Events is used by several CMS and is something common and interesting to exist, but its use is clear for events and not as a replacement for OCMOD/vQmod.

OCMOD is the best development tool I've ever seen in a CMS and Opencart's biggest differentiator, not to mention that its concept and use is super simple, being basically a tool that makes changes to files based on the searched line and then saving it in a Cache, which in terms of performance also surpasses Events, since the change is saved in the Cache, in addition to having Logs and being easy to edit, deactivate or remove.

Some developers unfortunately don't understand, but Events does not replace OCMOD and nor should it, as its focus and scope is different, for example try with Events to change a controller, model, library or other file on any line. You will be able to use events for Triggers, run code after editing a Product or at most change a view with Events, changing it before delivering the page, but requiring a lot of code, something that with XML is for the file you want to change and the operations simple and clear XML.

I'm curious about the difficulty some colleagues have with using OCMOD, given that what they want is the code itself but rather a tool to make working with Plugins/Modules better in Opencart and avoid directly touching the files. I've been working with Opencart for over 10 years and I've never had any problems with vQmod and then OCMOD, it actually makes my work and maintenance absurdly easier.

Now there are bad professionals, but it will be the same with Events or another tool and it will be even more difficult to identify and correct other people's mistakes.

[chulcha]

OСMOD, there is a list of instructions for changes.
Don't forget that you are not the only developer.
Events are interesting for unique solutions. But they are not suitable for group development.
Events must be applied to all methods (queries)
You cannot make multiple requests in one method
For example

	public function addProduct(array $data): int {
		$product_id = $this->model_catalog_product->addEntity($data);

		$this->model_catalog_product->updatedEntityImage($product_id,$data);
		
		foreach ($data['product_description'] as $language_id => $value) {
			$this->model_catalog_product->upadateaddEntityDescription($product_id,$value);
		}

[FelipoAntonoff]

@chulcha Exactly, Events are for Events and OCMOD has a much greater scope and use, which is basically being able to modify files with simple instructions in XML and saving any changes in Cache, not running in real time which is great for performance, in addition to generating Logs .

Of course, there is a way to improve OCMOD, but Events will never replace OCMOD and its broad use cases.

There are people who think that Apps/Plugins only have simple triggers, and it is often necessary to add/edit or remove existing codes and for that there is no better solution than OCMOD and its concepts.

Now OCMOD needs to also use themes edited by the Opencart theme editor in the future and it would be interesting to improve its features to make the tool even better, like perhaps a direct editor for Modifications, more detailed Logs and other possible improvements.

Now there could be another tool to replace OCMOD, but it would probably have the same basic concepts, but I think it's better to just improve what has been working for years and is super mature.

I'm super happy with the future return of OCMOD and I consider it a mistake by some colleagues insisting on removing it and blaming it on bad developers, I want to see a bad developer doing a wrong Event and stopping all the code, it's going to be much more complex identify, while with OCMOD, in the error log there will be modification/.... the file path, just open the cache and see the error and then check which module could be the one that did something wrong and there is even a way Quick test to see if it is an OCMOD, just deactivate it by cleaning it, if it resolves it is an OCMOD and then just find which one with the help of the Log.

Even when dealing with non-standard themes, OCMOD helps lol, in fact I think Opencart should standardize themes more, I'm tired of seeing non-standard themes from Opencart and even famous ones like Journal, Pavo, Burn Engine, Lexus and others that I would never recommend it to a good store.

[paulfeakins]

please let me know if its worth doing?

100% as doing some things with events is incredibly difficult and sometimes almost impossible.

[iplocker]

Really wondering why you have remove it at first place ! So needed tool !!!
Lots of Dev's couldnt work with out it their extensions !!!
4.x vesrion is out so long time and NOW you re thinking to bring it back so ppls now will wait for it to think about serious if they are going to keep going with the OC or move out from it and move to another shopping cart!

Finally concentrate to 4.x and clean all the bugs , bring back OCMOD and make it STABLE!!! Finally !!
Can you see that OC is not so popular any more ?! Think about it !
Thanks

[FelipoAntonoff]

Actually, to this day I don't know why they removed OCMOD, some devs tried to blame having bad extensions and bad devs using OCMOD, as it is only used to change original files with Cache, imagine how amateurish it would look if it was changed directly in the original files as is unfortunately done in other systems.

OCMOD (XML) is Opencart's biggest differentiator, it makes it 100% modular and easy to develop, I even addressed this in a Live I did, being able to touch any file and line without touching it directly is fanatical and also generates a high cache performance.

Bad code will always exist, if whoever does it is not a good professional, whether with Events, OCMOD (XML), directly in the files, etc. No tool is proof of a bad professional and nor should it be.

[danielkerr]

ok ocmod is finished being added back. please test.

[decMuc]

Yeeeah.... thanks a lot Daniel!

[FelipoAntonoff]

Thank you very much Daniel, I've been waiting anxiously for more than a year for this, finally now Opencart 4 will become more used by professionals and stores, in Brazil we will focus on Opencart 4 in 2024.

Finally, Opencart has OCMOD again, the best development system I've seen in more than 12 years focusing on Development and E-commerce and super simple, after all, it modifies files without touching them directly and with Logs, there's nothing more beautiful than that lol, there would even be if there was an editor that could interpret PHP within XML, format and correct errors, but if PHP is large, Model can be used for what is called from XML.

[mhcwebdesign]

@FelipoAntonoff : You are going on and on about OCmod. If you haven't managed yet to do extensions for OpenCart 4 because of the till recently missing OCmod feature, then you really need to catch up on some common programming design pattern.

Perhaps it might be a good idea to have a separate extension marketplace just for solid quality extensions, because with the availabilty of OCmod it will be only a matter of time before we see so many rubbish extensions again.

[markimax]

OCMOD is a joint development environment in the first place.
Let's forbid the Github (there is also a lot of garbage on Github), ... as it does not meet the paradigm of programing )))
OCmod is as microgit, a kind.
PS OCMOD is a tool (joint development environment)
"If you do not know how to use a shovel, this does not mean that the shovel is bad. You just don't know how to use it"

[FelipoAntonoff]

@mhcwebdesign I'm pretty good with OCMOD, I think maybe you need to learn how to use the tool better.

Because I'm going to change something that is going very well and best of all it has the best performance and relatively easy maintenance.

Remember, the quality of an Extension has nothing to do with the use of OCMOD, Event, direct manipulation of the code or other adopted standard, but rather with the professional who creates it.

I guarantee that we create high quality products using OCMOD and MVC, without having to change 1 line in the Opencart standard code and without affecting its performance, remember OCMOD is just a way to edit original files and everything is saved in Cache.

I think it's a mistake for you to try to generalize and blame an excellent development tool and I'll go further, there is no better tool than OCMOD for creating Extensions, which is why Opencart is also superior to any E-commerce CMS that exists.

The Opencart marketplace just needs better curation and not separate modules that are made with X or Y tool/technology.

I've been working with Opencart for over 12 years and I've made over 200 Extensions/Apps, some of which are highly complex and require a lot of changes, I know what I'm doing and of course I'm always willing to learn, but I'll never blame bad professionals or bad extensions with the tools used, remember a bad professional can also do bad Extensions with Events and other tools/technologies.

[danielkerr]

Really wondering why you have remove it at first place ! So needed tool !!! Lots of Dev's couldnt work with out it their extensions !!! 4.x vesrion is out so long time and NOW you re thinking to bring it back so ppls now will wait for it to think about serious if they are going to keep going with the OC or move out from it and move to another shopping cart!

Finally concentrate to 4.x and clean all the bugs , bring back OCMOD and make it STABLE!!! Finally !! Can you see that OC is not so popular any more ?! Think about it ! Thanks

I removed it because it doesn't exist in any programming paradigm. although it might make sense writing to the extension directory

[paulfeakins]

"I removed it because it doesn't exist in any programming paradigm."
That is true, but in my humble opinion many of the very academic and theoretical paradigms - complicated design patterns, inversion of control, the entity–attribute–value model, events, etc. etc. - are less useful than something as simple as vQmod/OCMOD, so I'm very pleased to see this! :)

[FelipoAntonoff]

@danielkerr , I believe it doesn't exist, because no one has ever thought about it.
You can see Wordpress, Magento, Prestashop, etc., they all have serious problems creating Extensions/Apps that need to modify platform files, as there are no methods like OCMOD/vQmod for this. They need to modify directly in the original file or try some Hook that is hopefully prepared for what they need to do.

Imagine in the visual part creating Notify Me in the Product, Informative Installment, reformulating the Footer, etc., without OCMOD, it would probably be necessary in many cases to edit the platform's files.

OCMOD itself is something super simple and does not need to follow any standard, because in fact the standard to be adopted is the one used internally in the code, after all it is not the code itself but a structure to be able to modify the files without changing directly. In it you can use Model, create new routes for the Controller, edit Twig files and much more without limits as long as there is the line to be searched or a nearby one.

Something interesting for certain cases is to have Hooks, lines as comments to facilitate the use of OCMOD in certain files and locations.

Opencart itself doesn't follow much of a standard either, it's almost pure PHP, with a micro Framework and a ready-to-use E-commerce structure, it basically follows the simple MVC + Library and Language pattern, without much frills or many layers. which makes it simple, easy to use, easy to modify and with great performance and low resource consumption, with it it is possible to have a store that has more than 10 thousand orders per day consuming 0.5 CPU after Index + Redis Cache optimizations for example , something that on other platforms would require a large server and the store would still have low performance.

[mhcwebdesign]

I still don't understand why people are so desperate for using the OCmod way of modifying core files. I hardly ever had a need for it. Using events, and on occasion the decorator design pattern was more than sufficient for me, even for more complicated extensions.

[paulfeakins]

Because we don't want to use abstract design patterns (even when we understand them: https://www.antropy.co.uk/blog/adobe_flex/) and events that can't modify a method that's already been modified by another extension. As I pointed out in the forum, you don't have that many extensions and you haven't updated many to OC4, plus the ones you have updated are quite simple. For any given change, it is quicker, simpler, and requires less code to use OCMOD. OpenCart has always been about simple, readable code. Let's not ruin that.

[FelipoAntonoff]

The apps/modules you make may not need it, but many need OCMOD and its power and freedom. I even use it for versioning my products, I modify a file that marks the version of each installed App and then easily consult it using the API I created.

I also use it for visual modifications in Twig or to be able to modify original files to include new resources, the only way would be to directly modify the files or by OCMOD (XML) which is easier to maintain and has excellent performance as it generates a Cache of modifications and is easy disable and view the Logs.

An example of an App that uses a lot of XML is Validate CPF/CNPJ with Masks, not to mention our Checkout Pro which uses XML a lot, for example to exchange the native Checkout for ours, we also have an Edit Product data in bulk that we have to change the Admin Products listing and create entries and again it would only be possible with OCMOD or changing directly in the file which I consider a bad way for those who work with ready-to-use Apps.

[chulcha]

Don't deceive yourself.

Example
https://github.com/opencart/opencart/blob/560a16e00c419b90f12d8b460dab58acfdcb6b2f/upload/catalog/controller/product/product.php#L23C3-L23C39

Where sku in template?
I know how to get it using events.
But using oсmod I will get it much faster and safer

[mhcwebdesign]

Because we don't want to use abstract design patterns (even when we understand them: https://www.antropy.co.uk/blog/adobe_flex/) and events that can't modify a method that's already been modified by another extension. As I pointed out in the forum, you don't have that many extensions and you haven't updated many to OC4, plus the ones you have updated are quite simple. For any given change, it is quicker, simpler, and requires less code to use OCMOD. OpenCart has always been about simple, readable code. Let's not ruin that.

Well, most of our extensions haven't even been published yet on the OpenCart market place, but were ported to newer OpenCart versions nevertheless. On some of our customers' websites there are between 50 to 100 extensions, some of them quite complex, at times modifying the same OpenCart library class several times over. Proper event handlers, and decorators with object-oriented extensions are more robust than OCmod-based modifications IMHO.

Interestingly enough, the latest master branch of OpenCart now has a proper factory class, something I had suggested ages ago, and which will make things easier. I still wish that OpenCart would use correct namespaces based on directory paths for extensions, as is the case with other programming languages. And OpenCart would still need a more robust extensions mechanism, including upgrade features.

[FelipoAntonoff]

Regarding more resources for extensions such as Updates, it is indifferent to OCMOD or Event, you can create these resources regardless of how the improvement was made and I also consider it important to have something like that one day.

Regarding the use of Events + Decorators, why do you think it is more robust than OCMOD? Maybe it would be interesting for you to do an article with examples one day, in my view there is nothing more efficient in Opencart than OCMOD in creating, using and maintaining it, because in the end a cache is generated, it's like taking the original file and modifying it, no it is run in real time, unlike Event which is triggered and needs to run in real time.

Now I think both are good, they can be complementary, but the scope of use is very different, if I want to modify a file, I don't think, I go with OCMOD (XML), if I want a trigger like doing an action after a Request or something like that I can go to Events or OCMOD.

Now, of course, there may be Apps/Modules that do not need OCMOD or Events, using just MVC as a Controller + Model may be sufficient depending on the App/Module, leaving it up to each professional to use the correct tool for what they need.

[rsuchovsky]

Hello, please, what is the state of ocmod in the master branch, is it fully functional or are errors being fixed?

[danielkerr]

shou8ld be ready. i need to go through all the issues once i finish what im currently doing

[FelipoAntonoff]

Looking forward to the new version of Opencart 4 with native support for OCMOD, I'm finally going to refocus on Opencart 4 and update most of our main integrations.

Today our biggest use is Opencart 3 and then 2.3, but in the future it should be Opencart 4 and 3, especially since Opencart 4 will become more popular after native support for OCMOD, also making it easier to update Modules/Apps.

I'm happy that they decided to return OCMOD, I consider it one of Opencart's biggest differentiators along with high performance, ease of use and 100% modular.

Thanks Daniel 👍

[scottw-finao]

I'm trying - as designed - to change core files as little as possible. We had a problem when prior developers used joomla early on and modified it extensively. The system can't be updated to newer versions of joomla (or at least would require as much work as starting from scratch - which is what I'm looking to do with something like opencart)

But....

There are still some instances -- that are the fault of opencart developers -- as to why modifying core files with a modification system is still useful. Namely the lack of PSR compliance (or at least standardized php autoloading) through the use of the 'registry' of magic methods. The code becomes un-traceable in most IDEs and autofill suggestions don't work. Now with new AI autofill suggestions, this is becoming a much bigger thing.

With some toying around, I found that some simple php @Property lines can handle a lot of the magic method obfuscation rather nicely for software like phpstorm and others. It's built into PHP, rather standardized and easy to use. (as in WHY AREN'T THE DEVS AT OPENCART USING IT!?!?!?)

If opencart is going to insist on ignoring open standards for coding php and use their own proprietary magic-method registry, and if opencart is going to set up ways to use either events or third party addons like vqmod to change content on-the-fly, then they need to have some way to let developers that do use coding standards and the IDEs used by more than 90% of the php developer community. ( Which editor / IDE do you mostly use for PHP development? ) to make up for their shortcomings and 'fix' what they broke with their method of handling autoloading.

[scottw-finao]

Here's a scary thought - make it composer/packagist compatible then PEOPLE CAN DECIDE FOR THEMSELVES what to pair it with. As it is, any gains you may claim in being light weight are lost in that you have to learn yet another, compartmentalized, entirely arbitrary, completely proprietary scheme of autoloading, registry handling and proxying. Meanwhile, NOTHING is traceable, autofill features of just about every IDE don't work and some of the proprietary methodologies used aren't even optimal.
It's a nice platform, appears to have good support and has a wide variety of extensions available for it. But the more I dive in deeper to it trying to create custom extensions, the more it looks to me like this thing was started in 2000 and never paid any attention to what the rest of the php universe was doing. Sooner or later that's going to bite the devs on the behind and the proprietary 'our way or the highway' approach won't even work in PHP. That's the problem with our current platform. I'm looking for something compliant with the language it's built inside of - not re-inventing every pragma as the devs saw fit.

[scottw-finao]

I've never even considered writing an object this way, so I really don't know the answer to this question but would be curious? When that registry (with all the instances inside of it) is attached to every new instance created, is that registry a shared object? I don't see use of '&' and I'm not entirely sure how PHP malloc handles object instances being cross-attached like that.
If it's not, has anyone examined the overhead of attaching that back onto everything? If it's shared, yeah that would be a great way to reduce a memory footprint. If it isn't, every new instance would exponentially increase memory usage

[markimax]

Adding an external framework to OpenCart is a mistake. Because frameworks are often heavy and overly excessive. OpenCart are good because they are fast and not overly excessive. OpenCart itself is already a framework.

[punitkumar]

Here is explanation, how PHP malloc handles object instances.

https://www.toptal.com/php/objects-references-php-memory

Also, a worth reading
https://www.phpinternalsbook.com/php7/memory_management/zend_memory_manager.html

[FelipoAntonoff]

It would involve a lot of changes to try to use another Framework over Opencart, but anyone can do it, for example I have previously added an ORM, a Redis session, among other features that improve the Opencart core for my uses.

Now redoing Opencart to add Laravel or another Full Stack Framework could be a mistake, but it would support some components if it were Symfony, as I think it is better documented, separated by components and even used by Laravel and other projects, but it would require a lot of reformulation of Opencart depending of the components used.

As for the standard, yes, Opencart follows a purer PHP standard, so much so that the internal Framework is a Micro Framework that uses Controller and the path as the name of the controller and its functions.

I just wish the extensions were more isolated, I believe that in Opencart 4 they improved this by staying in the extension folder, which helps a lot instead of being mixed with the controller and model of the catalog or admin of the Opencart core. It would also be nice to have auto-completion in the editors, some libraries have this feature, but it really lacks it in general, like let's use a model, a library like cart, etc., there won't be auto-completion.

Now I believe your points are better in a new post. Now something I learned from decades of development is that the most adopted standards are not always best for all cases. Sometimes the purer, simpler and closer to the language the better, for example Opencart, a good PHP programmer can create good extensions after analyzing the native ones and some others, not requiring a course or learning a complex Framework like Laravel and the like.

Magento and Prestashop actually use Symfony, which is a great Framework, but to use them, it requires learning it, which is much more complex than learning Opencart for example, which is why Opencart is today the most modular system in E-commerce and easier to create good improvements. It's actually the only one that has OCMOD/vQmod, something magical where we can change native files without touching 1 line directly in the original code and still generating a cache. That's why when Opencart 4 came out without OCMOD, I considered it a big mistake and I'm happy that OCMOD will be back soon and hopefully forever, it or a similar tool.

Today Opencart still uses some external libraries, which is an evolution in part because it doesn't have excess but rather uses the fundamentals like Twig, Guzzle, some Symfony components, perhaps it could use Symfony's Request and Response (HttpFoundation), But it would require a lot of change I imagine.

[mhcwebdesign]

I've never even considered writing an object this way, so I really don't know the answer to this question but would be curious? When that registry (with all the instances inside of it) is attached to every new instance created, is that registry a shared object? I don't see use of '&' and I'm not entirely sure how PHP malloc handles object instances being cross-attached like that. If it's not, has anyone examined the overhead of attaching that back onto everything? If it's shared, yeah that would be a great way to reduce a memory footprint. If it isn't, every new instance would exponentially increase memory usage

The OpenCart registry consists of only one instance, being referenced from different places and classes. It is an associative array of mostly singleton instances, such as cart, user, etc.

[scottw-finao]

oh cool, then that explains the use of the registry and is smart. but why break psr4 and why not use the standard autoloading methodologies?

[scottw-finao]

talking about wierdnesses like this. The existing framework seems fine... Opencart\Catalog\Controller\Item shows up in (opencart)/catalog/controller/item (I'll ignore the breaking of case sensitivity for the moment)
But then if you want to build an extension, rather than having a directory 'extensions\catalog\controller\item' under it resulting in Extensions\Catalog\Controller\Item, you wind up with Catalog\Controller\Extension\Item - wtf?!?!
Then you get other wierdness with camel-to-snake and snake-to-camel conversion. But wait, there's more. Referencing by the magic method uses stuff like model_catalog_category, but hold on - is that admin or catalog? There's a class in both! Even if you use scopes, you now can't (easily) use phpdoc to add traceability without creating multiple 'wrapper' classes for each namespace. The same occurs in extensions but with similar wierdness in the naming: model_extension_{extname}{exttype}{extname again?}. At least this is what i'm seeing in many packages I download for examples.
But ok, whatever - now try to - woops, I don't seem to see referencing for the autoloader on controllers or language files using the pragma - instead I have to use load->controller() or load->language(). It looks like you can also load models that way, but have to replace the _ with /. wth?!?

smh

If only there was an autoloader BUILT INTO THE LANGUAGE

[mhcwebdesign]

You are right, extensions do not follow the folder structure in their namespaces. I pointed this out to Daniel ages ago, but he wouldn't change it.

[hayden-t]

ocmod using database storage for xml was terrible to develop for, no source control and had to interface with the db to code live, i love vqmod

[danielkerr]

fine. we can have a ocmod xml folder and have the db just link to the files.

[hayden-t]

also the logging output was very difficult to use

[hayden-t]

also i did think the event idea was a good idea, and had its place, i just havent gotten around to learning about it yet

[danielkerr]

i dont give a fuck

[hayden-t]

I was actually trying to give you or who ever wrote the event system a compliment...

[hayden-t]

something that might be useful would be if in the admin panel for each xml/mod it gave a list of modified files and lines, and could even detect if different mods edit the same lines to warn of potential conflict