Same problem here, I upgraded from the intermediate release you sent me to 0.9.2.11 and now the cache is serving only empty pages.
The first time, when the page is generated, it’s ok but then pages coming from the cache are empty.
And although that makes for a tremendous performance enhancement my client is complaining 😉
Do you have page cache debug enabled ? It is happening by me only when page cache debug is enabled.
I’ve had to de-active W3TC due to this very problem (well, that and minifaction not working, either).
And with regards to the above: I don’t have page cache debugging enabled.
Which Page Cache engine was used, were debug enabled disabled? Does it work when Page Cache disabled? If you are not using Disc Enhanced do you have the same issue if you enable Late init?
If changing engine does not work as intermediary solution can you send us a bug report from the Support page in the plugin?
Which Page Cache engine was used, were debug enabled disabled? Does it work when Page Cache disabled? If you are not using Disc Enhanced do you have the same issue if you enable Late init?
If changing engine does not work as intermediary solution can you send us a bug report from the Support page in the plugin?
Enabling “Late init” for me, just seems to turn off caching of the page and so it is displayed. The debug info for page cache is missing.
Clearing Late init, and enabling page debug, for a logged in user the page displays and shows the debug data.
Logout and a blank Server 500 error.
Using AWS Elesticache, but same results using the internal disk cache.
I’ve got the same problem here, Page Cache on disk (enhanced) shows no error, but as soon as I turn on Page Cache debug, the pages only get served once, with “cache on” at the bottom of the source code, and after that its just a blank page being served. Also, when turning Page Cache Debug on, there is this error msg in the admin:
W3 Total Cache error: It appears Page Cache URL rewriting is not working. Please verify that the server configuration allows .htaccess
Unfortunately disk enhanced page caching will not function without custom rewrite rules. Please ask your server administrator for assistance. Also refer to the install page for the rules for your server.
Technical info:
.htaccess file contains rules to rewrite url http://www.mysite.com/w3tc_rewrite_test into http://www.mysite.com/?w3tc_rewrite_test which, if handled by plugin, return "OK" message.
The plugin made a request to http://www.mysite.com/w3tc_rewrite_test but received:
200 OK
instead of "OK" response.
dont know if thats related to the problem.
My htacess files are writeable,
@marcosmyara,
Yeah, I think I have the same problem and have written some more details about it in this post:
http://wordpress.org/support/topic/w3tc-disk_enhanced-page-caching-gzip-debugging?replies=1
I believe a number of us are having the same issue, because the post before this one seems to have the same symptoms.
Summary: it has something to do with page-caching support for gzip encoded responses. Try accessing your site with
curl -v <url>
to see if it works. Curl does not send the “Accept-encoding: gzip” header by default, so if it is the same issue as me, then it should work for you.
I cant test that anymore at the moment, since the problem has escalated to something way worse than that.
I have uninstalled all traces of w3 total cache, and still, my home page is STUCK. minified and cached. nothing will change the content of it, not even changing the “reading” options on wp-admin to make the home page a static page. whats being shown is a cached version of the paged, and I dont know how thats happening, its only the home page. i can even delete the index.php from my theme, nothing happens.
@marcosmyara:
Tough break. I have *zero* experience with wordpress, but I can make a few suggestions based on my experience with this caching problem:
It sounds to me like your site is being served from static pages by the apache/nginx webserver instead of php/wp scripts.
My setup is with nginx, and w3tc (asked me to) install rules in the nginx config file that specifies roughly the following: “when a static file exists in a certain directory, then rewrite the current request to that file and serve it instead of sending the request to php-fpm.”
It is conceivable that your setup has similar rules (with either apache or nginx). One thing that you might consider is to look into the
wp-content/cache/page_enhanced/
directory and poke around to determine if the home page that is being served is one of the static files in that directory. If so, I believe you can totally blow away that page_enhanced directory (or to be safe, move it to another name), and your webserver should then pass those requests on to your php/wp backend.
More generally, you want to get your webserver to stop serving these static files.
I just spent the whole day on this. and as it turns out, W3 Total Cache created an Index.html file on my root folder, and left that behind even after a complete uninstall. So it was just a matter of deleting that and everything would be back to normal, but who’d have thought? 12 hours straight on this issue!!!
