[Plugin: W3 Total Cache] Minify Rewrite Error Found (Fix Here)

  • Hey all. I have been pounding my head against a wall for the last few days trying to figure out what configuration problems were preventing me from getting Minify rewrites working, which in turn prevents uploading minified files to a CDN.

    My shared hosting account forced me to install my account attached domain name at the base of the public_html directory. This would mean that all the WP directories would be mixed in with the directories of my other websites. So I installed WP in a directory. So my website’s file structure is like this:

    https://www.domain.com
    https://www.domain.com/wp/wp-content

    The problem is the way W3TC tests for the minify rewrite ability. It doesn’t take into account the auxiliary directories that WP might be installed into.

    Here is the fix I have made in my code. Frederick might want to change it for official inclusion to the plugin and that’s fine with me. I just hope this fix get’s included so I don’t have to hack any updates to correct the issue.

    FIX:
    wp-content/plugins/w3-total-cache/inc/define.php
    add this line after WP_CONTENT_DIR_PATH is defined (line 41 in my file)

    define('WP_AUX_INSTALL_DIR', (strcasecmp($_SERVER['DOCUMENT_ROOT'], WP_CONTENT_DIR_PATH) == "") ? "" : (ltrim(str_ireplace($_SERVER['DOCUMENT_ROOT'], '', WP_CONTENT_DIR_PATH), '/') . '/'));

    wp-content/plugins/w3-total-cache/lib/W3/Plugin/TotalCacheAdmin.php
    In the function test_rewrite_minify() (line 5275) change:

    $url = sprintf('%s/%s/w3tc_rewrite_test', w3_get_home_url(), W3TC_CONTENT_MINIFY_DIR_NAME);

    to

    $url = sprintf('%s/%s%s/w3tc_rewrite_test', w3_get_home_url(), WP_AUX_INSTALL_DIR, W3TC_CONTENT_MINIFY_DIR_NAME);

    Now both your Minify rewrites will work and you will be able to upload your minified files to your CDN. Yay!

    https://www.ads-software.com/extend/plugins/w3-total-cache/

Viewing 8 replies - 1 through 8 (of 8 total)

  • Been using w3tc for a while but after updating to the latest version I started getting:
    “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 configuration.”

    If I deactivate the plugin and then reactivate again – all is fine (for about 6 hours or so) and then the error occurs again.

    Have tried all the usual: toggling permalinks, rewriting the .htaccess rules, even completely reinstalled the plugin – but nothing seems to stick.
    I have a VPS server with WP installed in my public_html folder. I use APC opcode, but minify IS the one thing that gives me the biggest performance gains.
    Might this be a bug in Version 0.9.2.4?

    Thread Starter haddow777

    (@haddow777)

    It’s entirely possible. My problem was due to a bug. Unfortunately your issue seems to be separate from mine. My problem was caused from having WP install in a directory above the main site directory.

    Also, it seems to me that you are using Apache. I am using Nginx + php-fpm, so the rewrites are different in how they are configured.

    From my understanding, Apache uses more than one .htaccess file to configure the rewrites. When you reinstalled the plugin, did you remove all the .htaccess files? (by remove, I mean copy them to htaccessbak just in case). W3TC should then create totally new .htaccess files for you.

    Also, do you have other plugins that write to .htaccess files? Even old ones you no longer use? A drastic test you can make is to uninstall W3TC, disable all other plugins, remove all .htaccess files in your wordpress directory and W3TC directories. Then reinstall W3TC and see if the issue happens again. This would at least show you if there is a conflict with another plugin.

    To me, it seems like it might not be a problem with W3TC. If it works to begin with, this means that W3TC wrote out a proper configuration for your .htaccess. The fact that this changes later seems to imply an outside influence on your configuration. Why would W3TC get it right only to later get it wrong.

    In fact, another approach that might work better for you is this. Repeat the exact steps you took to get it working again. Once it is working, make copies of all your configuration files. Reload Apache just to be sure everything is starting fresh and is working. If the it stops working again, compare all of your configuration files. This will tell you if it is indeed a configuration problem.

    Sorry I can’t be more helpful, hopefully this gives you some ideas.

    @ haddow777
    Thanks for your most kind & detailed suggestions.

    Spent 2 days now trying to fix this: followed some of your suggestions and the .htaccess code for w3tc in not being changed in any way.
    This problem has only surfaced for me with the update to Ver 0.9.2.4

    Sometimes updates do not ‘take’ properly – I have noticed that w3tc does not delete previous .htaccess and some other files with an update, rather it seems to just append the new ones.
    A complete clean reinstall should fix any such problem – but not in this case.

    Before finally rolling back to the previous version, I did try just one more thing:
    I have always used the ‘Manual’ minify mode, as previously this was the only way to exclude some js & css from breaking my site.
    ‘Auto’ mode is supposed to have been further improved with this latest version, and guess what – it really has been!

    Doesn’t break my site anymore, speed is just as good, and so far – (fingers crossed) minify is still working.

    I’ll report my findings again in a day or so, and if minify is still working in Auto mode; then that certainly smells like a bug to me!

    Naa,

    tried every possible configuration of minify with this plugin, and all eventually come up with the same error:

    “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 configuration.”

    When this error is visible my site is of course broken, AND I get the warning from my antivirus (Eset Nod 32) that various Trojans now live on my site (various JS/Iframe.DU/DY trojans in the w3ts/min/a660c/default.include files).

    Minify lifts my yslow score from 81 to 90, so I would like to get this working.

    Now going to submit a possible bug ticket.

    This huge chunk of code keeps getting added to the top of my wp-content/w3tc/min/index.php:

    <?php eval(base64_decode(‘ZXJyb3JfcmVwb3J0aW5nKDApOw0KJGJv —————Q0K’));?>
    <?php

    Looks suspect to me, and according to Exploit Scanner; the <?php eval bit can be used to execute malicious code, and the (base64_decode bit can be used by malicious scripts to decode previously obscured data/programs.

    Is anybody able to shed some light on this?
    Is this normal W3 Total Cache behaviour, and is this code legit?

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    That’s not normal W3TC behavior, you may want to look and see if you’ve been hacked or not…

    Thanks Jan,

    Yep you’re right – I have been hacked.
    This time an PHP/krptik.AB trojan got injected into my wp-content/w3tc/min/index.php file.

    Nod32 wouldn’t even let me open the file (via FTP) to remove the offending code.

    This is only being injected into the wtc/min/index.php file – if I switch minify on.

    Scanned my website with https://sucuri.net as recommended by Willie Jackson, Senior Marketer and Engineer W3 EDGE (thanks Willie) but my site comes up clean. I have also checked all the directories on my server for any suspicious code – and nothing I can see.

    This only happened after I upgraded both WordPress, and a fair few other plugins I use including w3Total Cache.

    This means: the code that allows some *#^+ asshole to do this, has obviously been put into one of these upgraded plugins – or my database.

    I run an identical test website on the same VPS server, that has not been affected with the same upgrade. That makes me suspect the database.
    I vote for a ‘mandatory death sentence’ for all hackers!

    Thread Starter haddow777

    (@haddow777)

    Sorry I didn’t get back to you. I was out of town away from computer for the last while and this forum doesn’t mix well with my cellphone.

    I don’t think I could have been of much help here though.

    I guess you could try manually doing like searches through your wordpress database tables to see if you can find a pattern match to was is being inserted into your rewrite.

    Not a great idea maybe, but a stab in the dark.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘[Plugin: W3 Total Cache] Minify Rewrite Error Found (Fix Here)’ is closed to new replies.