PHP Optimizers and install issues

[Rigel Kentaurus]

This has been happening to me more recently.

Because of the new Zend Optimizer, and APC, the server does not check PHP files every time. This means that even if the person uploaded a new PHP file, it might be cached by the opcode cache, and it will not be refreshed until a minute later.

This is ESPECIALLY relevant on add-on upgrades, because people might upload the PHP files, immediately go and upload the xml, and, oops, the Install.php file never ran because it took the one cached by the opcode cache, instead of the new one. And there is no way to recover since the version number got updated in the database already and re-uploading the xml is no good.

... and many other weird scenarios as you may imagine.

I am trying to look for a workaround. My current idea is to change the name of the file for Install.php on every upgrade, with a timestamp (hence, forcing the opcode to load the file since it is "new" to it). I am also considering watermarking the files, in such a way that the installer does not proceed if the xml does not match the files in the filesystem (i.e. addon version 5 but files version 4)

Or, I could be evil and just call accelerator_reset(); and apc_clear_cache(); and clear all the caches for the server (actually, I think it would be nice if XF did this by default on an add-on install or upgrade)

 

[MattW]

What do you have for opcache settings for these values?

opcache.validate_timestamps (default "1")
When disabled, you must reset the OPcache manually or restart the
webserver for changes to the filesystem to take effect.
The frequency of the check is controlled by the directive
"opcache.revalidate_freq".

opcache.revalidate_freq (default "2")
How often (in seconds) to check file timestamps for changes to the shared
memory storage allocation. ("1" means validate once per second, but only
once per request. "0" means always validate)

 

[Mike]

Store your version ID in the install file. If the version ID passed to the install callback from the XML (second argument; first argument is existing add-on record, second is some of the new add-on record from the XML) doesn't match, throw an error.

 

[Rigel Kentaurus]

What do you have for opcache settings for these values?

opcache.validate_timestamps (default "1")
When disabled, you must reset the OPcache manually or restart the
webserver for changes to the filesystem to take effect.
The frequency of the check is controlled by the directive
"opcache.revalidate_freq".

opcache.revalidate_freq (default "2")
How often (in seconds) to check file timestamps for changes to the shared
memory storage allocation. ("1" means validate once per second, but only
once per request. "0" means always validate)

It doesn't matter what I personally have, it matters when the dozens of people and addon gets distributed to have different things

Store your version ID in the install file. If the version ID passed to the install callback from the XML (second argument; first argument is existing add-on record, second is some of the new add-on record from the XML) doesn't match, throw an error.

Thanks. I'll start doing that. I'd rather "break" the add-on from being installed than explaining over and over why the Install instructions didn't run.