Add OCMOD (XML) in Opencart 4 - Suggestion

[FelipoAntonoff]

Hi, congratulations Daniel , team and all contributors, I was looking forward to Opencart 4 :) and to be able to create modules and themes for it.

I found it interesting to have fewer base extensions, so each user installs the desired one, I just really missed OCMOD (XML) I consider it the great and perhaps the best differential of Opencart 3 and 2 and basically every module is made using it, even if it's just to inform the version or other details.

Events is interesting, but I consider OCMOD much more powerful, with it I can change any Opencart file, be it controller, model, view or other without touching the original file and best of all, except file dependency, I can even assemble one controller without creating a file for it for example, it also facilitates maintenance and editing.

In the View itself is the great power of OCMOD, I can do it by installments in the products, let me know, change CSS, put JS in several desired places, in short, if there is a line to be researched to be done with OCMOD, since Event I believe that be much more limited.

I would recommend going back to OCMOD, I don't see the point in taking the same, even more being a great differential of Opencart and used by thousands of modules, much easier to keep 1 XML file than several PHP and Events files and I believe that Events have limitations mainly in the view , I don't know if it will be possible in any line to add something, remove something or change something.

It will also be very complex for most developers to maintain 2 totally different modules between Opencart 3 and 4, since in 3 most use OCMOD.

Every module I create has at least 1 XML (OCMOD), because I use it to inform the version, I can change the controller I use to pull the Module version without changing 1 single file directly and everything created with Cache generated by OCMOD, no excess of if or for, a simple Cache with the changes applied.

I believe that most of my colleagues also almost always use OCMOD, because it avoids excess files and having to move directly in certain files, I think it's so good, that since version 1.4 of Opencart I've been using vQmod and then OCMOD in 2 and 3 and I've always preferred over event, hooks and other ways, because we have more control, more freedom, easy to disable or change and it's also easy to check the Not Found and adapt to non-standard themes, which unfortunately is the majority.

[cartbinder]

+1

[mhcwebdesign]

OCmod is a curse, and I am glad it's not part of OpenCart 4 anymore! It's usually poor quality extensions which tend to make excessive use of OCmod instead of using event handlers.

[FelipoAntonoff]

I can only imagine how will these developers hammer nails with a microscope using events :) And suffering to debug these events.

Wait and see.

I also wonder lol, something that should be simple can be very complex.

[FelipoAntonoff]

@cartbinder Curious for certain more complex uses of Events, but I still don't think anything can replace 100% OCMOD, unless something that does it similarly.

The things I like most about Opencart:
OCMOD (xml), MVC and the ease of working with it, not to mention the performance and simplicity of course.

[cartbinder]

Of course, OCMOD was very easy to use and flexible. So it was even sometimes possible for a non-developer to make changes in their store. They only needed basic instructions.

Complex modules will be hard to create just via events. There would be a need for Ocmod or Vqmod.

[osworx]

So it was even sometimes possible for a non-developer to make changes in their store.

Seeing the results every day!

Complex modules will be hard to create just via events. There would be a need for Ocmod or Vqmod.

No, with a few lines nearly everything is possible with events.
OC- & VQMod are outdated.

[aris9ian]

Events will basically do the same as VQMod or OCMod, but compared to both, the modifications (the edited files) **are stored in the database** instead of new files in your folder system. The system itself checks **with every call this database** and fetch the stored code - the original files will be untouched.
@osworx Is this ok in terms of performance?

[mhcwebdesign]

Perhaps a better approach would be to introduce more triggers, especially for library classes.

With regards to template changes: This can be tricky either way, whether OCmod or event handler, because of the need to find certain HTML elements in the DOM tree, for them to be modified, inserted before, or inserted after. This might be a scenario where Twig's built-in mechanism of template inheritance might come in handy, see e.g. https://twig.symfony.com/doc/3.x/templates.html#template-inheritance

The good news is that the lack of OCmod discourages developers from doing quick unneeded dirty template changes.

[FelipoAntonoff]

It's something to think about, but I find it difficult to replace OCMOD so well for certain uses, especially in the view.

