Evolution of the event system

[v5mvidal]

Congratulations on removing OCMOD @danielkerr!

OCMOD was a nice feature, but let's face it, it was just an amateur feature that caused more problems than it helped.

We had to create an OCMOD Editor to be able to solve the dozens of problems with conflicts in poorly made modifications, follow the Editor:
https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=22015

That's why we're happy with his departure and now ready to help with the evolution of the event system!

This topic is to discuss ideas on how to make the event system more practical, because without a doubt this is the future of OpenCart.

We will engage in evolution as we love OpenCart!

[danielkerr]

correct. to many issues for newbies fixing generated code rather than the xml file. its to much messing around look for whic line of code causing issues.

[FelipoAntonoff]

Daniel, in the case of adaptation, I usually just check the Logs, I see the Not Found and I solve it, if it's a PHP file it's super simple, because it can be an Opencart fork that has changed or some formatting, I even think it's very good the Log has the line number, search text and other details.

As for View, the same process, only we have to analyze the theme a little and there are some that are sadly so bad and really work, who knows, maybe an idea in the future of curating the themes, to encourage themes with better code and that are closer to the Opencart standard, it even has a theme that uses include, this complicates a lot.

Now I can't currently see how Events would be better than OCMOD at this point of conflict/adaptation, because if we go to see Events I consider it a tool that tries to solve another issue and does it well.

Have you ever thought about creating a new type of OCMOD but directly in PHP, maybe a way for us to define the operations the same as OCMOD in PHP, maybe it would be a good option, but I didn't think about the complexity of it and if it would be viable, I think the structure is good of XML, I just feel that the IDE really lacks being able to process the internal PHP for formatting and validation, but with Model we can easily circumvent this for larger code that has its own Model.

[FelipoAntonoff]

Currently, consider that Events is proposed to be triggered by triggers and perform an action before or after, for example, the trigger that triggered it, such as before loading the product view, after a certain change in the database, etc.

But I don't know how it would be used as a new tool in place of OCMOD the OCMOD use case which is basically for any line of PHP and View.

It would be good, maybe, examples of Events uses converting XML files with trivial tasks for veracity of using Events and how to improve the use of Events and how to improve to be able to convert any OCMOD of Opencart 3 to itself and in a way that maintains the same performance and ease of creating and maintaining XMLs, even a tool that can migrate XML from Opencart 3 to Events or a new tool that will replace its use in Opencart 4 would be interesting.

I can also help with these tests, I have a lot of XMLs with the main use cases.

[TheCartpenter]

Not sure how it helps evolving the events when there's an install.xml (OCMod) file inside the ZIP file for OC v4 ...

[FelipoAntonoff]

I have a different point of view on OCMOD, I consider it the best tool of Opencart and its biggest differential in development, I've even been using vQmod and then OCMOD for more than 10 years in more than 100 products, it always worked very well even more later that OCMOD became more mature, at this time it was only necessary to deal with a non-standard theme, adapt the line or when the client itself modified an original Opencart file or used a fork version and even then it was super easy to adapt, due to the Log, it is enough see Not Found and adapt.

Perhaps the point could be to encourage the correct use of the tool, avoiding excess offset and index if possible, in addition to doing it with fewer operations, if the professional is good, he can do magic with OCMOD when it needs to be used, if there was a way for the editor to recognize the PHP inside would be perfect lol, at this point a tool that is code directly in PHP can have advantages like PHP error formatting and validation, but using Model in OCMOD was another correct way to use it mainly for big PHP.

It really has a lot of bad modifications, some with meaningless operations and very wide searches, now bad code depends on the professional, if not through OCMOD it will be straight in the original files, Events or any other possible way.

I think the biggest problem is the non-standard themes of the platform, no matter the development tool, if the theme is of low quality and non-standard of Opencart, conflicts, problems or failure to get a visual module will occur.

Even I don't currently see how I would deal with conflicts and adaptations to themes easily, but of course it is possible to improve even more if it becomes a tool that goes beyond Events, but I would recommend in this case even changing the name even to demonstrate that Opencart It's not just Events, but another tool or a broader one that has Events and other extras.

[FelipoAntonoff]

The advantage of OCMOD in these cases is that it has Logs and generates a Cache, it never modifies the original file directly, it is also a form of protection for the developer, because in case of an error in the store it can be easily proven that a certain module does not have it. any relationship by disabling the XML or even clearing the general modification cache.

Events is just an Events tool in general, even very well made and planned, but its use in general is for triggers and not a system that can basically change any line of php or twig files like OCMOD and doesn't have the same resources of the OCMOD.

I think a possible idea would be to create a new tool, perhaps an OCMOD 2.0 with another name and proposal, which has resources within it of Events and to be able to change any single line like OCMOD and preferably generating a cache so as not to have a high cost of performance and logs.

I even came up with an idea about going back to OCMOD #10883, as I currently don't see how Events would meet every use case that OCMOD managed to cover and in a simple, safe and high-performance way because a cache is generated.

We also have to think about the migration of modules, there are thousands of modules that use OCMOD and many in which Opencart 4 doesn't have a tool that can handle 100% without messing directly with the file, which I don't recommend.
I think it's good to give options to professionals and of course maybe focus more on guides to teach the most recommended use of each tool and examples of uses, I can even help at this point, because I understand OCMOD and its best practices very well.

