[wp-hackers] Bizarre /cache/ experience with wp_object_cache.lock
ryan at boren.nu
Fri Feb 3 07:09:43 GMT 2006
Mark Jaquith wrote:
> I just had a rather strange experience with the object cache. I just
> moved my site to a new server, and I deleted the contents of the /wp-
> content/cache/ directory before moving. At the new host, I was getting
> 80+ queries on my front page (redundant option hits). I chown/chmod'd
> my /cache/ directory into oblivion... I was confident that I had it set
> correctly... but nothing. Then, out of desperation, I started moving
> files from another WP install's cache into my cache. Once I moved
> wp_object_cache.lock into my /cache/ directory, it started working.
> I took out all the error suppressing @s from /wp-includes/cache.php in
> an effort to try to get it to throw an fopen() error, but it didn't
> make a peep. If /cache/ wasn't there, it wouldn't be created, even
> though the permissions were set up so that it could.
> Why can't WordPress create this file? Why wasn't WordPress reverting
> to the old caching method (i.e. select all options where autoload = '1'
> and store them in memory for that load)?
We were seeing this with safe_mode enabled, which is why the cache is
now disabled if safe_mode is on. What happens in the safe_mode case is
that WP thinks it can write because is_writable() returns true. The
cache isn't really writable, however, and later attempts to write to the
cache fail. We don't revert to the old method because is_writable() is
telling us that we are able to write to the cache even though that isn't
More information about the wp-hackers