robertstaddon

I just submitted a bug report. Thanks for taking a look!

Update: If “Page Cache Debug Mode” is turned on under Performance > General Settings, the posts page cache successfully flushes even if a static home page has been set!

It is interesting to note that GZIP files are not generated when Debug Mode is turned on. This may be related to the issue.

Hello Snackmaster!

I’m having the same problem. Under Settings > Reading Settings I have my front page displaying as a static page and my posts displayed on a blog page.

However, whenever I post a new post, W3 Total Cache doesn’t automatically purge the blog page out of the cache. So non-admins see the old cached posts page without the new post. I have to manually clear the W3 Cache.

It works fine if I turn off the static home page. But I need that option.

Did you ever find a solution?

Specs:
WP 3.3.1
W3 Total Cache 0.9.2.4

I have the exact same question. I don’t remember it being set up this way before either. I think it’s new in 0.9.2.4. I’m concerned because this seems to be breaking a measure of compatibility with WordPress multisite. I have dozens of sites set up and I don’t want think I need all this multiple sets of code in my .htaccess file.

Problem solved!

While troubleshooting the “500 Internal Error” from the last release, I had mistakenly gotten the idea that I needed to manually put the /wp-content/plugins/w3-total-cache/wp-content/ files into the /wp-content/ directory.

So now it makes sense. The plugin was trying to automatically copy the files into the /wp-content/ directory and failed because they weren’t there to copy. But it assumed that the reason it couldn’t copy was because /wp-content/ wasn’t 777, even though it really was.

Works perfectly now! Thank you, Frederick. You have a great plugin and you provide great support. I think every blog out there ought to be using it.

I just tried an experiment that failed miserably.

1. I made sure that the latest versions of advanced-cache.php, db.php, and object-cache.php were properly placed in the /wp-content/ folder.
2. I manually created a /wp-content/w3tc-[mydomain].com/ directory with sub-directories named dbcache, log, min, objectcache, pgcache, and tmp.

With this all set up, I tried to activate the plugin. It generated the fatal error again, but this time it looked like this:

Plugin could not be activated because it triggered a fatal error.
/[path]/domains/[mydomain].com/html/wp-content/db.php  could not be created, please run following command:
chmod 777 /[path]/domains/[mydomain].com/html/wp-content

But the db.php didn’t need to be created! I had already copied it into the wp-content folder a day earlier!

I accessed the site with FTP and found that the plugin activation attempt had deleted the advanced-cache.php, db.php, and object-cache.php files in /wp-content/ and the entire directory structure that I had created above. They were gone! Activating this plugin causes it to eat its own files.

There appears to be a serious bug in the activation code.

@sjeng, I have made the /wp-content/ folder 777, so I would think that any plugin should have the permission to create subdirectories without a problem.

I do have a /wp-content/w3tc/ folder. However, I’m running WordPress MU 2.9.2. The plugin should be creating /wp-content/w3tc-[mydomain].com folders for every separate domain that the plugin gets activated on. These store the cache files for that particular domain.

Unfortunately, it appears that on MediaTemple GS running MU 2.9.2 a bug in the latest releases of 0.9.0 and 0.9.1 have lost the ability to create these folders when the plugin is activated on a new domain, generating fatal input errors.

Hmmm. I’m still getting the fatal error.

I completely uninstalled the 0.9.0 plugin and deleted all associated config files. Then I did a clean automatic install of the 0.9.1 plugin. I had to manually copy over the files in wp-content/plugins/w3-total-cache/wp-content/ to my wp-content directory.

When I tried to activate, I got this error

Plugin could not be activated because it triggered a fatal error.
/[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com/pgcache  could not be created, please run following command:
chmod 777 /[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com/pgcache

The wp-content is still set to 777 and has been for a full day now. I even set the wp-config.php to 777 based on @Sjengs’s suggestion. Are there other files/folders I need to set to 777?

Weirdly enough, the files I had manually copied over to the wp-content directory (advanced-cache.php, db.php, and object-cache.php) mysteriously disappeared. Activating this plugin eats files?

I manually re-copied the files to wp-content and then tried activating the plugin again. Once again it “ate” those files and I got the following error message:

Plugin could not be activated because it triggered a fatal error.
/[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com could not be created, please run following command:
chmod 777 /[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com

I’m a bit bewildered. Would you like an FTP login to my site?

I believe I had the same problem. I traced it back to the fact that the automatic upgrade did not upgrade the advanced-cache.php, db.php, and object-cache.php files in the wp-content directory. When I manually upgraded these, the plugin began escaping characters correctly in the .htaccess file.

I had 500 Internal Server Errors when I upgraded to the latest version and copied the new suggested rules into my .htaccess file. I figured out that the RewriteCond %{HTTP_USER_AGENT} line was not properly escaped.

In my case, this happened because the automatic upgrade/install had not automatically replaced the old db.php, advanced-cache.php, and object-cache.php files in the wp-content directory.

After replacing these files with the new versions, the suggested code to paste into my .htaccess file suddenly had the proper escape characters. I copied this code into my .htaccess file and it solved my 500 Internal Server Errors.

fredericktownes, would you recommend that I post this question on the WordPressMU forums instead of here? It is true that it only applies to a WordPressMU installation.

It’s not really a 404 error. If I FTP into my server and remove the file completely, I get the “file not found” message.

When W3TC is active, a web browser will find large files but can only download 0kb of them. Try to download the two top example files above and you’ll see what I mean. If the W3TC plugin is deactivated, you would be able to download them entirely.

Here’s how to consistently replicate the problem:
– Install WordPressMU
– Install and activate W3TC
– FTP upload a large file (>20MB) into wp-content/blogs.dir/1/files/ or any subdirectory
– Try to access that file via a web browser