A few years ago, When the Skooter Blog was still staying at the HostGator, I installed the plugin W3 Total Cache in an attempt to improve the speed of blog, It was slow and was off the air eventually, only to find that most of the features depended on the resources HostGator not offered. I left it enabled with the basic features for a long time, I migrated to the Hawk Host later, and I ended up realizing that the plugin more burden that helped.
The point is that practically every cache plugins work as follows: the first time a page is accessed, PHP does all processing, serves the page to the user and save a copy to disk. On subsequent accesses it directly accesses the disk copy saving server resources. The problem of this approach is that the first access, that will generate the cache, is computationally costly. On blogs, this is compensated by the famous many subsequent accesses that have virtually no cost and get well faster.
The problem is that the Skooter Blog is not a famous site. And you are guilty of that, not to share the blog with your friends :P. Because of this, We have a lot more hits coming from bots than ordinary users. Are all the bots from the well, as the Googlebot and the Bingbot, who pass through here to index the blog, as the evil bots, who just want to do spam or get some security flaw. The problem of generating from cache of hits from bots is that they access many different pages, that probably won't have any subsequent accesses during the validity of the cache. Skooter Blog has a lot of content, but a large part of daily accesses are concentrated around few most famous articles. Generate the cache from the hits of the bots just makes these more expensive access, without any advantage in return, Since in most cases there will be no subsequent accesses to the same pages.
To work around this problem, I've been using the plugin WP Super Cache, simpler than the W3 Total Cache, but with a nice feature that identifies most of the bots and doesn't generate cache page from their access. They are still served by a page from cache if it exists, but do not generate a cache page if it does not exist. With this the Skooter Blog just generates cache pages from human visitors access, and only the pages that humans are actually accessing, making the cache useful.
I recently found out that our hosting provider, the Hawk Host, released PHP 7, The Memcache, and allows you to enable/disable packages such as APC and APCu. A few weeks ago I did these migrations and other changes that were announced here. Now I decided to give it a chance to W3 Total Cache, because their biggest advantages arise when in-memory caching features, as the APC, are available. Without this, It only caches to disk as the WP Super Cache.
The problem now is that the W3 Total Cache seems to have been abandoned by its author. The last update was 6 months, and there's no sign of support for PHP 7. But luckily a few simple patches that can be made in order to make it work with PHP 7 and also with the new APCu. Let's go get them.
W3 Total Cache with PHP 7
- Open: /WP-content/plugins/w3-total-cache/lib/W3/Plugin/TotalCache.php
- Go to line 512
- Change &$buffer to $buffer. That way you are removing the ampersand (&).
- Save (and upload the changes to the website)
This small modification immediately makes the W3 Total Cache work with PHP 7.
But still lack the APCu work. I didn't find any solution on the web and ended up discovering a self-employed, What motivated this article. This mod is a little more cumbersome, but let's get to it.
W3 Total Cache with APCu
The W3 Total Cache is compatible with APC, but in PHP 7 the module has changed its name and is called APCu. Therewith, all functions that started with ' _ ' apc, now start with ' _ ' apcu. I figured, so the plugin working again, you need to find the passages where these functions are called and make the change.
APC calls the W3 Total Cache uses are three: apc_store, apc_fetch, and apc_delete. They should be changed to apcu_store, apcu_fetch, and apcu_delete, respectively.
But where are these calls? I traced them in 4 files:
The secret then is to open each of these four files, Locate the calls apc_store, apc_fetch, and apc_delete and replacing them with apcu_store, apcu_fetch, and apcu_delete, respectively. Then just save the files and upload them to the server. The option to use the APC is available in W3 Total Cache (Opcode: Alternative PHP Cache (APC)) and you can select it instead of the disk cache.
I'm still testing, but so far have not found any side effects from these changes and apparently the cache with the APCu is working correctly.
Note that I just walked around the problem to meet my needs. If you go back to PHP 5.x APC will not work. The correct would be to identify and APCu APC separately, and use the functions, but I prefer to leave this to the author of the plugin, If he one day reappear.
Update (04/03/2016): I forgot to mention in the article that there is also a call to apc_delete that needs to be replaced by apcu_delete. Thank you, Jaakko, for the comment noting that. Updated the article to include this is also called.