ecartz

I am having the same problem. The .8 release loses the previous minify settings and I can’t add them back. I have done a Verify URI on the file path and the popup shows the CSS file.

If I do a view generated source after clicking the add stylesheet button, I see

<ol id="css_files">
                    			<li><input class="css_enabled" name="css_files_include[]" value="" size="100" type="text">&nbsp;<input class="css_file_delete css_enabled button" value="Delete" type="button">&nbsp;<input class="css_file_verify css_enabled button" value="Verify URI" type="button"></li></ol>
                <ol id="css_files"></ol>
    			<input id="css_file_add" class="css_enabled button" value="Add a style sheet" type="button">

However, if I look in the options function in lib/W3/Plugin/TotalCache.php I see

$css_files = W3_Request::get_array('css_files');

If I add _include to css_files there:

$css_files = W3_Request::get_array('css_files_include');

It changes the behavior and the CSS file setting that I enter shows on the subsequent page. However, it doesn’t actually include the CSS in the head. It does look like it removes the link if I enter one for the CSS manually in the head. I had to disable minify to get the site to work correctly.

I am just another user of this plugin, so don’t take my advice as gospel. However, my understanding is that the preferred place for javascript is footer, non-blocking. The impact of this is for the javascript to start loading after the HTML is almost completely loaded and it allows the HTML to finish loading before it actually runs the javascript.

In some cases, your javascript will need to be in the head as blocking so that it runs before the HTML loads (the HTML may include javascript that accesses the head javascript). In other cases, it will be sufficient for it to be in the footer as blocking.

In principle, the kind of javascript that needs to be blocking is javascript that actually displays content. I.e. it makes HTML appear on your page. The kind of javascript that needs to be in the head is the javascript that is called by javascript snippets throughout the body. For example, a function that does a document.write of some content that might be called in the page while it is rendering. Because it can control element position, CSS should always be head, blocking for this reason (and I don’t think that the plugin offers you an option to do CSS differently).

If you understand what all your javascript does well enough, you could figure out where it belongs. However, if you are just using the javascript (you didn’t write it yourself), you might try first setting everything as footer, non-blocking. Then, look around and see if the site works. If it doesn’t, move things to footer, blocking; head, non-blocking; head, blocking — (head, blocking should be last and footer, non-blocking should be first; I’m not as sure of the order of the middle two, but I think that footer, blocking will either work or not; head, non-blocking might seem to work in cases where you really want footer, blocking), and see if it fixes it. In general, you would prefer to have the javascript non-blocking and in the footer, but depending on how it is written, you might need to put it in the head and/or make it blocking to get it to work.

When testing your site, remember to clear your cache first, so that you have to load fresh copies of the javascript. That will highlight the kind of issues that a first time visitor to the site would see.