I haven't studied Events very well, but I think it's because of triggers, there will be things that are almost impossible to be done by Events I imagine or there will be an excess of triggers and codes just for the event to be triggered and I have no idea how it would be dealing with conflicts, in OCMOD we have the very complete logs and it is nothing more than a change saved in the cache, I find it difficult to overcome this simplicity and resources, the Event has its use, but I don't think it can replace 100% the use of OCMOD and if you want it is the best way.

I believe Twig's idea is just another complexity for developers, OCMOD is just xml and nothing else, any developer knows how to deal with XML or learns in a matter of minutes or hours and how to use it more correctly with experience and time.

I'm curious how Events will be able to handle any line or almost any line in a view and if it will be more efficient than OCMOD, which generates a simple cache with a copy of the altered original.

[mhcwebdesign]

We have been using event handlers for quite a while now, even for changes to templates, and from our experience in most cases there was no need for OCmod. I have seen cases where extensions do unneeded changes to core files, a prime example for this is the Journal3 framework.

[FelipoAntonoff]

I understand, if you need to change the default files of the platform or view, with Event I think it has a big limitation, as far as I understand it's a simple trigger.

OCMOD is much bigger than Event in terms of features and simplicity of use, it looks for a line and does something simple like that, in the hands of a good professional it makes a product with great quality.

I'm worried about the Events limitation, there will be a module that won't be possible to be created due to this or a guide will be needed to teach the client to change directly in the file what I consider something bad.

OCMOD has some advantages:
Generates a Cache, Logs with Not Found if not found the line, easy to change, disable or remove.

[mhcwebdesign]

I might add that, provided there is sufficient demand for it, then I'll port our Integrated VQmod (https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=19501) and our Override Engine (https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=8588) to the new OpenCart 4.

[FelipoAntonoff]

Very good, I also think if I need to make a fork or an OCMOD module or something like that, because I'm almost 90% sure that a lot of modules won't get just with Events and without changing directly in the file.

Let's see if the Opencart team doesn't rethink, OCMOD is just as good if used correctly and the better it generates a cache, while Event I believe has a higher performance cost.

[IP-CAM]

It's a foreseeable Fact, that VqMod will further be used in latest OC v.4 Versions, so, also still adding OcMod, will, at best, result in beeing confronted with the same problems, as many older Version OC Users already experienced in the past. So, it really makes not much sense, to add OcMod again, considering the known fact, that VqMod had some advantages over OcMod, according to what I have been reading about. Just to add my Swiss Cheese to this ...
vqmod/vqmod#165

[FelipoAntonoff]

vQmod is very good too, OCMOD is basically a fork of it, but it was native and this was its biggest differential.

I find it strange after Opencart 3 and 2 and making OCMOD very consolidated and used, they took it out of nowhere, even though it is still somehow possible to use vQmod.

I keep imagining developers updating their XMLs to Events and discovering that some of the features will probably not be possible and will have to go straight to the :( file, I find it a little worrying, but I hope I'm wrong.

[osworx]

Quite funny that after nearly 3 years, the "folks" see that Events are the only proposed method to work with OC 4 ..
Were have you been all the time .. ?!
Now after the "final" release, all are coming out of the "holes" and post nonsens.

Time to wake up - rest in piece VQ- & OCMod.

[osworx]

Nobody reads forum. Even Daniel doesn't :)

Nobody pays attention to bugs and propositions here, where development is discussed, for years.

Nobody whining. Just doing their job.

Instead of whining, that everybody is whining, you could try to help us to convey some ideas to Daniel. But you only repeat "where you have been all these years" :(

Basically I have to agree what you write.
But, where are all your "ideas" the last 3 years .. ?
Seems that nobody was able to read Daniels announcement a few years ago.
Additionally reading the forum threads.

Now, after the - quick and surprisingly - release of OC 4.0.0.0 (without any proper announcement for developers and translators !!), the folks arguing that OC- & VQMod was - and is - so fine .. so good .. where are they .. ?
Would say: too late.

On the other hand I would say, we all here know Daniel ..

[osworx]

@chulcha is that all you can do "thumbs down"?
No participation the last few years, no commits, no ideas, etc. ..
And now you are awake?

[chulcha]

When I do not receive feedback, I am not interested in discussing anything.
When the author of the project tells me that I'm "stupid", then I'm not interested.
When some contributors do something senseless (spam), then I'm not interested.

[stalker780]

Basically I have to agree what you write. But, where are all your "ideas" the last 3 years .. ? Seems that nobody was able to read Daniels announcement a few years ago. Additionally reading the forum threads.

I have discussed events here several times.
I have experimented and tested OC4 events and extensions for more than a year. Even my one year old bug reports were hardly applied just a few days before release.
https://github.com/opencart/opencart/pulls?q=is%3Apr+author%3Astalker780
Most were simply ignored or closed without discussion and proper testing.

As a result - I have created an OC4 VQMod Manager more than a year ago for myself and made it public now.
https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=42736
https://github.com/stalker780/opencart-vqmod-manager

Nobody wants to waste his time, because most bug reports and proposals are ignored by Daniel.
He has his own point of view on OC future, and that's great.
But OC is not only a core. OC is mostly a bunch of extensions.
And in my point of view, Daniel must pay more attention to a simplicity and compatibility of extension development.

Events do things only worse.
If you install 2-3 extensions which override same controller function, I want to see what you say and how are you going to debug this.
And when there is a hell of 30-80 extensions, each producing dozens or maybe even hundreds events, you will get tired clicking pagination buttons in events manager while debugging :)

Yes, they may come handy in some situations. That's great to have another tool for developers.
But events cannot replace OCMod/VQMod. They do not cover all core functions, even libraries. They mostly require to totally duplicate core functions just to inject one line of code or modify SQL. They make simple things very complicated, hard to debug and produce a lot of conflicting extensions.

I am looking forward to see Journal4 based on events )))

