Existing advanced-cache.php doesn't get replaced when reactivating ZenCache plugin

[raamdev]

Steps to reproduce this bug

1. Install and activate ZenCache, then enable caching
2. Deactivate the ZenCache plugin
3. Install and activate WP Super Cache, then enable caching
4. Deactivate the WP Super Cache plugin
5. Activate the ZenCache plugin

Expected behavior

ZenCache should now be active and caching pages.

Observed behavior

WP Super Cache cache files are still being served, because wp-content/advanced-cache.php was never replaced by ZenCache with its own version.

If you Disable and then Enable caching in ZenCache, the advanced-cache.php file gets updated properly.

---

Note that this scenario specifically depends on ZenCache caching be enabled when you first deactivate the plugin, because when you reactivate ZenCache (after activating, enabling, and then deactivating WP Super Cache), ZenCache is activated with caching enabled (the previous setting). As a result, the routine that installs advanced-cache.php never runs.

[jaswrks]

ZenCache is activated with caching enabled (the previous setting). As a result, the routine that installs advanced-cache.php never runs.

Ah, tricky tricky. Good catch!

[jaswrks]

Install and activate ZenCache, then enable caching
Deactivate the ZenCache plugin
Install and activate WP Super Cache, then enable caching
Deactivate the WP Super Cache plugin
Activate the ZenCache plugin

I was unable to reproduce this, and I just checked the source code to confirm this should not happen. After disabling WP Super Cache and then re-enabling ZenCache, I inspected the advanced-cache.php file and confirmed that ZenCache does handle this scenario properly.

However, I have noticed a similar issue myself in the past when testing, and I think what you might be experiencing is an OPCache issue? The advanced-cache.php file installed by WP Super Cache can get cached in memory. Try disabling WP Super Cache, re-enable ZenCache; and then immediately inspect your advanced-cache.php file.

What you should find is that advanced-cache.php has in fact been updated. However, if OPCache is configured to bypass stat checks, the old version of that file can remain in memory for a few minutes, or even until your next Apache restart. The result is that you'll think the file has not been updated, because WordPress is in fact still running with the old copy in memory.

Relevant OPCache config. options:

• http://php.net/manual/en/opcache.configuration.php#ini.opcache.validate-timestamps

  opcache.validate_timestamps boolean
  If enabled, OPCache will check for updated scripts every opcache.revalidate_freq seconds. When this directive is disabled, you must reset OPcache manually via opcache_reset(), opcache_invalidate() or by restarting the Web server for changes to the filesystem to take effect.

• http://php.net/manual/en/opcache.configuration.php#ini.opcache.revalidate-freq

  opcache.revalidate_freq integer
  How often to check script timestamps for updates, in seconds. 0 will result in OPcache checking for updates on every request. This configuration directive is ignored if opcache.validate_timestamps is disabled.

---

Suggested Configuration for Production

php.ini file config. options...

opcache.validate_timestamps = yes
opcache.revalidate_freq = 300 ; or higher

---

Note that this issue should not occur with PHP OPCache now that ZenCache is configured, by default, to automatically clear the OPCache whenever a wipe and/or reactivation takes place. That was part of the work in this PR: wpsharks/comet-cache-pro#127

The issue can occur however, if you are running APC with a configuration that would open you up to this sort of confusion. APC has similar config. options, and stat checks can be turned on to avoid this. Referencing: http://php.net/manual/en/apc.configuration.php#ini.apc.stat

[raamdev]

@jaswsinc I seem to recall manually inspecting the advanced-cache.php file each time, which would rule out the OPCache theory. I'll add this to my todo list again and attempt to reproduce it later. Thanks for the feedback! :-)

[jaswrks]

I see. Well, maybe it's an issue that existed in a previous release and I just didn't test it at the same time as you did. I tested earlier today against the development branch.

[raamdev]

I re-tested this with the latest versions of ZenCache Lite and ZenCache Pro and was not able to reproduce the issue I described above. Closing this.