CTools adds missing css files to the page via ajaxresponder.css.
Drupal.CTools.AJAX.commands.css_files = function(data) {
// Build a list of scripts already loaded:
$('link:not(.ctools-temporary-css)').each(function () {
if ($(this).attr('type') == 'text/css') {
Drupal.CTools.AJAX.css[$(this).attr('href')] = $(this).attr('href');
}
});
If Performance -> CSS Optimization is enabled, all stylesheets get attached again. Adding the system css files later, will normally kill any custom layout because the system css rules are now stronger. I think it is not possible for the ajax-responder.js file to determin, which css should be added without having a list of all css files used on the current page.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | ctools-dialog-api-stylesheets.patch | 553 bytes | ayalon |
Comments
Comment #1
merlinofchaos commentedIt maintains this list currently in a cache, and those files *should* be removed prior to sending. I actually thing we have this implemented kind of wrong right now, but everything I have shows that it works. Do you have an instance where this is not working?
Comment #2
merlinofchaos commentedWe are now maintaining a list of CSS files that were put into the aggregation so that the code can skip them. This should alleviate the problem. The thing is, we were doing this when this issue was posted. So I'm a little concerned there is soemthing else gone here.
That said, it is working for me, so marking postponed looking for some confirmation (and easy repro instructions) that this is still happening.
Comment #3
sociotech commentedmerlinofchaos,
We're seeing this on a client site using Fusion at the moment. When applying a filter to a View, the AJAX inserts all the same css again, except for grid layout and local.css stylesheets we add in template.php (which does not use drupal_add_css() and is therefore not aggregated). The result is that the duplicated css overrides our grid layout and local.css and destroys the layout of the page.
We're seeing this in the latest 6.x-1.6 and 6.x-1.x-dev versions.
Comment #4
sociotech commentedComment #5
merlinofchaos commentedI can think of two ways this can happen:
1) If you modify the list of CSS files after Drupal's normal processing
2) If you use @import
Comment #6
sociotech commentedThanks for the quick response!
Well, our (Fusion) template.php does alter Drupal css and use @import, but only in our IE 31 stylesheet fix theme setting, which isn't being used in this case. In this case it's disabled and we're not modifying Drupal css and we're only using link tags to add our extra stylesheets.
Also, it does the same thing in plain vanilla Garland (adds all the stylesheets again, unaggregated), but Garland doesn't have any non-aggregated stylesheets to be overridden, so it's not noticeable.
Also, this occurs whether the View is in a Panel or a page, and whether or not it is cached.
Anything else I should be looking for?
Comment #7
mstef commented[edit - not a ctools issue]
Comment #8
merlinofchaos commentedThey're not supposed to be reloaded; it's giving a whole list of CSS files that were added and the client is supposed to only add new ones.
When sociotech was debugging he noticed that new CSS files didn't have the query string, but in the code I can't see a reason why they might not.
Comment #9
merlinofchaos commentedOk, I was able to take a look at this thanks to mikestefff and CTools wasn't involved in this one at all, which explains a whole lot of confusion.
Comment #10
jcisio commentedThis recently has caused a problem with vote_up_down module #972386: Clicking widget causes module CSS files to be reloaded when CSS optimization is enabled. The module maintainer couldn't reproduce the issue, but many users could.
Any relation to this issue?
Comment #11
merlinofchaos commentedThere is no relation to this issue, because this issue turned out not to be CTools at all, as mentioned in #9.
Comment #12
mpaler commentedI'm still seeing this and I upgraded Vote Up Down to latest. So, what is involved in this? Can it be any thing outside the realm of improper ctools implementation in 3rd party modules? What should we be looking for to debug on this? Stumped... :(
Comment #13
mpaler commentedI'm wrong. The entire css set is being loaded again when aggregation is turned on. After reading the issue cue for 1 hr, now I'm confused...is this the expected behavior when doing ajax with ctools?
Comment #14
ayalon commentedI have fixed the problem this way. You can use this patch only, if CSS Aggregation is turned on.
Comment #15
merlinofchaos commentedTHIS issue turned out not to be CTools. Please stop hijacking it. File a new issue or find a more appropriate issue, but please stop destroying the history on this issue. Especially after I've already told you.
Comment #16
mpaler commentedMy apologies. No hijacking or cage rattling intended. In #9 above you mentioned:
and that suggests you & mikestefff have some insight on what was causing the observed behavior. I was simply asking if you could share that information.
Comment #17
merlinofchaos commentedOh sure. It was ajax_load module, which happened to be doing something very very similar to CTools and beacuse they knew CTools could do that they assumed it was. Only it wasn't; it was happening during an operation that wasn't using CTools' AJAX framework at all.
Comment #18
Dohama commentedI had just the same problem with duplicated temporary css files if CSS Optimization is enabled.
Turning off CSS Optimization fixes the problem, but causes the IE display the theme not correctly in fact of too many css files.
But I also recognized an error, that jQuery was not defined, because I was loading scripts at the bottom of template.
For me really fixed it, when I load the scripts in the header not in the bottom of the template, now I have no more duplicate temporary css files. So just have a look with firebug, if you have also an error with jQuery defined.