Support » Plugins » [Plugin: W3 Total Cache] Unexpected CSS @import UriRewriter behaviour

  • I’ve been trying out W3 Total Cache with the intention of using it for CSS/JS minification and caching on a number of sites I maintain – however, I’ve noticed some unexpected behaviour with respect to the rewriting of CSS @import URI’s when debug is enabled and disabled. Basically, I’m finding that the URI rewriting ISN’T working when minification debug is DISABLED, and DOES work when minification debug is ENABLED.

    For the sake of this example, lets assume I’ve got a stylesheet (style.css) stored in the top level directory of my theme named ‘mytheme’ – and that this stylesheet file contains a single CSS @import statement containing a relative link to a PHP file (Conditional CSS) which generates the actual CSS output (which is stored in a subdirectory named ‘styles‘).

    So, I update the W3 Total Cache configuration to add the (relative) path to the theme stylesheet:


    The style.css file contains a single @import as follows:

    @import url("styles/c-css.php");

    The W3TC-generated CSS file is added to the HTML markup and is located at:


    When I view the contents of this file via my browser, the @import URI is unmodified – since the URI is relative it no longer resolves since the location of the W3TC-generated CSS file is different to the original CSS file.

    When I turned on the minification debug to figure out what was going on, and then viewed the contents of the W3TC-generated CSS file, the @import URI had been correctly rewritten to specify the full path from the document root of my installation, i.e.

    /* Minify_CSS_UriRewriter::$debugText
    docRoot    : /path/to/docroot
    currentDir : /path/to/docroot/wp-content/mytheme
    file-relative URI  : styles/c-css.php
    path prepended     : /path/to/docroot/wp-content/themes/mytheme/styles/c-css.php
    docroot stripped   : /wp-content/themes/mytheme/styles/c-css.php
    traversals removed : /wp-content/themes/mytheme/styles/c-css.php
    /* style.css */
    /* 1 */ @import url("/wp-content/themes/mytheme/styles/c-css.php");

    I’ve tried turning on and off minification debug and the results are repeatable and consistent. I’m not sure if its a result of some interaction or conflict with other plugins that I may have installed – I may retest with all other plugins disabled to see if the end result is the same.

    I’m using W3TC version

Viewing 10 replies - 1 through 10 (of 10 total)
  • Upon re-reading this, some of you may be thinking – why don’t I just bypass the style.css file and update W3 Total Cache’s configuration to point directly to the c-css.php file (and accept W3TC’s helpful warning about being sure that a .php file actually contains CSS). Yes, I could do that – but I’ve just simplified the scenario for the sake of understanding – and the fact remains, the URI rewriting DOES work as you would expect (on my test installation at least) when debugging is turned ON!

    Now that my interest has been piqued, I’m curious as to whether the same behaviour applies to any other URI’s defined in a CSS file (such as background images) – not just @import – and does it work recursively – what if one @import resolves to a file which also contains an @import definition or other types of URI… hmmm…

    Okay, I’ve re-tested with a nice clean WordPress 2.9.2 install and URI rewriting is working as expected – without debug needing to be turned on – so some other sort of interaction or conflict must be occurring with my original environment where I first tested – requires a little more detailed investigation – enabling/disabling plugins etc. With regard to URI rewriting for background images – this works, but not recursively – if I add a CSS file which @import‘s another CSS file containing other url(“/path/to/image”) definitions, the paths are not rewritten… 🙁

    Although thinking about it more – not rewriting url() paths in @import‘ed files would make sense – since the browser should interpret any relative paths relative to the location of the @import‘ed document – and not the one containing the @import statement – so you can safely ignore that last statement 🙂

    Further update – I disabled all plugins with the exception of W3TC – was still seeing the same behaviour – i.e. relative @import URI’s not being rewritten – however, when I unchecked the ‘Combine Only’ CSS minify option, the URI’s did get rewritten as I had expected – when I renabled this option – the URI’s didn’t get rewritten. I reactivated all the disabled plugins and repeated the tests – same result – so the other plugins were not interfering after all.

    As a final test, I repeated the same scenario with my new ‘clean’ WordPress install – same behaviour.

    Is this by design – is the ‘Combine Only’ mode deliberately not rewriting relative URI’s? Surely if you combine files in this way (regardless of whether you wish to minify them or not) it becomes necessary to perform this rewriting activity since the files may contain relative URI’s which are no longer valid in relation to the location of the W3TC-generated combined file? Perhaps I’m still overlooking something?

    Is this by design – is the ‘Combine Only’ mode deliberately not rewriting relative URI’s?

    Yes this is a bug that will be fixed in the next release.

    Ok – thanks for the clarification Frederick – I thought I was slowly but surely going mad 🙂

    A fantastic plugin in all other respects though!

    One further observation on the CSS @import front. If combining multiple different CSS files, each potentially containing one or more @import‘s, then all @import declarations need to be moved to the top of the combined document to comply with CSS standards – in fact, minify helpfully inserts an error message into the CSS document when this scenario occurs:

    /* See */

    In some cases it may be possible to re-order the CSS files in the W3TC configuration so that those with @imports are defined at the top of the list – but if you have more than two files with a combination of at least one @import definition followed by standard CSS markup (as I do – maybe I’m just being awkward!), then it will no longer be possible to handle this scenario through simple file ordering alone.

    The documentation at the minify-generated URL above suggests that minify supports a bubbleCssImports option (disabled by default) – which I assume means that all @import statements across multiple files are ‘bubbled’ to the top of the combined file automatically… I suppose its a call that the person installing and configuring the W3TC plugin needs to make since bubbling all @import‘s to the top may have unexpected side-effects if there are multiple CSS definitions for the same DOM elements and styling is applied in a different order than intended.

    I note that the w3-total-cache-config.php file contains a reference to this configuration option (bubbleCssImports) …

    'minify.options' => array(
                     <strong>'bubbleCssImports' => false,</strong>
                     'minApp' => array(
                             'groupsOnly' => false,
                             'maxFiles' => 20,

    …but I can’t see any way to influence this value through the W3 Total Cache plugin configuration screens. However, it seems I can make the change manually in the w3-total-cache-config.php and it remains intact, even after changing other configuration through the plugin screens – so I’m glad there is a way to do this – I assume its acceptable (at our own risk) to make minor changes to the w3-total-cache-config.php file for configuration options which are supported by underlying libraries, but not available via the plugin config screens?

    bubbleCssImports is unreliable and not supported. Additionally, lots of minify functionality is quite troublesome so new CSS optimization schemes will be available in the final release.

    Ok – thanks Frederick.

    You’re welcome.

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘[Plugin: W3 Total Cache] Unexpected CSS @import UriRewriter behaviour’ is closed to new replies.