[FelipoAntonoff]

@stalker780 Exactly, they are development options, with OCMOD being more complete than Events, in short, Events is a part of what OCMOD does and OCMOD does everything else.

Imagine the Journal with Events lol, I already think it's too bad to deal with it with OCMOD which helps a lot and we can see the Logs and make the necessary adjustments, now with Events I don't even want to imagine these non-standard themes how they will look, the question is very simple with Events to change any single line of code, if so it can be viable, but even so I want to see thousands of devs updating everything to Events, it will delay too much the release of modules for Opencart 4 and its migrations and the ones that Events cannot be resolved, it will have to be overwriting the original files which I consider to be a bad thing.

[FelipoAntonoff]

@osworx Events will never completely replace OCMOD, they are very different tools and with different uses, what I can do with OCMOD is not the same thing as with Events, but I can do everything that Events does with OCMOD, that's the point, I also consider the repository as a good place to discuss this kind of idea.

I'm just suggesting something that I consider essential, if someone proves to me that Events can do everything that OCMOD does and with the same quality and performance, then it would make sense for Events to replace OCMOD, but Events has been around for years and I kept using it without problems OCMOD, because I think it is much superior in many uses and always got 100%, there is something more beautiful than being able to change any location of a code without directly messing with it, generating a Cache, logs and being easily possible to adapt to a time, disable or remove.

The main point is OCMOD > Events, so if you want to discontinue OCMOD I think you would need a tool as good and complete as it could be, it could even be an OCMOD with another name.

And a flaw of many is to think that OCMOD is related to a bad module, when in fact a bad module depends 100% on who makes it, I make very good modules and I love using OCMOD, I have been working with Opencart for over 10 years since 1.4 and his great differential was always being able to make XML that does magic without touching 1 line of code in the original.

I haven't seen debates about discontinuing OCMOD, but I still think it's worth rethinking about it, there are thousands of modules that use it and that Events won't be able to meet 100%, I want to see create an Event that changes the Opencart library, which changes in various locations in the View, which changes a new Controller without prepared triggers, etc.

[cartbinder]

@osworx Amazing. We will wait to see it. Or maybe Daniel helps us using API documentation.

I have tried using search-replace in the event system. But it also needs unique values to search. Which in the above case might be possible. As it is the product page. But it would still work just on the default theme. If the theme changes, add code for that as well. There might be thousands of themes. How to do then?

But if same thing you have to do on the list page like a catalog page. Where there will be a lot of products. Search replace via events won't work. As the prices can be the same.

[FelipoAntonoff]

@osworx Ok, I'll wait, I think it's so good, search for a line and that's it, do the desired rest, curious to see how Events do something similar.

