I will look into this but vQmod has always supported ocmods first, even with 2.5.1 so that isn't anything new. My guess was maybe you needed to force clear the mods.cache file and it would have updated. Not sure why it didn't auto refresh itself but I've worked on a lot of sites and have installed dozens of ocmods and vqmods without ever seeing a problem with vQmod not taking in the previously ocmodded file.JNeuhoff wrote:I recently came across another VQMod 2.6.1 bug while looking at a customer's OpenCart 2.0.3.1 website. It had the Pavo Themes installed, but no Override Engine, nor Integrated VQmod, just your VQmod. There was the following OCmod XML file, stored in the database via the normal Extension Installer from an install.xml file:
OCmod created the expectedCode: Select all
<modification> <name>Export/Import Tool (V2.30) for OpenCart 2.x</name> <code>Export/Import Tool (V2.30) for OpenCart 2.x</code> <version>2.x-2.30</version> <author>mhccorp.com</author> <file path="admin/controller/common/menu.php"> <operation> <search><![CDATA[$data['text_backup'] = $this->language->get('text_backup');]]></search> <add position="after"><![CDATA[ $data['text_export_import'] = $this->language->get('text_export_import'); ]]></add> </operation> <operation> <search><![CDATA[$data['backup'] = $this->url->link('tool/backup', 'token=' . $this->session->data['token'],]]></search> <add position="after"><![CDATA[ $data['export_import'] = $this->url->link('tool/export_import', 'token=' . $this->session->data['token'], (version_compare(PHP_VERSION, '2.2.0.0') >= 0) ? true : 'SSL'); ]]></add> </operation> </file> <file path="admin/language/*/common/menu.php"> <operation> <search><![CDATA[$_['text_backup']]]></search> <add position="after"><![CDATA[ $_['text_export_import'] = 'Export / Import'; ]]></add> </operation> </file> <file path="admin/view/template/common/menu.tpl"> <operation> <search><![CDATA[<li><a href="<?php echo $backup; ?>"><?php echo $text_backup; ?></a></li>]]></search> <add position="replace"><![CDATA[<li><a href="<?php echo $backup; ?>"><?php echo $text_backup; ?></a></li><li><a href="<?php echo $export_import; ?>"><?php echo $text_export_import; ?></a></li>]]></add> </operation> </file> </modification>
system/modification/admin/controller/common/menu.php
system/modification/admin/language/english/common/menu.php
system/modification/admin/view/template/common/menu.tpl
The subsequent VQmod processing step ignores the system/modification/admin/view/template/common/menu.tpl and only creates a vqmod/vqcache/vq2-admin-view-template-common-menu.tpl (with Pavo menu changes only).
While it's good to see VQmod supporting OCmod XML syntax, it still needs to be able to cooperate with OCmod and its processing files via the admin/controller/extension/modification.php, both modification systems should be able to co-exist!
why not to include a "modification / file / operation / if" as alternative to ignoreif ?
I mean something simply applying the operation if some lines of code are found.
Is it possible to be achieved today? Or can it be an interesting feature?
Thanks for your time,
M
-----------------------------------------------------------------------
My last mods: Partita IVA e CF | Pro EU VAT Number | Sales Agents | Pricelist Pro
-----------------------------------------------------------------------
Yes indeed. I had this same conversation with Jay a few months ago when I needed "if" instead of "ignoreif". It should be in the next version.madimar wrote:Hi all, I'm almost sure this just exist in some way but:
why not to include a "modification / file / operation / if" as alternative to ignoreif ?
I mean something simply applying the operation if some lines of code are found.
Is it possible to be achieved today? Or can it be an interesting feature?
Thanks for your time,
M
Regards,
Md
Inviato dal mio SM-G930F utilizzando Tapatalk
-----------------------------------------------------------------------
My last mods: Partita IVA e CF | Pro EU VAT Number | Sales Agents | Pricelist Pro
-----------------------------------------------------------------------
<file ver=">2.3.0.0">
<file ver="<=2.3.0.0">
<file ver="=2.3.0.2">
<file ver=">2.0.0.0,<=2.2.0.0">
also operation would be essential
<operation ver="2.3.0.2">
(possibly even modification tag itself? maybe not) <modification ver="<=2.2.0.0">
etc.
That way, all versions of a mod could be implemented in one xml file.
(Should also work for non-opencart implementations as long as their versioning method is decent).
From a programmer perspective it would be quite neat as it would show the common changes for several versions grouped together and then you would have version specific changes in their own statement.
From a user perspective it would be quite cool aswell, just get the latest version of each mod and override it, rather than having to remove version specific mods and replace them with the updated versions.
Developers may even choose to implement something like
<operation ver="<=2.3.0.2">
// latest tested/supported version, implement as usual
<operation ver=">2.3.0.2">
// give user warning mod not tested on this version yet, proceed with caution / disable altogether!
This is a really, really good idea and I think it would be relatively easy to implement.sculptex wrote:What about opencart version conditionals?
<file ver=">2.3.0.0">
<file ver="<=2.3.0.0">
<file ver="=2.3.0.2">
<file ver=">2.0.0.0,<=2.2.0.0">
also operation would be essential
<operation ver="2.3.0.2">
(possibly even modification tag itself? maybe not) <modification ver="<=2.2.0.0">
etc.
That way, all versions of a mod could be implemented in one xml file.
i've done a test implementation for the <file> so farbillynoah wrote:
This is a really, really good idea and I think it would be relatively easy to implement.
seems to work okay.
2 points raised.
1) Using <,>,>=,<= etc. threw up parsing errors so instead I am useing lt,gt,ge,le (also =,!= as eq,ne) which are compatible operators used by the version_compare() function
2) The logic needs to be all positive, so;
greater than 2.0.2.0 but less than 2.3.0.1 oh and also if equal to 2.4.0.0 aswell WOULD NOT WORK. So really its only suitable for one continuous range of versions.
if anyone wants a copy of my prototype updated vqmod.php, let me know
<constant name="VERSION" comparison="<"><![CDATA[2.2.0]]></constant>
You could add multiple constant items to each operation, and it would allow you to use any version variable across platforms.
These features were already planned as part of a 3.x release along with many others, but with the release of ocmod in 2.x I kind of lost the motivation to code it. Perhaps this year we can look at doing that again
I have implemented for <file> and <modification>, I sent to you earlier.
It just takes the defined constant VERSION for now because thats what opencart calls it. If you chose another name for it or for implementing on other systems, part of their install 'wrapper' would be to inject define('VERSION', OTHERAPPVERSION); into index.php or whatever in the equivalent to vqmod opencart install.
Anyway, it seems to work and make sense to me.
I can't really follow where you are going to be honest with your example, it seems to be more complicated than the way I have implemented it.
The reason for having it in both <file> and <modification> is that occasionally there is a different version of a mod for the same file on different versions so that would use it in <modification>. Other times, the file has moved to a different location, so you would use it in <file>.
I have attached the file in case any other developers want to take a look but don't start using it for released mods as it would be totally useless if its not implemented in the standard vqmod core.
Attachments
proposed new vqmod with version control
Code: Select all
<file const="VERSION" compare="<=" target="2.3.0.2" name="path/to/file.php">
<operation const="VERSION" compare="<=" target="2.3.0.2" >
<search/>
<add/>
</operation>
</file>
Code: Select all
<file server="REMOTE_ADDR" compare="<=" target="76.123.*.*" name="path/to/file.php">
</file>
Code: Select all
<file envvar="JAVA_PATH" compare="=" target="c:\\java8\bin" name="path/to/file.php">
</file>
But it keeps things more universally generic without hardmapping values to attribs which we don't want to have.
But it would be better to not have compare and target separate, just put them both in compare as per one of my examples as this allows multiple comparison separated by commas though you wouldn't normally need more than two (already works in my prototype). (Also I changed to alpha comparison operators to avoid syntax errors).
Code: Select all
<file const="VERSION" compare="ge2.3.0.0,lt2.3.0.2" name="path/to/file.php">
Code: Select all
<file vartype="constant" varname="VERSION" compare="ge2.3.0.0,lt2.3.0.2" name="path/to/file.php">
constant
server
envvar
etc.
So each compare would use the vartype and varname in the current tag?
I also attach a test xml file which shows version comparisons in admin header (therefore needs refreshing twice)
Attachments
Am I the only one here who is still enthusiastic about vqmod?
Vqmod was actually the clincher that decided me on switching to opencart above other cart software, I think it would be a pity for it to stagnate just because OC implemented its own inferior version.
Vqmod has so much more potential than just OC, I am using it for entire websites and other platforms (still wip), I would love to contribute but just need to know if its realistic that vqmod will be developed any time soon.
The last thing I want to do is tread on anyone's toes or create a rift by branching off in an incompatible direction.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
As far as the 'future direction' of vqmod is concerned, it potential is not restricted to OC but any improvements to it may as well benefit OC aswell!
Users browsing this forum: No registered users and 74 guests