WordPress.org

Ready to get started?Download WordPress

Forums

WP Super Cache
wp-content/cache/.htaccess file went missing (22 posts)

  1. Bill Dennen
    Member
    Posted 3 years ago #

    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.

  2. Bill Dennen
    Member
    Posted 3 years ago #

    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)

  3. Bill Dennen
    Member
    Posted 3 years ago #

    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.

  4. Bill Dennen
    Member
    Posted 3 years ago #

    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.

  5. kevinB
    Member
    Posted 3 years ago #

    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.

  6. Bill Dennen
    Member
    Posted 3 years ago #

    Thanks kevinB!

  7. kevinB
    Member
    Posted 3 years ago #

    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;
  8. kevinB
    Member
    Posted 3 years ago #

    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?

  9. kevinB
    Member
    Posted 3 years ago #

    Are you running multisite?

  10. Bill Dennen
    Member
    Posted 3 years ago #

    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.

  11. kevinB
    Member
    Posted 3 years ago #

    [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++;
    			}
    		}
    	}
    }
  12. kevinB
    Member
    Posted 3 years ago #

    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

  13. Bill Dennen
    Member
    Posted 3 years ago #

    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.

  14. jittipat
    Member
    Posted 3 years ago #

    Thanks.

  15. kevinB
    Member
    Posted 3 years ago #

    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;
    }
  16. Bill Dennen
    Member
    Posted 3 years ago #

    Thank you. This approach makes a lot more sense.

  17. kevinB
    Member
    Posted 3 years ago #

    Just to clarify, this fix is not yet included in any Role Scoper version. The next version to include it would be 1.3.RC4 or 1.3

  18. Bill Dennen
    Member
    Posted 3 years ago #

    thank you!

  19. royoel
    Member
    Posted 3 years ago #

    I am new user of two days and I will say that Role Scoper appears to rather complex for me and I have not found a good guide to use so far. The problem is simply me as I do not have the experience.

    I was looking for another issue solution and came across this one. I am running 1.3.31 and when I check the file structure I did not see this file located in the /wp-content/cache folder. I only have the folder rs in that directory.

    In another post 6 months ago someone posted that they received a 500 server error after they updated, although unrelated, it steered me here in another search.

    So am I missing this .htaccess file or is it in one of the subfolders?

    The reason I was looking for a solution was that my problem is that unless I am logged in as an admin I can not post any comments to my posts whether I am logged in or not.

    I have one category and post exposed to the general public all of the others are hidden. This is to allow the general public to add comments and cause interaction between the membership.

    I will create another post for that issue, but if you could update me on the .htaccess file that would be stellar.

  20. Donncha O Caoimh
    Member
    Plugin Author

    Posted 3 years ago #

    royel - you might be better off using PHP caching mode to serve cached pages. No need for .htaccess files and it's 99.99999% as fast!

  21. kevinB
    Member
    Posted 3 years ago #

    Absence of an .htaccess file in the wp-content/cache/uploads folder just means Role Scoper is not filtering any uploaded files (Roles > Options > File Filtering). It has nothing to do with your inability to post comments. And the 500 error was only with PHP4.

    Regarding the comment posting issue, I'll need more details on your configuration and usage because I'm not seeing the error. Where exactly is the failure? Missing "post comment" link? Link is ineffective? Comment entry form displays but submission fails? Are you sure the issue is non-creation of comments and not non-display?

    Does this still occur if you temporarily switch to the default theme? If all other plugins are disabled?

    What RS Restrictions and Roles did you set? Any customized role definitions or option changes?

  22. royoel
    Member
    Posted 3 years ago #

    Thank you for the replies and I created this post early this morning to discuss my issue. I believe I found the root cause, but need to test some more today.

    I will ignore the .htaccess file as it has nothing to me apparently.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic