I’m trying to get all relevant topics in the forum updated to help folks know why they having trouble with the update. It’s not the additional features, those have been tested with enterprise and paying customers week over week for the past year, it’s switching file management to use the WP FileSystem API at the suggestion of WP core developers, which is simply not working out obviously. Because W3TC creates files, if *anything* goes wrong with file management, the user’s experience is going to be terrible… obviously. Other plugins don’t have to worry about this at all, which the reason why this is so bothersome to users. Making a server faster requires changing it’s behavior, there’s nothing I can do differently especially with millions of possible environments to deal with.
So I’m sorry for the trouble, but the intent was to do things the “WP Way” and have everyone benefit from what the core developers have learned over the years. We will continue to work behind the scenes to that end, but for the moment the updated releases are reverting activation and file management BACK to the way things worked just fine before, once done, the great new features will work just fine for you.
For those with MaxCDN as a CDN provider, issues there are with their updated API. For those with Cloudflare, issues there arise from updates to their new API (you know have far more control of your account from within W3TC and better integration with their platform).
Thanks for trying W3TC, if there were a simple way create files and folders via PHP in a secure way on every single server and environment out there then clearly we would take that route. If we hadn’t have tried to follow recommendations, no changes to install, activation, update etc would have been made and people would stop calling us names… maybe.
minify doesn’t work at all, not even in 0.9.2.8.
I’ve tried this on a couple of installs and it’s not working. It doesn’t matter what settings are used for minifying the files. It’s pointless.
It would be great to have a look at your server environment. Some don’t seem to believe it but tons of testers, paying customers and hosts all test this stuff working before every release.
I have no idea what’s special about the server right now.
However, I can tell you I just got this exact same problem with the minification on xampp 1.7.7 with a fresh wordpress 3.5.1 install with w3tc 0.9.2.8.
That means I was using the default theme and only had w3tc installed.
I installed a clean wordpress 3.5.1 from the website, went straight to the plugin management section and installed w3tc. I enabled page cache and minification. Page cache seems to have worked. Minification doesn’t work.
I keep getting this no matter what settings, permissions and server environment I use (always apache with .htaccess, rewrites and all are enabled):
It appears Minify URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess. Or if using nginx verify all configuration files are included in the main configuration fail (and that you have reloaded / restarted nginx).
WHY is that shown? What is it trying to detect and keeps failing to detect? The pages can’t load their CSS & JS because minification doesn’t work.
I’ve discovered why I was having problems. It looks like the URLs and the rewrite base are wrong.
For an install running on the localhost at /wordpress/ with the default settings and minify enabled with auto, the following URLs are generated:
http://127.0.0.1/wordpress/%5Cwordpress/wp-content/cache/minify/000000/M9AvLqnMSQUA.css
The rewrite base is also off (might be caused by Windows):
RewriteBase \wordpress/wp-content/cache/minify/
Changing the rewrite base to /wordpress/wp-content/cache/minify/ seems to fix loading the file http://127.0.0.1/wordpress/wp-content/cache/minify/000000/M9AvLqnMSQUA.css ; the cache directory and the file seem to be correctly minified in that case.
Simply loading the page still makes it use the wrong URLs with the extra “%5Cwordpress”.
The issue really seems to be related to running wordpress from “/something/” instead of /.
I can confirm that the live systems are also having the problem with the double path.
I’m getting /blog/blog/wp-content instead of /blog/wp-content in the HTML as paths to the minified files.
The base rewrite path isn’t broken as it is on Windows. That’s a windows only problem.
The issue really seems to be related to running wordpress from “/something/” instead of /.
I can confirm I have the same problem on a Linux Centos system with cpanel. The total cache minify doesn’t work on a wordpress subfolder with the latest version of total cache (0.9.2.8). I confirmed this also with a new installation of wordpress to be sure without any plugings. It’s working fine on the / (root) btw.
I can confirm I have the same problem on a Linux Centos system with cpanel. The total cache minify doesn’t work on a wordpress subfolder with the latest version of total cache (0.9.2.8). I confirmed this also with a new installation of wordpress to be sure without any plugings. It’s working fine on the / (root) btw.
This is good to hear. We know this is really an issue now as it’s been discovered by at least 2 persons now. Thank you.
Hey John. You are a jerk! Your tone is embarrassing.
