• We’ve been using WP Super Cache for several months without a problem.

    Tonight, our homepage was downloading as a .gz file, instead of displaying properly. I tracked it down to a missing wp-content/cache/.htaccess file.

    Putting the file back in place solved it.

    I am not sure how this file went missing. From what I can tell, I do not see any unauthorized accesses to the server.

    Does anyone have any ideas how this file could have gotten deleted?

    Thanks.

Viewing 15 replies - 1 through 15 (of 21 total)
  • Thread Starter Bill Dennen

    (@xyzzy)

    I recently installed Role Scoper plugin. I noticed in its source that it has several mentions of “htacces” but I assume this means the main WP htaccess file and not this one in the cache.

    (Our main htaccess file is untouched)

    Thread Starter Bill Dennen

    (@xyzzy)

    There is definitely a connection to Role Scoper. I just saved some options in Role Scoper and it wiped out the contents of wp-content/cache/, including the .htaccess file.

    The htaccess file was owned by root, with 644 permissions, so it’s surprising that it got wiped out.

    Also, my supercache directory was wiped out too.

    It seems that Role Scoper is quite aggressive in deleting files in wp-content/cache.

    Still looking for advice.

    Thread Starter Bill Dennen

    (@xyzzy)

    The offending function seems to be:

    rm_cache_dir

    which is found in:

    wp-content/plugins/role-scoper/hardway/cache-persistent.php

    using Role Scoper 1.3.RC2.

    I’m sorry Role Scoper misbehaved in that way; thanks for reporting. You can correct it by editing function rm_cache_dir (in plugins/role-scoper/hardway/cache-persistent.php) as follows:

    add:

    if ( ! $group )
       return;

    to the top of the function. I’ll revise the RC version with this or an equivalent fix soon.

    Thread Starter Bill Dennen

    (@xyzzy)

    Thanks kevinB!

    Actually, here’s a further tweak to that fix:


    change:

    $group_dir = ( $group ) ? $this->get_group_dir($group) : '';

    to:

    $group_dir = ( $group ) ? $this->get_group_dir($group) : '';
    
    if ( ! $group_dir )
    	return;

    Thinking on this further, I’m not sure that code change will clear your error. Let me know.

    How can you tell function rm_cache_dir was the culprit?

    Are you running multisite?

    Thread Starter Bill Dennen

    (@xyzzy)

    Yes, I am running multisite.

    I’m not positive rm_cache_dir is the culprit. But, it was the function I found that seemed like it would be the one.

    I will try to test a bit later.

    [edited] I think you’re right. Multisite may be a factor here, because the cache storage path is different (stored right in the cache root) for group-related cache data if you have the “share groups site-wide” option enabled.

    If the above fix does not clear your symptoms, here is a further trap:

    change:

    if (@ is_dir($dir . DIRECTORY_SEPARATOR . $file))
    	$stack[] = $dir . DIRECTORY_SEPARATOR . $file;
    else if (@ is_file($dir . DIRECTORY_SEPARATOR . $file)) {
    	if ( file_exists($dir . DIRECTORY_SEPARATOR . $file) ) {
    		if ( !@ unlink($dir . DIRECTORY_SEPARATOR . $file)) {
    			$errors++;
    		}
    	}
    }

    to:

    if ( @ is_dir( $dir . DIRECTORY_SEPARATOR . $file ) )
    	$stack[] = $dir . DIRECTORY_SEPARATOR . $file;
    elseif ( $dir && ( $dir != rtrim( $this->cache_dir, DIRECTORY_SEPARATOR ) ) ) {
    	if ( @ is_file( $dir . DIRECTORY_SEPARATOR . $file ) ) {
    		if ( file_exists( $dir . DIRECTORY_SEPARATOR . $file ) ) {
    			if ( ! @ unlink( $dir . DIRECTORY_SEPARATOR . $file ) ) {
    				$errors++;
    			}
    		}
    	}
    }

    I reproduced this error on a multisite installation. The initial patches if ( ! $groups ) and if ( ! $group_dir ) are not valid because they prevent proper flushing of the RS cache.

    However, the larger code block change above does prevent the unwanted deletions. I will include it (with some optimization) in 1.2.9.RC3 and 1.3.RC3

    Thread Starter Bill Dennen

    (@xyzzy)

    Thanks. I tried 1.3RC3. The cache flushing routine safely avoids the .htaccess file, so that seems fine now.

    However, the routine simply deletes the WP Super Cache directories (blogs and supercache) (among others).

    Might it be better to call the cache flushing routines available in WP Super Cache? Deleting those directories seems rather drastic.

    Thanks.

    Alright, here’s a better fix – moving the entire RS cache to a subfolder. I never meant to delete other plugins’ wp-cache content, and this will prevent it:

    • all other patches listed here can be skipped or reverted
    • edit function WP_Persistent_Object_Cache in role-scoper/hardway/cache-persistent.php as follows:

    Add the following code above the existing CACHE_EXPIRATION_TIME line :

    $this->cache_dir = $this->cache_dir . 'rs/';
    
    if ( ! file_exists( $this->cache_dir ) ) {
    	if ( @ mkdir( $this->cache_dir ) ) {
    	   $stat = stat(WP_CONTENT_DIR);
    	   $dir_perms = $stat['mode'] & 0007777;
    	   @ chmod( $this->cache_dir, $dir_perms );
            } else
    	   $this->cache_enabled = false;
    }
    Thread Starter Bill Dennen

    (@xyzzy)

    Thank you. This approach makes a lot more sense.

Viewing 15 replies - 1 through 15 (of 21 total)
  • The topic ‘[Plugin: WP Super Cache] wp-content/cache/.htaccess file went missing’ is closed to new replies.