About the idea of ​​improvements, I think I would need to solve these 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.

[v5mvidal]

Until we created the OCMOD Editor, working with ocmod was difficult and almost always full of conflicts, the same for vqmod that also had an editor made by another user for the same difficulties.

I remember when ocmod came as an alternative to vqmod in OpenCart 2, and the same speech was made, that we didn't need ocmod because we already had vqmod and it was better, but in the end, after we evolved the tools to work with ocmod, it was accepted.

This debate about the importance of ocmod is valid, but it doesn't help as the changes are here to help OpenCart continue to evolve.

[FelipoAntonoff]

Yes, the Editor helps a lot or putting it in the /system folder, even a native editor would be a great idea.
What kind of conflicts are you referring to?, because I've never seen OCMOD give a problem, only if the searched line has basically been changed and that probably another tool will occur if it searches for a line and it has been modified, I even think it's bad when they mess with the standard files and I've seen it done even by large companies. I also think a tool that can deal even better with conflicts and adaptations is very valid.

About the change from vQmod to OCMOD at first some didn't like it, because it was necessary to rewrite the xmls due to small changes in the order of the structure like before, after and etc and in the first versions depending on the version of Opencart there were small changes and now with Events it will be something much more complex and in the current state I would say incomplete without touching the files directly in some cases.

Yes I agree change is always good, I have always focused on innovation and evolution, but I think it is important to analyze the changes and in a way that is positive and for the better.

If Events is the "new" OCMOD right, we have to think about how to improve it to be a really functional and better replacement, but honestly I would change the name Events or a new tool, if it's to make it another kind of tool besides use normal Events, but that's another matter.

As for ideas of evolving Events or the new tool, I suggested a few points above.

Basically need:

• Be easy to deal with conflicts
• Being able to change lines of PHP (controller, model, library), Twig and maybe a bonus JS and CSS
• Have clear logs and easy to identify conflicts or errors
• Being able to work even with several modules moving in the same places/nearby or at least help to avoid conflict in these cases or
• Have a native online editor to make it easy to edit lines in case of any conflicts
• It cannot compromise the performance of Opencart, so use of Cache I consider important
• Easy maintenance in code
• Easy development and testing
• Easy deactivate, remove or edit

I think initially about these points, I also find it interesting to be analyzed if Events can meet, if it wouldn't be necessary to see another tool for this focus, as I commented above, maybe a type of OCMOD 2 only with the code declared in PHP.

I also think it is valid to create a conversion tool between OCMOD and the new tool/Events, as there are thousands of modules in OCMOD, I believe that this manual migration is unfeasible for many and it would also be a way for us to validate the new tool, because if it succeeds functionally convert any XML into the OCMOD standard at least from Opencart 3, then it will already be validated and tested.

[v5mvidal]

Some admin delete this conversation, because I believe they didn't understand that it was to be dedicated to ideas to improve events and not to talk about ocmod.

[FelipoAntonoff]

I consider what was discussed to be important, after all we are talking about Events and how to make it better to be able to replace the use of OCMOD since it doesn't have it in Opencart 4 at the moment.

[v5mvidal]

Everything you said we already know, what we need is practical applications in code.

We created the ocmod editor to help solve ocmod problems, what will you create to help solve the event 'problems'?

The purpose of this discussion was this, something practical.

[punitkumar]

@FelipoAntonoff You are right when we see opencart plugins with eye of OCMOD.
May be @danielkerr has more broader vision which majority of Opencart community is not able to see right now.

I am, myself a big fan of OCMOD system and it's easiness and flexibility, however, current event system is completely oppose to what ocmod do.

Hopefully vision of removing OCMOD in place of event get's clear soon.

[FelipoAntonoff]

@v5mvidal I understand, that's why I informed suggestions and what would be necessary for Events or another tool to predate the Modules correctly without having to directly touch native files and with high performance and security.

About what I can do is give suggestions, debate and help with the code if needed, maybe the main question is Events can meet the entire use case for the current Modules with quality? and if not, how can we make this possible or if we need to analyze the creation of a new tool for cases that may not be the focus of Events.

[FelipoAntonoff]

@punitkumar I can't see this vision either, but I want to understand this vision, so I created a topic about returning to OCMOD or at least having an idea of ​​how we can pass modules to Events.

Events has been around since Opencart 2 and 3, it had its use well defined to work with triggers, while OCMOD the part of changes in files based on lines without directly changing generating a final cache with the changes and could even cover the triggers of Events .

Now if Events is the great future of Opencart 4, we need to analyze ways it meets the current use cases of Modules and how we can correctly migrate the modules that move the controller, model, library and view by XML to Events or another tool.

We have to think about the strengths and weaknesses of OCMOD and Events so that in the future Events will cover all the advantages of OCMOD and go beyond, so it would meet all use cases with a clear evolution, facilitating development, maintenance and support.

I also like the idea of ​​everything being done in PHP, this could be a big advantage in the future.

[danielkerr]

I will write some examples. I have it planned out. After that I will fix more issues upgrade bs5, jQuery, etc..then new minor release.

[FelipoAntonoff]

Thanks @danielkerr , it will be nice to have examples with different types of usage.
I can then translate them or create tutorials in Portuguese too.