[MOD] - VirtualQMod "vQmod" Virtual File Modification System

[Qphoria]

Yea that is true.. I could just do newlines and leave spaces. Both ideas seem good to support older and newer scripts

[uksitebuilder]

Not sure if this is an OC bug or due to having vQmod installed but I think it is vQmod

On a demo store with demo products installed, edit the Apple Cinema 30" product and click save.

if public $useCache = FALSE in vqmod.php then the following error is displayed:

Code: Select all

Notice: Undefined index: option_value_id in/htdocs/site/admin/model/catalog/product.php on line 169Warning: Cannot modify header information - headers already sent by (output started at/htdocs/site/admin/index.php:79) in/htdocs/site/vqmod/vqcache/vq-system_engine_controller.php on line 28Warning: Cannot modify header information - headers already sent by (output started at/htdocs/site/admin/index.php:79) in/htdocs/site/vqmod/vqcache/vq-system_engine_controller.php on line 29


setting $useCache = TRUE in vqmod.php then the error goes away


In addition, I think the default for $useCache is FALSE in vqmod.php

this means that the cache files are rewritten each time the page loads that has been modded. I have noticed a slight performance hit with this.

[uksitebuilder]

I have also noticed when doing a mod for the contact form that although the correct cache files are now written, for some weird reason, the captcha image stops working.

[JAY6390]

this means that the cache files are rewritten each time the page loads that has been modded. I have noticed a slight performance hit with this.

Well it's kind of a misleading variable to be honest. Although cache is set to false, it does actually still use cache files, however the cache files are made once per script/page load. The cache files are then used if the file is requested more than once in that page load. This means that if a file gets called 20 times, it's not going to have to modify it 20 times, only once.

For production servers, you should have useCache set tot true, to fully take advantage of the caching system. This way, you can modify the file once, and use the cache file indefinitely from then on. It does mean that when a new mod is added, you should delete all cache files so that it will generate them all correctly again

[JAY6390]

I have also noticed when doing a mod for the contact form that although the correct cache files are now written, for some weird reason, the captcha image stops working.

If caching is not enabled, this may be due to it being a second separate request for the image, although if my memory is correct the image is generated with the page, not separately

[Qphoria]

Not sure if this is an OC bug or due to having vQmod installed but I think it is vQmod

On a demo store with demo products installed, edit the Apple Cinema 30" product and click save.

if public $useCache = FALSE in vqmod.php then the following error is displayed:

Code: Select all

Notice: Undefined index: option_value_id in/htdocs/site/admin/model/catalog/product.php on line 169Warning: Cannot modify header information - headers already sent by (output started at/htdocs/site/admin/index.php:79) in/htdocs/site/vqmod/vqcache/vq-system_engine_controller.php on line 28Warning: Cannot modify header information - headers already sent by (output started at/htdocs/site/admin/index.php:79) in/htdocs/site/vqmod/vqcache/vq-system_engine_controller.php on line 29


setting $useCache = TRUE in vqmod.php then the error goes away


In addition, I think the default for $useCache is FALSE in vqmod.php

this means that the cache files are rewritten each time the page loads that has been modded. I have noticed a slight performance hit with this.

This is not related to vQmod. Usecache or not, that just determines whether or not the file is regenerated everytime. The actual error comes from the actual mod of that file. You need to contact the author of that mod.

[uksitebuilder]

Hi sorry, I think my point was confusing.
The admin bug/error is occurring where there is no mod, on just default files.

[madimar]

This is not related to vQmod. Usecache or not, that just determines whether or not the file is regenerated everytime. The actual error comes from the actual mod of that file. You need to contact the author of that mod.

Sorry Q, this time I don't agree with you. Reported issue is almost recurrent and wellknown (reported in several ways/forms in this topic discussion too). I experienced the same random problem and solved setting $usechache = TRUE;
As you can see in the extract reported by uksitebuilder, the errors are related to operations executed by the basic vqmod script "vqmod_opencart.xml".
In my experience this kind of errors happens randomly, especially in registration forms, where ajax / javascripts are present. Anyway with $usecache = TRUE; it seems problem is solved, maybe because several concurrent file rewrite are avoided. It is something similar to the errors related to the log-rewriting when ajax callbacks occur.