@mhcwebdesign I wonder if it's not to complicate more, because in OCMOD I think it's so trivial to do something like that, but curious to see how it works in the View with Events, if it's something simple it can be interesting, now I still think OCMOD is the best solution, because it generates a cache, hard to beat the performance of a cache, unless Events also generates a cache which I think is unlikely.

[cartbinder]

Theme developers are the worst offenders with regards to OC standards anyway.
Very true.

The end-user might be purchasing the theme from X websites. Saying them "Nonstandard compliant theme" is a good solution?
I can only imagine fighting, arguments, and refunds. And a waste of time.

Still, we are unable to find the right direction I guess.

I think a mixture of events plus ocmod/vqmod would be great.
And then adding more functionality to the event-based system with documentation.
So developers can refer to that.
And then removing the Ocmod/Vqmod.

[osworx]

I can do above mentioned modifications easily enough using event handlers, with an event handler for 'catalog/view/common/header/before' and 'catalog/view/product/product/before' triggers. This was discussed in more detail on the OpenCart forum in the past.

For example: https://forum.opencart.com/viewtopic.php?f=144&t=227710
https://forum.opencart.com/viewtopic.php?f=24&t=211914
https://forum.opencart.com/viewtopic.php?t=221533

And that is what I already mentioned earlier this day: where have you all been during those discussions .. ??

[FelipoAntonoff]

@osworx I don't use the forum much, interesting topics, but it seems much more complex to use Events, in the end a file_get_contents or something will be used and a str_replace, I can't imagine where this is better than OCMOD that generates a cache, not to mention the delay that it must cause in performance if you don't cache it, now of course you can create a mini module or library that improves the Event for this use.

I'm also curious about how to deal with conflicts and logs, it seems to me a way to make Events more complete, but apparently raw to deal with the View, but it's a start.

It seems to me that we created a micro OCMOD to deal with the View in Events, but in a very raw way, probably without logs.

Now I don't know if it's possible to change PHP with Event, like any line of a Controloler, Library or Model, because it is normally added before or after, so the code has already been run, I still think that Event is just Events like there are in others platforms, it's not a bad thing, I think it's very interesting, but OCMOD seems to me to be more complete and easier to use for certain cases, one basically complements the other.

[bankeris]

Those who are defending OC 4 for removed OCMOD probably doing only Tutorial Extensions. What is benefit from removing OCMOD ? I was waiting some upgrades for events as it was announced that OC4 wont have OCMOD, but nothing added. Funny how much code needed to change TWIG with Events. RIP OC 4.0.0.0

[osworx]

Those who are defending OC 4 for removed OCMOD probably doing only Tutorial Extensions. What is benefit from removing OCMOD ? I was waiting some upgrades for events as it was announced that OC4 wont have OCMOD, but nothing added. Funny how much code needed to change TWIG with Events. RIP OC 4.0.0.0

Don't know who you are .. but as can be seen, you are a real professional.

[bankeris]

Whats the problem wih you?

To change single line of TWIG we will need to use this old school method, its normal ? :) unless i missed something and there is some more simple way.

https://forum.opencart.com/viewtopic.php?f=144&t=221533

[osworx]

Whats the problem wih you?

The problem are people like you!
The highlighted forum thread simple does what OC- & VQMod is doing.
The poster proposed a solution to be added to the core, which was declined by Daniel.

Events - as they are currently implemented - are not optimal, but there is no reason to use further OC- & VQmod because you don't understand how to use them.

And the general "problem" are people like you - after 3 years of "development", several months of discussions in the forum, now you are "coming out" of your holes and posting useless comments about something which is fact since many months!

[bankeris]

Can I see "several months of discussions in the forum"? I probably missed this one ty in advance :)

[FelipoAntonoff]

@osworx The detail is that OCMOD works 100%, just a simple XML that has been used since version 1.4 of Opencart and mainly in 2 and 3.

I don't think there's anything simpler and better, it looks for a line, does something, as simple as that, generates a log, marks the lines in the log that did not enter and generates a final cache, this is perfect, it can be improved and evolved of course, however , has been operating for years and is well established.

Events is Events just that, it can be improved to have a type of OCMOD inside it, but it shouldn't be the use of Events that, which basically serves to run something before or after a certain trigger.

