Post by Qphoria » Sat Mar 26, 2016 10:34 am

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:

Code: 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> 
OCmod created the expected

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!
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.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by JNeuhoff » Sat Mar 26, 2016 4:36 pm

Perhaps the issue was caused by the Pavo web theme which uses terrible VQmod XML scripts and even tries to modify the admin backend too much.

User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by madimar » Thu Aug 25, 2016 6:36 am

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

-----------------------------------------------------------------------
My last mods: Partita IVA e CF | Pro EU VAT Number | Sales Agents | Pricelist Pro
-----------------------------------------------------------------------


User avatar
Active Member

Posts

Joined
Thu Sep 24, 2009 6:27 pm


Post by Qphoria » Tue Aug 30, 2016 11:27 pm

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
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. :ok:

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am


Post by madimar » Sat Sep 03, 2016 1:14 am

Good news, thanks, it can be really a nice feature IMHO.

Regards,

Md

Inviato dal mio SM-G930F utilizzando Tapatalk

-----------------------------------------------------------------------
My last mods: Partita IVA e CF | Pro EU VAT Number | Sales Agents | Pricelist Pro
-----------------------------------------------------------------------


User avatar
Active Member

Posts

Joined
Thu Sep 24, 2009 6:27 pm


Post by sculptex » Mon Jan 09, 2017 6:55 pm

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.

(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!

ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK

Post by billynoah » Tue Jan 10, 2017 1:54 am

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.
This is a really, really good idea and I think it would be relatively easy to implement.

Image


Active Member

Posts

Joined
Tue Jan 15, 2013 12:46 pm

Post by sculptex » Tue Jan 10, 2017 6:59 am

billynoah wrote:
This is a really, really good idea and I think it would be relatively easy to implement.
i've done a test implementation for the <file> so far
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

ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK

Post by JAY6390 » Wed Jan 11, 2017 10:23 pm

Sorry, I don't get notifications for this thread any more for some reason. We have discussed both the "if" tag and adding version checking. The first can be added quite easily. The second we need to go about a little more carefully. VQMod is designed for more than just opencart, and so we have to account for those other systems too. We also need to allow finer tuning on the operations so with that in mind, having it as part of the <file> tag wouldn't really work. What would be better is if there was a tag for this where you could add one or more constant conditions, where you could set the constant name and the value, as well as a comparison mode (= < > != <= >=) on the operation level, and have those values tested before a mod is applied. For example

<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

Image


User avatar
Guru Member

Posts

Joined
Wed May 26, 2010 11:47 pm
Location - United Kingdom

Post by sculptex » Thu Jan 12, 2017 6:38 am

Hi Jay,
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


ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK

Post by JAY6390 » Wed Jan 25, 2017 2:46 am

Yeah, my way is more complicated but more adaptable, as you could use it for more than just version checking. The way I've described you would be able to make any constant a condition of an operation

Image


User avatar
Guru Member

Posts

Joined
Wed May 26, 2010 11:47 pm
Location - United Kingdom

Post by Qphoria » Wed Jan 25, 2017 3:46 am

I would propose it best to keep a more generic level of abstraction, and instead of hardcoding attributes like "ver" to map to the VERSION constant, we add open-ended name/value/comparison structure. Then it could be used with any constant

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>
We could even expand out to GLOBALS, SERVER, and Env variables, albeit rather needlessly, but it just pushes the point of the design to be able to grab system level settings as a qualifier

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>
Though not everything works with =, >, < as we'll need to know when to do partial matches, when to use version_compare vs str_comp vs strpos

But it keeps things more universally generic without hardmapping values to attribs which we don't want to have.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by sculptex » Thu Jan 26, 2017 1:19 am

Hi, yes that would be a great addition, sorry Jay I didn't understand properly I must have been having a dumb moment.

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">

ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK

Post by sculptex » Thu Jan 26, 2017 3:41 am

Actually, on second thoughts, it might be better to have something like

Code: Select all

<file vartype="constant" varname="VERSION" compare="ge2.3.0.0,lt2.3.0.2"  name="path/to/file.php">
so as per your example, the vartypes would be
constant
server
envvar
etc.
So each compare would use the vartype and varname in the current tag?

ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK

Post by sculptex » Thu Jan 26, 2017 4:47 am

i've implemented it just for constant, no error checking, just proof of concept.

I also attach a test xml file which shows version comparisons in admin header (therefore needs refreshing twice)

ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK

Post by sculptex » Thu Feb 09, 2017 4:47 pm

@Qphoria
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.

ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK

Post by JNeuhoff » Thu Feb 09, 2017 5:53 pm

While VQmod is useful (I mainly use it for bugfixes), the future direction should head toward more robust ways of modifying OpenCart core files. OpenCart has finally introduced useful event triggers since 2.2.0.0 for almost every public controller, model, language, and loading views events. The danger with VQmod is that all too often different 3rd party extensions clash with each other, often because of poorly written VQmod scripts.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by sculptex » Thu Feb 09, 2017 7:04 pm

Yes, as far as the 'future direction' of OC is concerned, event triggers are the best way to achieve most things, but I am sure that multiple poorly written modifications residing on the same event trigger could also have problems. At the end of the day its always gonna be down to the quality of coding by the mod author.

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!

ImageImage


User avatar
Active Member

Posts

Joined
Tue Sep 13, 2011 3:07 am
Location - UK
Who is online

Users browsing this forum: No registered users and 43 guests