Then, I generally totally agree with JAY6390 suggestion. Since several time I use (and I recommend to use) following vqmod settings for production (well tested) environments:

$usecache =TRUE;
$logging = FALSE;

M

[opencartisalright]

I'm using OC 1.5.0.5 and vQmod 1.1.0.

When I update the status of one of my orders (ex. from processing to shipped), when the customer gets the notification to their e-mail and they click on the link that takes them to their order history page in opencart, they get the following error message.

Code: Select all

Warning: require_once(/home/xxxxxxxx/public_html) [function.require-once]: failed to open stream: No such file or directory in /home/xxxxxxxx/public_html/vqmod/vqcache/vq-system_engine_front.php on line 43

[Qphoria]

This is not related to vQmod. Usecache or not, that just determines whether or not the file is regenerated everytime. The actual error comes from the actual mod of that file. You need to contact the author of that mod.

Sorry Q, this time I don't agree with you. Reported issue is almost recurrent and wellknown (reported in several ways/forms in this topic discussion too). I experienced the same random problem and solved setting $usechache = TRUE;
As you can see in the extract reported by uksitebuilder, the errors are related to operations executed by the basic vqmod script "vqmod_opencart.xml".
In my experience this kind of errors happens randomly, especially in registration forms, where ajax / javascripts are present. Anyway with $usecache = TRUE; it seems problem is solved, maybe because several concurrent file rewrite are avoided. It is something similar to the errors related to the log-rewriting when ajax callbacks occur.

Then, I generally totally agree with JAY6390 suggestion. Since several time I use (and I recommend to use) following vqmod settings for production (well tested) environments:

$usecache =TRUE;
$logging = FALSE;

M

There are times where I have seen an errors for things like an ajax load on rare occasion due to the vqmod.log file being locked.. but this particular error about "option_id" has never been reported in relation to vqmod that I've seen. I'd need more information. The problem is worked around with usecache, but a fast server shouldn't normally have this problem anyway. v1.1.0 also adds a delayed write option and automatic pseudo-cache if the same file is accessed twice within the same 2 seconds which should have likely resolved those issues.

[madimar]

Thank you Q,
to be honest I was reporting my experience, but I don't consider it a real problem or a bug. Anyway if things have been improved in 1.1.0 better... I experienced them in 1.0.8 and 1.0.9.
For me, especially usecache=TRUE is quite a normal setting in a production environment, I don't see it as a workaround, but, better, as a best practice: if a script/mod is well tested, and cache files have been generated, what is the necessity to re-build them each time!
Sure, if a new mod/script is added, I temporarily re-set usecache=FALSE and logging, or I purge cache directory.

[Qphoria]

Thank you Q,
to be honest I was reporting my experience, but I don't consider it a real problem or a bug. Anyway if things have been improved in 1.1.0 better... I experienced them in 1.0.8 and 1.0.9.
For me, especially usecache=TRUE is quite a normal setting in a production environment, I don't see it as a workaround, but, better, as a best practice: if a script/mod is well tested, and cache files have been generated, what is the necessity to re-build them each time!
Sure, if a new mod/script is added, I temporarily re-set usecache=FALSE and logging, or I purge cache directory.

LOL are you explaining my own features to me? I know how they work and what they are for, that is why I added them.. but the error above doesn't necessarily reflect the same issue you experienced with earlier versions.

[opencartisalright]

I'm using OC 1.5.0.5 and vQmod 1.1.0.

When I update the status of one of my orders (ex. from processing to shipped), when the customer gets the notification to their e-mail and they click on the link that takes them to their order history page in opencart, they get the following error message.

Code: Select all

Warning: require_once(/home/xxxxxxxx/public_html) [function.require-once]: failed to open stream: No such file or directory in /home/xxxxxxxx/public_html/vqmod/vqcache/vq-system_engine_front.php on line 43

So any idea about the above error message?

[Qphoria]

