Support » Plugin: W3 Total Cache » Problem with W3TC WPML Minify

  • Hi,

    I have been seeing errors for a while about files not being minified, because they were not found. If the file started with http://…/content/, the file would be minified in some cases –not all–, but if it started with content/, the file would not be found, even though the path was correct.

    After several hours of tracking down the problem, I found out that it is a problem related with WMPL and using language codes in the URL.

    For example, the root for our spanish version of the site, is /es, which is not a real path, and this was causing W3TC not to find the files unless they used the full http:// name (and even then, many were not found).

    The problem is in the w3_get_document_root() function. This is our expanded log for our test case:

    Site Root: C:/Inetpub/vhosts/
    Doc Root:
    PHP_SELF: /index.php/es
    SCRIPT_FILENAME: C:/Inetpub/vhosts/
    DOCUMENT_ROOT: C:/Inetpub/vhosts/
    PATH_TRANSLATED: C:\\Inetpub\\vhosts\\\\httpdocs\\index.php\\es
    Site Path: /content/
    Base Path: /C:/Inetpub/vhosts/
    File before normalize:
    File after normalize: C:/Inetpub/vhosts/
    File "/C:/Inetpub/vhosts/" doesn't exist

    In this case, w3_get_document_root() returns an empty string, which causes the w3_get_site_path() to return an incorrect path, which then causes the w3_normalize_file_minify2 function to return an incorrect result, which then causes W3TC not to find the file to minify.

    The reason for this is the following code in w3_get_document_root():

    } elseif (!empty($_SERVER['SCRIPT_FILENAME'])) {
      $document_root = substr(w3_path($_SERVER['SCRIPT_FILENAME']), 0, -strlen(w3_path($_SERVER['PHP_SELF'])));

    This would return an incorrect document root, caused by the /es path that WPML adds. When passed to realpath at the end of w3_get_document_root(), we get a blank result.

    To solve this issue, I commented out these two lines, so that the PATH_TRANSLATED server variable is used instead. In this case, all errors in locating files to be minified were gone from our site.

    I hope this helps!

    Best regards,

Viewing 1 replies (of 1 total)
  • Hmmm…

    W3TC is not removing the files from the HTML. After further inspection, the /es added by WPML is the source of the problem again. These are two examples of regexp used to find the tags to remove:

    Replaced JavaScript files:
    1. ((https?:)?//(www\.)?oursite\.com/es/)?/?content/wp\-content/themes/overall/js/cufon\-yui\.js
    2. ((https?:)?//(www\.)?oursite\.com/es/)?/?content/wp\-content/themes/overall/js/Futura_Bk_BT_400\.font\.js

    It should not include the /es. I replaced the call to w3_get_home_url_regexp with w3_get_domain_url_regexp, in the remove_scripts and remove_styles functions, but I have no clue if this would break things in other sites. It got the minify functionality to work on our site, for this particular scenario where WPML is being used.

    $home_url_regexp = w3_get_domain_url_regexp();

    Best regards,

Viewing 1 replies (of 1 total)
  • The topic ‘Problem with W3TC WPML Minify’ is closed to new replies.