While OCMOD's proposal is to change basically any original line of code, ideally if it's a single line.

I've never seen a platform with a better solution than OCMOD or vQmod which is Opencart's great differential, it's not something modern and doesn't need to be, but it's something totally time-tested and especially fully functional, now if Events or another name of tool does something with the same ease, great performance too, I just think that Events should be used for what they propose, both are complementary or you can just use OCMOD that meets almost all use cases that need to change something in some file without touching it directly.

The idea of ​​the topic is a suggestion, because I consider it a mistake to remove OCMOD while there is nothing as good and complete as it to replace, it would be more viable to improve it, if the main Opencart developers were asked and that they know how to use OCMOD correctly (xml), I bet most would vote to keep it or improve what they already have.

We just need to ask a few questions:

• Does everything OCMOD does?
• Does it with the same ease and performance?
• Easy to resolve conflicts and adaptations to the theme?
• Easy to disable and prove to the customer that a store error has nothing to do with the module?
• Easy to install, update, remove or edit?

If the answer is yes to all questions great, we have a tool as good as OCMOD, otherwise it would be a mistake to take OCMOD out in my opinion.

[agatha65]

OCMOD / vQmod is the Opencart biggest competitive advantage.
Without it, Opencart's popularity would decline dramatically.
Period.

[FelipoAntonoff]

It looks like vQmod will soon have a version for Opencart 4.
If unfortunately you don't have native OCMOD (xml) anymore, we will have back the dear vQmod that gave rise to OCMOD, but it was always active.

So cases that Events can't handle, we'll be able to solve with vQmod so we don't need to change directly in the file.

[nexadomain]

It is declined.
I migrated my 2 clients' websites to Magento since the release of OC v4

[FelipoAntonoff]

It is declined. I migrated my 2 clients' websites to Magento since the release of OC v4

I imagine that the measure is a bit radical, I would recommend staying on Opencart 3.0.3.8 until Opencart 4 is more stable and suitable and even OCMOD, if necessary, can use vQmod or even go on Opencart 4, but correcting possible bugs.

Magento I believe the complexity and demand for resources is much greater, even more so for stores below a few million in revenue per month.

I consider Opencart the best solution for small, medium and even large stores, ranging from stores that earn 0-10 thousand per month, to stores that earn 10-100 million per month or more.

The profile of these 2 customers would be from which range?

[IP-CAM]

VqMod for OpenCart v.4.x and an OpenCart v.4.x VQMod Manager already exist:
https://webocreation.com/how-to-use-vqmod-in-opencart-4-installation-configuration-and-example-use/
https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=42736

[FelipoAntonoff]

Yes, we still have vQmod, too bad it's not native.
I'm curious 1 year after the launch of Opencart and still nothing about a replacement tool, in any case we have this option, maybe one day Opencart will have OCMOD again or something similar and improved, I find it curious that there are colleagues who blame code bad with the tool, now if the person on the other side of the table makes bad code, it will be bad with OCMOD/vQmod, Events or worse it will do it directly in the original files.

[MikhailShemelin]

• Events can less than OCMod
• Events are more complicated to debug than OCMod
• Events have worse performance than OCMod

But no worries, if Opencart 4 have no native OCMod in it, every store will just have OCMod/vQmod installed additionally.

[FelipoAntonoff]

Yes, it will be the way, we will have to install vQmod for cases that Events does not meet.

[BuslikDrev]

	//$this->db->query("UPDATE " . DB_PREFIX . "event SET sort_order = (sort_order + 1)");
	//$this->model_setting_event->addEvent('mymodule_controller_before', 'catalog/controller/*/before', 'extension/mymodule/event/mymodule|controller', 1, 0);
	public function controller(&$route, &$args, &$output = '') {
		if (!empty($this->request->get['route']) && $this->request->get['route'] != $route || $this->config->get('action_default') != $route) {
			if (version_compare(VERSION, '4.0.0', '>=') && !defined('DIR_CATALOG')) {
				$trigger = $route;

				// we control everything
				$action = new \Opencart\System\Engine\Action($route);
				$output = $action->execute($this->registry, $args);

				if ($output) {
					// off event after
					//$this->event->trigger('controller/' . $trigger . '/after', [&$route, &$args, &$output]);

					// off controller
					$args = array($output);
					$route = 'extension/mymodule/event/mymodule|controllerFree';
				}
			}
		}
	}

	public function controllerFree($output) {
		return $output;
	}

