I am struggling with the issue that is described here in the CTools queue: http://drupal.org/node/830382
However, it's marked as wontfix there, so I suppose the problem is really with Vote Up/Down.
I use Drupal's built in CSS optimization, which neatly merges the ~40 CSS files used on my site into a single one. However, after updating from Vote Up/Down 1.x, it seems that I'll have to leave it disabled from now on.
When clicking a vote up down widget on a node, several CSS files belonging to installed modules are reloaded separately. These include:
modules/node/node.css?Q
modules/forum/forum.css?Q
sites/all/modules/cck/modules/fieldgroup/fieldgroup.css?Q
sites/all/modules/cck/theme/content-module.css?Q
sites/all/modules/ctools/css/ctools.css?Q
sites/all/modules/date/date.css?Q
...
I obtained this list through Firebug. It's not the complete list of course, but that's probably not relevant anyway.
The issue is in the fact that these default CSS files that come with the modules now override my custom styles from my theme, defined in the 'optimized' CSS file.
In other words, clicking the Vote Up/Down widget destroys the entire page layout.
I tried this with all 4 widget types that come with the module, as well as with my own custom widget. The result is the same in each case.
I'm not sure why it's reloading any CSS files at all - I'm sure there's a good reason for it, but it seems to be incompatible with Drupal's built-in CSS optimization.
With CSS optimization disabled, no strange behaviour occurs and everything works as expected. I suppose it's still reloading those files, but because they were already loaded before, the cascading order doesn't change.
I was hoping that there is a workaround for this problem. If there isn't, I will have to leave CSS optimization disabled from now on.
Comment | File | Size | Author |
---|---|---|---|
#29 | 0001-Issue-972386-by-merlinofchaos-marvil07-Fixed-Clickin.patch | 842 bytes | marvil07 |
#12 | vud_ctools.png | 47.93 KB | jcisio |
#11 | voteupdown.png | 200.67 KB | carlop |
#5 | no-extra-css-loaded.png | 89.98 KB | marvil07 |
Comments
Comment #1
benanne CreditAttribution: benanne commentedI have downgraded to version 1 in the meantime, as disabling CSS optimization made page loads several orders of magnitude slower.
Comment #2
birchy82 CreditAttribution: birchy82 commentedSame, breaks page layout. Also overrides theme_hues for the node.
Comment #3
tchilly CreditAttribution: tchilly commentedSame problem here, system.css is being reloaded messing things up.
Comment #4
carlop CreditAttribution: carlop commentedI have the same problem here. Disabling CSS optimization the problem disappear.
Comment #5
marvil07 CreditAttribution: marvil07 commentedSorry, I can not reproduce this behaviour with zen theme.
Firebug only reports me one POST request per click on the widget(see image).
Comment #6
benanne CreditAttribution: benanne commentedI am using a custom-made subtheme of Zen 1.1. I'll try to reproduce it with the bare Zen theme and report back.
Comment #7
carlop CreditAttribution: carlop commentedI use a custom-made theme but it's not based in any other theme. I have recorded a tiny video showing this issue http://www.youtube.com/watch?v=r9_M_8l7qjM i hope it can help
Comment #8
moosh101 CreditAttribution: moosh101 commentedSame here. When a vote is cast, my tab menu is replaced with the Drupal default tab menu. When I navigate away from the page, my own tab menu re-appears. This only seems to occur when a vote is cast, but not when viewing the node normally. As a result, I cannot use this module - shame :-(
Comment #9
marvil07 CreditAttribution: marvil07 commentedWell, it seems that this is not really related with vote up/down, since only happens on custom themes(see #5).
If someone can reproduce this on an isolated environment(only vote up/down and using garland or zen) please re-open it.
Comment #10
carlop CreditAttribution: carlop commentedI have a local copy of my website with the same issue. I have switched to garland and have installed only vote up/down (ctools too), and the issue still breaks the layout and load the extra css.
Comment #11
carlop CreditAttribution: carlop commentedI attach the firebug report
Comment #12
jcisio CreditAttribution: jcisio commentedI have this, too. Ctools AJAX response returns other things than the only "replace" command.
Comment #13
moosh101 CreditAttribution: moosh101 commentedSeems like its effecting quite a few people. Hope the developer takes a serious look into the issue despite being unable to reproduce it. It would be good to use this module, but with these current CSS bugs, I cannot.
I experienced the issue without CSS optimization turned on. Seems to be effecting both systems, those that use CSS optimization and those that do not. Lets hope we can get it fixed.
Comment #14
RobertOak CreditAttribution: RobertOak commentedI have the same issue here. This is with the Newsflash theme. It's easy to reproduce frankly and I've done a quick first pass of the code and am not seeing the bug, but this is MAJOR for it does slow the site down and change the layout. Instead of ajax speeding up the overall site experience, it causes a delay, while all css is loaded.
It's not just vud_node, it's also in the comments. Seems to occur on ajax_render, after vote is cast, changes the entire site layout and also slows the site due to the additional css load.
Comment #15
jthomasbailey CreditAttribution: jthomasbailey commentedsubscribing, I'm having the same problem with the Adaptive Theme Panels Everywhere
Comment #16
jcisio CreditAttribution: jcisio commentedSimilar issue in CTools #830382: Unwanted / duplicated temporary css files if CSS Optimization is enabled.. It turns out not to be CTools problem, but module problem. May get some ideas there.
Comment #17
naden CreditAttribution: naden commentedIn my case it only happens with google chrome, firefox, safari and ie are ok. I'm using the http://drupal.org/project/acquia_marina theme.
Comment #18
jcisio CreditAttribution: jcisio commentedI'm using Mac OS X 10.5, zen based theme, I have problem with Firefox, Opera, Chrome, Safari, with uid 1, normal user and anonymous user! I sometimes had this problem before, but now it always happens.
Comment #19
jthomasbailey CreditAttribution: jthomasbailey commentedExplorer won't work without CSS optimization (too many stylesheets, 33) so I think this is critical. Major at the minimum.
Comment #20
physiotek CreditAttribution: physiotek commentedsubscribing
Comment #21
marvil07 CreditAttribution: marvil07 commentedFinally I can reproduce the problem, but only if css core optimization is enabled, it is also generic(not-vud_node specific). I was also using an old ctools version on my sandbox at the time I tested this before, so maybe that could influence my test.
Well, not really sure where is the problem at my initial review, so patches are welcome.
Comment #22
marvil07 CreditAttribution: marvil07 commentedI opened a new issue at ctools with a patch: #989956: ctools_ajax_render() is loading css/js when core css/js optimization is active
Not really sure if that is the right solution, but it seems to be solving this problem.
Postponing this until a conclusion there.
Comment #23
carlop CreditAttribution: carlop commentedmarvil07 thank you very much for your hard work.
Comment #24
benanne CreditAttribution: benanne commentedmarvil07, you're a legend! Hopefully I'll be able to upgrade again soon :)
Comment #25
Ainur CreditAttribution: Ainur commentedmarvil07, doesn't helped me. Still got js and css file processing which slows down the voting significantly.
Comment #26
gibbet CreditAttribution: gibbet commentedAnyone have a fix/workaround for this yet? Other than disabling ajax or css aggregation?
Comment #27
marvil07 CreditAttribution: marvil07 commented@gibbet: see #989956: ctools_ajax_render() is loading css/js when core css/js optimization is active as commented in #22:
Comment #28
RobertOak CreditAttribution: RobertOak commentedJust applied your patch (#7, link: http://drupal.org/files/issues/0001-Only-process-css-js-files-when-prepr...)
to ctools-6.x-1.8 and it seems to be working great.
The patch lines might be off but I just went into vi and modified the code instead of applying the patch.
Good job, looks to work!
Comment #29
marvil07 CreditAttribution: marvil07 commentedAnd finally the mystery has been solved by merlinofchaos, the problem has been on the implementation :-p
Here the patch I will be committing.
Comment #30
marvil07 CreditAttribution: marvil07 commentedOk, committed to master, 6.x-3.x and 6.x-2.x.