johndoej

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.

As I’ve asked in another thread before songdogtech closed the thread and also said I was “hijacking the thread”: are you running wordpress under some subdirectory?

This is a bug I can reproduce when running wordpress from /anything/, but not when running from https://www.domain.tld/.

Please let me know if you’re running it from /.
You can post here if you’re running it from a subdirectory:
another bug report

Are you running wordpress under https://domain.tld/sometihng/ ? I’m having problems with the exact same thing.

If you don’t have it under /something/ and it’s directly on the root domain, then you’re having a different problem.

You need to uninstall the latest version and install version 0.9.2.5.

That should make it work.

Are you running your site from anything but the root domain?
If your site is at /blog/ or something like that, you won’t have working minification.

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.

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:
https://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 https://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 /.

w3tc is terribly broken right now. Originally, I thought I was having problems because of my setup.

After having performed a couple of tests, I’ve seen that’s not the case and that there are some very serious bugs. Even when loading pages from the local machine, it still takes about 146ms to load the HTML of a cached page. That used to take like 5-15ms when loading it from localhost.

The good news is that this plugin may just make me switch away from wordpress. Without w3tc, it’s useless to me. It can’t handle the traffic I’m getting.

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.

As soon as I upgraded to 0.9.2.8 the page load times increased to approx 3s, the big increase was due to an extra approx 2s time to first byte wait.

If I uninstall 0.9.2.8 on one site and reinstall 0.9.2.5 the page load time drops again to 1.2s, the other sites running 0.9.2.8 still have 2s TTFB times.

Putting 0.9.2.8 back on again increases the load time.

NOTE simply deactivating the plugin didn’t work, nor did uninstalling it, I had to reinstall the old version for the time to first byte times to go back to normal.

It looks like it’s not caching anything. It’s either that or that and other bugs in w3tc.

Agreed, something is wrong with 0.9.2.8. The admin backend is running in slow motion on two websites with 0.9.2.8. It’s also 100% useless because minification is entirely broken.

I’ve asked this question because nothing seemed to fix w3 total cache after completely wiping and reinstalling 0.9.2.7.

0.9.2.8 has pretty much the same issues for me. minify doesn’t work no matter what. Since 0.9.2.5 was working, I’d say something is STILL broken.

w3tc 0.9.2.5+ won’t create the minified files at all. It simply says it can’t get the rewrite to work for the minified files. But there’s no such problem at all. rewrites are working in apache and everything is as it should be. I have tried all sorts of permissions and other things.

I have even completely uninstalled and reinstalled w3tc using the latest version and it’s still not working. Since the exact same system works with 0.9.2.5, I believe it’s a problem with w3tc and not a problem with the server setup.

The plugin has the same problems on other machines. Something is STILL terribly broken. I’ll try WP Super cache, maybe that plugin is more useful.

It’s broken in 0.9.2.8. It’s still broken.

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.

I’ve had a similar problem with this plugin.
Fortunately, I was able to get into the admin area and disable it.

The websites have been completely messed up since the last updates due to this plugin. It’s a pain to use and update. I can’t even tell if something works or not any more. It’s TERRIBLY BROKEN, just kill it with fire!!!