[BuslikDrev]

speed "OcMod" str_replace = speed "Theme Editor (Cache Theme)" str_replace

[FelipoAntonoff]

I didn't understand your answer, do you think the time to process the cache generated by OCMOD is equal to the str_replace used by an Event realtime?

If so, I don't think so, the time to generate the Cache yes, but the final performance does not, because it is in a cache that is ready for use, since Events it is run realtime as far as I know, so it would need a cache in Events to stay close and still would probably be lower in performance if you have N visual Events in the same trigger and file, as it would be N mini caches to load vs in OCMOD a general cache of the twig file.

[BuslikDrev]

/admin/index.php?route=design/theme

[FelipoAntonoff]

I thought of two possible solutions:

1. Create an XML migration tool (OCMOD) Opencart 3 or up to 2.3.0.2 for Events
   It would even serve to validate if Events works 100% as a complete replacement for OCMOD in Opencart 4 or if it would be necessary to reformulate a new tool or return OCMOD to meet the 100% compatibility of OCMOD resources

I don't know what stage Events is in and as I've commented before in my view its use should be for triggers only, I would even give it another name if it's to have a type of OCMOD inside rs and it would be necessary to be able to deal with adaptations/conflicts easily.

The cool thing about a migration tool that those who like XML could continue creating XML and the converter would turn into PHP (Events or the name of the new tool)

2. If it is not the intention to add OCMOD to the Opencart core, even with its pros and cons, then maybe an OCMOD module should be made, as it was done in the past with Opencart 1.5, for example with vQmod that did not come in the core, but was installed in Opencart as a module demand.

I prefer to avoid 2), but if it is not possible to return OCMOD to the base and 1) is not possible/feasible, it may be the single most practical option to keep modules made in OCMOD working in Opencart 4.

[FelipoAntonoff]

Guys, it looks like vQmod will soon have a version for Opencart 4.
If unfortunately you don't have native OCMOD (xml) anymore, we will have back the dear vQmod that gave rise to OCMOD, but it was always active.

So cases that Events can't handle, we'll be able to solve with vQmod so we don't need to change directly in the file.

[FelipoAntonoff]

Hello, guys, how has your experience been with vQmod, Events or how have you managed to deal with the detail of not having OCMOD in Opencart 4 anymore?

At the moment I haven't started to move the modules to Opencart 4, I will probably use vQmod, while there is no way to have all the features of OCMODs in Opencart 4.

Has anyone using vQmod been doing well in Opencart 4?

[mhcwebdesign]

Has anyone using vQmod been doing well in Opencart 4?

Yes, we have. No problem using event handlers.

There is no need for OCmod or VQmod.

Of course, there are still other bugs to be addressed in OpenCart 4 before it become usable for live sites.

[FelipoAntonoff]

Has the performance noticed the same as with the use of OCMOD? Because Events works by trigger, so it requires a process in PHP, while OCMOD generates a cache with the original modified file.

Another point has managed to circumvent changes in php files, such as controller, model, library and etc? What about debug or conflict has not occurred? Because I imagine that in the case of Twig it is necessary to create a mini system and use replace, so I wonder if two or more modules change the same Twig and possible conflicts.

For now I must use vQmod, I will start to focus more on Opencart this year, because in previous tests I didn't feel it was stable for Production and I still think the biggest mistake was taking OCMOD without having another replacement tool as good or better.

[FelipoAntonoff]

I did some tests with the use of vQmod in Opencart using the same OCMOD XMLs and it got directly successfully 😃 👍 💯
vQmod releases: https://github.com/vqmod/vqmod/releases, Thanks to the creators and maintainers 🤩
It seems that it will be possible to use vQmod, it would be interesting to have a native tool, but while we don't have it, it's a great option.

Maybe they could go back to OCMOD or something like that, but as an optional use as it always was, whoever wants to use the X, Y, Z tool, giving more freedom and options to the developer.

I will continue using XML for what is recommended in conjunction with model, controller, library and etc as I have always done in more than 10 years of development with Opencart and I can guarantee it is excellent this way and without touching 1 line of code in original files of the Opencart, leaves the code 100% isolated from the Opencart code and facilitates maintenance/support, in addition to high performance, as a cache is generated with the changes.

