object-cache.php conflicts with third party plugins

[jamesozzie]

Bug Description

As highlighted by one user in the support forums, there is a conflict between the Performance Lab generated object-cache.php file and the same file generated by third party plugins.

The expected behavior with an additional object-cache.php file generated by another plugin (if the PL plugin is installed first):

1. The PL plugin renames the third party plugins object-cache.php to object-cache-plst-orig.php
2. The PL plugin then loads it's own file, while also loading the object-cache-plst-orig.php file

Steps to reproduce

1. Install the PL plugin
2. Check that that object-cache.php file exists within the sites wp-content directory
3. Install and active W3 Total Cache
4. Within the W3 Total cache settings enable Object Caching (Performance > General > Object Cache > Object Cache > Enable)
5. After enabling object caching within the W3 Total Cache settings a notice will appear recognising the conflict. You can then choose to allow W3 Total Cache to remove the PL inserted object-cache.php file. If doing so, the PL file is removed.

The same issue can be found if using LiteSpeed Cache and applying Object Caching (ListeSpeed Cache > Cache > Object > Object Cache > ON). For this plugin there is no conflict highlighted, instead the PL file is removed (recording of experience)

eF0WdP12Tn.mp4

[felixarntz]

@jamesozzie I debugged this thoroughly with W3 Total Cache. What happens depends much on the order of things:

W3 Total Cache first

This is the scenario for someone that was first using W3 Total Cache with object caching enabled (probably the more likely one when it comes to support requests).

• If you first activate the W3 Total Cache Object Cache feature, it'll place its object-cache.php file.
• If you later activate Performance Lab, it will try to place its own object-cache.php file, doing so in a non-destructive way. Because it notices there is already one there, it'll rename that one to object-cache-plst-orig.php and then place its own object-cache.php file. That object-cache.php file will keep loading object-cache-plst-orig.php.
• At this point, the W3 Total Cache object caching feature is working perfectly fine. However, W3 Total Cache's logic about their object-cache.php file is overly strict: It doesn't even consider that the logic is still working; it simply "complains" that their own object-cache.php file is not the object-cache.php file found at that location. The fact that their own object cache file is still loaded and executed (as object-cache-plst-orig.php) is ignored, resulting in that message. So effectively in that scenario it is unnecessary to agree to the message. This could potentially be raised as a concern to their development team.

Performance Lab first

• If you first activate Performance Lab, it will place its object-cache.php file.
• If you later activate the W3 Total Cache Object Cache feature, it'll show the admin notice you're referring to. In this case it is valid, since indeed right now the Performance Lab object-cache.php file poses a "conflict".
• If you agree to replace the file, W3 Total Cache will replace PL's object-cache.php file with its own.
• At this point, PL's object-cache.php file is not loaded, which is expected.
• However, PL has a timeout mechanism to retry placing its own object-cache.php file if it doesn't exist, with a 1 hour timeout. W3 Total Cache has its own timeout of 10 minutes for your "consent" to remove the other (in this case PL's) object-cache.php file. As such, after agreeing to W3 Total Cache's admin notice, you will have to wait between 10 minutes to 1 hour (depending when the PL file was first placed).
• After that time, PL will retry to place its object-cache.php file (similar to the first scenario outlined above), again doing so in a non-destructive way. It will rename the W3 Total Cache file to object-cache-plst-orig.php and then place its own object-cache.php file. That object-cache.php file will keep loading object-cache-plst-orig.php.
• Still, as mentioned in the above scenario, at this point both files will technically be loaded, but W3 Total Cache will still "complain" with the notice.

So far, so good. Now the interesting thing is what happens at a point where both the Performance Lab timeout to try placing the file has expired while the W3 Total Cache timeout for the consent to replace the file is still active. At this point both plugins will try to place their files, almost in like a race condition. Because the logic for W3 Total Cache runs later, it'll replace PL's object-cache.php file ("destructively") after PL has placed its own and in the process backed up W3TC's object-cache.php file ("non-destructively"). In other words, you end up with the W3TC file in both object-cache.php and object-cache-plst-orig.php. It is still only loaded once though. However that is the only scenario where arguably the bug is on the PL side, since PL does currently not cater for that situation. I will fix this in a PR.

Other than that PR, the most appropriate step here would be to open an issue with W3 Total Cache on checking for whether their object cache logic is loaded/running before simply assuming it is not because the file they expect to be in a certain place is not in that place.

I haven't done testing with LiteSpeed Cache yet, but I'd be pretty sure the issue there is along the same lines.

[OllieJones]

Don't forget Till's Redis Object Cache, and my new SQLite Object Cache (to which I will add compatibility code when this PL (ab)use of the object_cache.php drop-in settles down.

And, it has to be said, this approach isn't sustainable without adding a documented protocol for dropping drop-ins in.

[felixarntz]

@OllieJones Fair points, let's discuss this a bit further. Potentially the only alternative here would be to just not place the PL object-cache.php file if there already is another one.

I think the approach here does what we can, and we ensure things stay working. I stand by my point that other plugins likely use extremely strict checks for whether the correct file is in place, which are IMO overkill. But if this is a widely common problem, then we may still reconsider here.