ballinascreen

Ok – thanks Frederick.

I would assume the tag cloud is based on the most popular tags associated with your pages/posts – I assume when you create new posts you assign tags to them, right?

I guess you could always write a plugin of your own that accepts an appropriate HTTP request, checks if the required plugin is active and returns a response. However, if your plugin is responsible for generating the form contents, then I can’t see why your plugin can’t check if the appropriate plugin(s) are active, before generating the form content in the first place – is it likely that a plugin could be enabled/disabled during the time that someone is viewing the form – and would potentially invalidate it?

Probably would help to specify:

(a) the plugin name and version
(b) what version of WordPress you’re using
(c) any other pertinent information about your WordPress environment – OS, PHP version, web server…

For what its worth, a simple Google on your subject title throws up quite a few articles on the issue (not necessarily solutions). Probably stating the obvious here – but have you looked at the header of the plugin in question – and is it actually valid?

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?

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

A fantastic plugin in all other respects though!

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?

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 ??

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… ??

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…

Perhaps you could provide a little more detail – what behaviour do you see – if anything? Any (Javascript) error messages? Did it work correctly in earlier versions of WordPress – have you just upgraded to 2.9.2 – have you updated Lightbox 2 recently – have you updated or installed any other plugins recently that might conflict with it…?

Just a guess – but could it be a permissions problem with the plugins directory? Make sure it is writable by your user (or the user that the web server runs as if it is different). Alternatively, just manually extract the contents of the plugin zip file and manually FTP them to your WordPress plugin directory.

You, my friend, are a star! Works for me too!

Much appreciated.

Yep – translates to a 1×1 pixel iframe which then attempts to load content from a php script at iss9w8s89xx.org – however, the domain name no longer resolves or appears to be active.

@leisegang

86b2522768eb8c9ce026779ddf4f3b24