W3 Total Cache
Problem with W3TC + WPML + Minify (2 posts)

  1. amvbsd
    Posted 2 years ago #


    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/oursite.com/httpdocs/content
    Doc Root:
    PHP_SELF: /index.php/es
    SCRIPT_FILENAME: C:/Inetpub/vhosts/oursite.com/httpdocs/index.php
    DOCUMENT_ROOT: C:/Inetpub/vhosts/oursite.com/httpdocs
    PATH_TRANSLATED: C:\\Inetpub\\vhosts\\oursite.com\\httpdocs\\index.php\\es
    Site Path: /content/
    Base Path: /C:/Inetpub/vhosts/oursite.com/httpdocs/content/
    File before normalize: http://www.oursite.com/content/wp-content/plugins/sitepress-multilingual-cms/res/css/language-selector.css?ver=2.6.0
    File after normalize: C:/Inetpub/vhosts/oursite.com/httpdocs/content/wp-content/plugins/sitepress-multilingual-cms/res/css/language-selector.css
    File "/C:/Inetpub/vhosts/oursite.com/httpdocs/content/wp-content/plugins/sitepress-multilingual-cms/res/css/language-selector.css" 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,


  2. amvbsd
    Posted 2 years ago #


    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,

Topic Closed

This topic has been closed to new replies.

About this Plugin

  • W3 Total Cache
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic


No tags yet.