How do I make vQmods work better together?

I'm new to developing for Opencart and I've figured out how vQmod works and have successfully written and modified a few extensions.
But my latest project has revealed a problem with using vQmod to modify the database queries.

What I am wanting to do is add a few extra data fields to the edit product page, which isn't a problem with vQmod. The problem comes when trying to modify the queries in the product.php controller and model in the admin. If multiple extensions use vQmod to modify the query, then they will break each other. So my question is how do I properly modify these queries to both retrieve the stored data AND update the data when the product is updated?

I'm not sure if this is where modules come in, but if someone can point me in the right direction, I would greatly appreciate it. Thanks1

The best bet in this situation is a lame answer... you should alert and work with the other devs to make a less liable habitat. Often they are willing to fix authoritative replaces to work smooth with the touchy vQ ecosystem. Beyond that, here are steps we all can use to make vQ->OC a better experience


About inline mods: vQmod has iafter and ibefore, so if you can figure out a non liable string to target or write on, it may work. This is highly unlikely though in the situation of 3-4-5 vQ fighting for mod authority To amend this, you could experiment with making render orders different and editing the xml of the other mods (not ideal).


About mod sort/render: vQmod uses a file sort order, it goes from top to bottom down the files in the xml folder. Things like "--" will float a mod to the start of the render order, whereas things like "xx_" will render last. You would think that "zz_" would be most logical choice for last, but that name itself acts wonky (hidden) in certain extensions like Openshop vQmanager. Also yy_ or zz_ should be treated as a "reserve". Certain extensions like related options use it as a complete last in line and you should respect that.


About less liable targeting + gambling: If you're targeting things, try to use the smallest yet unique bit you can, that isn't repeated. Sometimes this may be a gamble. In the case of something like list items: You would want to target just the <?php echo $my-thinger; ?> without li wrapper to make more compatible right? What if someone makes a new <?php echo $my-thinger; ?> in the future somewhere else? Would your code be placed there too, perhaps. Use your best judgement.

Opposite example, say that you want to target and remove something like that li row. Lean towards just commenting it out, although you may be in the same predicament. What if someone replaces your commented? Its always a gamble to break less next/prev/replaces/anything from other mods. Be aware of the gamble if you market it


Extra vQ hints: You can highlight a bit and use ctrl-F in notepad++ if you need a fast way to count strings. Avoid using index, try to find a better string. Try to NEVER use offset unless critical. Use skip on <file> and on <search> for other optional-existent mods. Log on both those facets is good too for other things. Use info on all your operations and explain the steps. Use proper tabs/spacing on add for readability in vqcache. If you need, you can clear the files in vqmod/vqcache/ at any time, you can also delete vqmod/mods.cache file. These will regen automagically and re-render your xml folder.


Making vQ dependencies: A tactic we use sometimes is just making a new useful function in model, or calling simple db in controller (that will never be shared in other controllers, hotfix only). Its not pure MVC calling query at controller but nothing is pure anymore. If you opt for the new model function route, consider splitting it out into its own vQ with a first-in-line file sort so that other mods may use and "depend" on it in the future.

Hope that helps for all folks new to vQ as well as those who have used it often. Whew a bunch of edits later...please add your thoughts to less volatile vQ ecosystem in OC.

Personally, there is no easy answer.

Depending on the sort order of your vqmod files, one of them will overwrite the other if two mods are running using the same line of code.

Infact the other mod will no doubt throw a vq-cache error since it wont find the correct code to change once its been replaced by the previous one.

The only solution, is to remember what vqmod files are modifying which bit of data. If something throws an error or doesn't work, and you know it is because they both clash, the only real solution, is to try and blend both vqmod codes in to one file, and in some circumstances, rewrite code so they interact together and not against each other.

The last resort, is to contact the developer of one, and hope he/she is nice enough to do it for you.

Thank you both for your replies and I changed the post title as per your suggestion Dhaupin.
It doesn't seem there is a *great* solution. I came from developing in Wordpress, from making themes, plugins, and even contributing to the core code where I found shortcomings and problems.
The reason I mention it is because they have a brilliant system of what they call "hooks" and "filters". It allows a great deal of flexibility as well as permits multiple plugins to work together without clashing, even if the same line of code is being modified. I can only wish Opencart had this sort of flexibility, but vQmod just isn't dynamic enough to allow this.
I recommend it being looked into and the code is also GNU, so there would be no conflict with borrowing this method from their code. It would be a progressive integration and I can see that being one big draw back since I don't know how many people are keen on doing regular updates to their store since this jeopardizes their store and can crash it, costing a lot of money to fix. Hooks and filters are progressive, meaning there's always new places to implement them and I suppose that's where vQmod has a better application.

Anyways, I appreciate you all taking the time reply.

There is a nascent events hook system in OpenCart 2.0. I wish the idea of OCMod had been dropped entirely and events had been further developed instead. I've practically become a broken record on the subject, but moving away from systems like OCMod to more modern techniques will dramatically improve development time and code stability.

As far as vQmod goes, here are some additional tips for code stability I threw together a while back. The most important thing is to stop thinking of vQmod as a way to modify code and start thinking of it as a way to insert and override code. I usually accomplish this by inserting code into the controller before the template loading which looks for certain conditions then applies overrides/additions to the controller $data property. This won't cover every use case but it will handle a big chunk of them.