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

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 https://code.google.com/p/minify/wiki/CommonProblems#@imports_can_appear_in_invalid_locations_in_combined_CSS_files */

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.