Just a recommendation to avoid using the Administrator's theme editor, as it never worked with OCMOD and should not work with vQmod, as it saves changes in the Bank and not in a file.

[mhcwebdesign]

It's good that OCmod got abandoned, XML is a markup language for documents and protocols, it's not a programming language. The number of poor-quality OCmod and/or VQmod based extensions is countless.

[FelipoAntonoff]

Removing OCMOD without a replacement was a mistake and perhaps the idea was due to problems of professionals who do not know how to use the tool and not the same, after all the end result is just the cache of the original file with the changes, much better than working directly in the original file or something that runs realtime.

The XML is for markup, configuration, and other uses.
The OCMOD/vQmod XML code is just PHP, HTML, CSS, JS and the like, what goes inside the add is independent of the XML, the XML being just for the markup, it could be direct PHP or another format.

Being used XML or another way is indifferent, I imagine, the biggest detail is if there is any other tool as good as or better for Opencart currently and in my view it doesn't exist :( and unfortunately Events is not.

About the quality of extensions, sorry, but it has nothing to do with the use of OCMOD/vQmod, I'll go even further, the quality is the same, because OCMOD is just a tool that many people don't understand, the quality of the XML and the code added depends solely on the developers, I do it with the same quality using XML or editing directly in PHP, but of course you have to know how to use the tool and really not every Opencart developer uses it in the best way, some make the wrong use of the offset, index, non-ideal line searching and so on, but we can't blame the tool for lack of developer skills. Modele Library can also be used in XML, even suitable for large codes as it would be without the use of OCMOD.

Now it takes better curation on the Opencart Marketplace and also on other developer sites and also the developers themselves to make a code with more quality and care, focus on quality and not price. Something that urgently lacks curation is themes, I get tired of seeing bad themes and not just for Opencart, that's why until today I always indicate the native theme or changes to it.

Some advantages of OCMOD/vQmod:

• Being able to change at line level without touching the original file
• Cache usage with changes made
• Logs
• Easy to use and maintain
• Easy to understand, learns in a matter of minutes/hours and the most correct use with time and experience
• Serves for Back End and Front End, excellent for module that changes the visual

Advantages of Events:

• Can use direct PHP
• It uses a trigger, but it does not work at line level like OCMOD/vQmod

They are different tools, OCMOD does everything that Events can do, but Events cannot do everything that OCMOD does, even because they are tools with different purposes and that can even be used together.

Events or any other tool will only replace OCMOD/Vqmod when it meets all use cases and with better quality and performance, we also have to think about ease of use, performance, support and maintenance.

My question is, is there any other tool in Opencart today that replaces OCMOD 100% natively and with the same ease of use, performance and maintenance?

I'm always in favor of evolution, OCMOD or any other tool can certainly evolve or even make a new one that does something better, but Opencart still doesn't have it, so I thought it was a mistake to remove it without having a replacement the height.

[decMuc]

Yes, you're absolutely right! There are countless terrible modules for OC.

However, most of these providers also have tons of negative comments. It's just like Amazon. You don't have to use/buy it.

But what else is there against it?

That followers of OC3 who aren't the great development pros start tinkering with the source code just because they want to stick with their beloved OC? Is that the better solution? Probably not!

And what happens when someone gets the idea to write an OCMOD4 module? Then maybe even opens a site where old OCMOD developers can sell their stuff for OCMOD4? That's almost a brilliant business idea! Give away OCMOD4 and then wait for developers to fill your pockets with commissions. And I'm sure there would be plenty of them! The only difference is that it will get EVEN WORSE, and Daniel won't get a piece of the action.

Maybe it's worth asking the group if someone has the inclination to write an OCMOD4 module? A kind of mix between vQmod and ocMod. Perhaps with a few improvements...

I'd rather go for a qualified integration!

And hey, not all packages have been crap with OCMOD!

[DanielHatano]

When OCMOD is back?
Opencart must suffer a FORK.
Version without OCMOD and with OCMOD.
Let the market decide.

[FelipoAntonoff]

Daniel commented that he will return, he should return in the new Opencart 4, hopefully soon.