WordPress dashboard fatal error; blame & tweak APC!

I upgraded APC a couple of days ago and subsequently encountered a fatal error when trying to load my WordPress dashboard (but not the other wp-admin pages);

Fatal error: Call to undefined function wp_dashboard_setup() in wp-admin/index.php on line 15

Google confirmed the obvious; APC and WordPress didn’t get along (again), and the most common solution (next to switching from APC to XCache or eAccelerator) is to alter wp-admin/index.php by replacing
require_once(ABSPATH . 'wp-admin/includes/dashboard.php');
with
require_once('includes/dashboard.php');
But I prefer not to change code that is bound to be overwritten at every WordPress upgrade and surely other PHP-apps suffer from the same problem, so instead I tweaked APC by adding the following line to my configuration:
apc.include_once_override=0
This tells APC not to optimize include_once (it’s complicated). Why I have to explicitly specify this, if “0” is the default value anyhow, is beyond me though.

Fun with caching in PHP with APC (and others)

After installing APC, I looked through the documentation on php.net and noticed 3 interesting functions with regards to session-independent data caching in PHP;

When talking about caching, apc_delete might not be that important, as apc_store allows you to set the TTL (time to live) of the variable you’re storing. If you try to retrieve a stored variable which exceeded the TTL, APC will return FALSE, which tells you to update your cache.
All this means that adding 5 minutes worth of caching to your application could be as simple as doing;

if (($stringValue=apc_fetch($stringKey)) === FALSE) {
$stringValue = yourNormalDogSlowFunctionToGetValue($stringKey);
apc_store($stringKey,$stringValue,300);
}

From a security point-of-view however (esp. on a shared environment) the APC-functions should be considered extremely dangerous. There are no mechanisms to prevent a denial of service; everyone who “does PHP” on a server can fill the APC-cache entirely. Worse yet, using apc_cache_info you can get a list of all keys which you in turn can use to retrieve all associated values, meaning data theft can be an issue as well. But if you’re on a server of your own (and if you trust all php-scripts you install on there), the APC-functions can be sheer bliss!
And off course other opcode caching components such as XCache and eAccelerator offer similar functionality (although it’s disabled by default in eAccelerator because of the security concerns).

Trading eAccelerator for APC

Yesterday I somewhat reluctantly removed eAccelerator from my server (Debian Etch) and installed APC instead. Not because I wasn’t satisfied with performance of eAccelerator, but because the packaged version of it was not in the Debian repositories (Andrew McMillan provided the debs), and those debs weren’t upgraded at the same pace and thus broke my normal upgrade-routine. Moreover APC will apparently become a default part of PHP6 (making the Alternative PHP Cache the default opcode cache component). Installation was as easy as doing “pecl install apc” and adding apc to php.ini. Everything seems to be running as great as it did with eAccelerator (as most test seem to confirm).