I'm using OC 1.5.0.5 and vQmod 1.1.0.

When I update the status of one of my orders (ex. from processing to shipped), when the customer gets the notification to their e-mail and they click on the link that takes them to their order history page in opencart, they get the following error message.

Code: Select all

Warning: require_once(/home/xxxxxxxx/public_html) [function.require-once]: failed to open stream: No such file or directory in /home/xxxxxxxx/public_html/vqmod/vqcache/vq-system_engine_front.php on line 43

So any idea about the above error message?

Actually this is the white whale I've been chasing. I have a possible work around for it, but can't understand how it happens. It doesn't happen on any of my servers, but a few people have mentioned it. It is due to the realpath() not being able to propagate the full path so it returns false. But don't know why this should happen to begin with. Does it happen everytime? I was only able to reproduce it by manually debugging it and changing the sourcefile to a fake non-existent file.

I'll update the thread with a 1.1.1 with this work around and you can tell me if it resolves the issue.

[opencartisalright]

Does it happen everytime? I was only able to reproduce it by manually debugging it and changing the sourcefile to a fake non-existent file.

At the moment it's only happening when a customer clicks on the link in the order update notification that directs to the order history page. I haven't experienced the error anywhere else (yet). And yeah, it happens every time.

I'll update the thread with a 1.1.1 with this work around and you can tell me if it resolves the issue.

Great, as soon as you upload 1.1.1 i'll test it out and see if it resolves the issue.

[madimar]

LOL are you explaining my own features to me? I know how they work and what they are for, that is why I added them.. but the error above doesn't necessarily reflect the same issue you experienced with earlier versions.

ahah, surely I didn't want to explain you your features!! I was just sharing my experience with the forum... maybe other people are interested to know usual vqmod practices.
Thank you for your great work, vqmod is a great invention

Sent from my Desire HD using Tapatalk

[JNeuhoff]

Here is another VQMod 1.1.0 bug which wasn't there in 1.0.8:

If I specify a non-existing route in the url, e.g.

index.php?route=xyz/abc

the front.php will eventually pass an empty string as the file name in the call

Code: Select all

$file = $vqmod->modCheck($file);

yet vqmod returns a non-empty string (in this case the real path name). The subsequent

Code: Select all

if (file_exists($file)) {
....

now returns TRUE instead of FALSE, preventing Opencart from executing a proper error/not_found action.

Suggested bugfix:

Add

Code: Select all

      if ($sourceFile=='') {
         return '';
      }



at the very beginning of function modCheck.

[Qphoria]

Yea this is the issue I described a few posts up.... pretty much the same fix in place.

I've actually been working with JayG and just for fun he has filtered through a lot of the messy code I've been "bandaiding" over the past year and cleaned it up into a great looking new structure. We may have a v2.0 sooner than I thought.

Meanwhile I'll have 1.1.1 out with this fix and more today

[Qphoria]

So after thinking about it and talking to some people.. I think a better alternative to the logging issues is to cut back immensely on the logging. In reality, there is no real value in printing EVERYTHING to the vqmod.log, especially when they are successful changes. The logging was added initially because I was using random tmp files to create the modified files. This means you couldn't match the original source with its modified doppelganger. Since adding the vqcache folder and making real files there, the modified files are all there for easy analyzing and troubleshooting.. so the old fashioned logging no longer needs to be there.

So the new plan is to keep the vqmod.log as a continuous log, like the opencart error log. It will only log vqmod errors and minor notices, nothing else. If the mods are working then there is really nothing to check... and if you are making a mod that isn't working as you'd expect, you'd use the vqcache file to see what the code is doing.

This should improve a few things....
1. The tiny performance hit that may have been caused by logging will be gone
2. Intermittent errors regarding the locked log file will no longer occur
3. At least a page worth of logging code will be gone now, making vqmod.php smaller
4. Logs will be easier to read and error tracking will be much easier

1.1.x was mostly about trying to get the old logging system working better.. but really is moot now. So i will release the next version as 1.2.0

[JAY6390]

sounds good, can't wait to see the new logging method. Having a continuous log will be far better IMO