Posted 1 year 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.
Posted 1 year 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)
Posted 1 year 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.
Posted 1 year 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.
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.
Posted 1 year ago #
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?
Posted 1 year 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.
[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
Posted 1 year 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.
Posted 1 year 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:
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;
}
Posted 1 year ago #
Thank you. This approach makes a lot more sense.
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
Posted 1 year ago #
thank you!
Posted 1 year 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.
Posted 1 year 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!
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?
Posted 1 year 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.
This topic has been closed to new replies.
