[Solved] vQmod fails to write to vqcache directory on IIS

This was a bug in 2.6.0 but I cannot reproduce this on 2.6.1. That code hasn't changed from 2 years ago in 2.5.1. We added some code there to fix another potential issue in 2.6.0 but then went back to the old way in 2.6.1
Please redownload and try again. I actually developed this on a windows machine so I would have certainly seen this.
Unless there is something funky about the path.

If you have not made any changes to vqmod code after site transfer and you believe that vqmod is installed properly then try deleting MODS.CACHE file inside VQMOD folder and it might do the trick.

Unless there is something funky about the path

Nothing unusual, just alphanumeric characters, no spaces or special characters.

I'll download 2.6.1 again to be sure it's clean and continue testing

I'm sure there is nothing wrong with 2.6.1.

2.5.1 (and all previous versions I used) ran without issue on the original server.

I suspect the new server is somehow generating different values relating to the cache path.


Can someone confirm what filenames should be expected in /vqmod/vqcache?

On the old server I see eg.

vq2-system_startup.php but I think others are seeing the filename derived from realpath eg.

vq2-net_hosts_domain.com_httpdocs_system_startup.php

try deleting MODS.CACHE file inside VQMOD folder and it might do the trick

If I do that there are no cached files in /vqmod/vqcache/vq2-* to rebuild mods.cache at run time so no modifications are applied.

Think this is solved.

Short version
Changing line #120 of vqmod.php from
to
Means the /vqmod/vqcache/vq2-*.php cache files are written and the website runs as normal.

Long version
Breaking down line #120:

• self::getCwd() is returned as: C:\Net\hosts\domai... etc.
  $sourcePath is generated by self::_realpath($sourceFile); and is returned as: C:\net\hosts\domai... etc.
  function _realpath() sets $path = realpath($file);

So when preg_quote tries to create $stripped_filename it can't find an exact match because for case-insensitive filesystems realpath() may or may not normalize the character case.

Since Windows is case insensitive I guess this is where the problem lies.

However, I am unsure why only the first letter in the path is affected.

The absolute root directory is C:\Net which $sourcepath returns as C:\net.

If sub folders have upper case letters they are returned as such.

I guess the reason there was no issue on the original server is the absolute root directory happens to be C:\net.

I'll test further with additional sites tomorrow.

We will test this out and put it in the next release if all goes well.

Qphoria wrote:We will test this out and put it in the next release if all goes well.

Changing the preg_match to be case insensitive could create an issue on linux/unix, since files there are case sensitive. It wouldn't be typical to have two vqmods with the same name but varied in case, but it could happen.

I'm guessing this is all driven by a bug in php's realpath() on windows. There is, for example, a bug with realpath() on Windows if the directory in question is actually a link that was made with mklink. Now that one is just the case of the drive letter, but it seems similar. There's another bug that looks exactly like this, but closed way back in php 5.2.something.

OP is using a fairly old, unsupported, PHP5.3 version, might be worth trying a newer version of PHP.