Global CSS classes - Ordering in cc-global-class.css instable and incorrect


Hey there,

I basically have a div with an Inner Block inside a component that, depending on one of four styles I choose, gets a class attached:

The class overrides a base value in another class that is set by default.

This is all working fine! :white_check_mark:

But the override of the base class values by the values of the class applied suddenly stopped working for one of the classes. I unfortunately can not tell what happened because I don’t know when exactly it stopped working while I was working on other parts of the page.

What I found out was what is going wrong. In the cc-global-class.css the class I apply is written before the default class. Since this order matters for CSS it takes the value from the last appearance of the property matching a selector for this element. Thus it takes the value from the default class and overrides the applied classes value.

I wondered if there is a way in cwicly to influence this order and it seemed to be possible in the Stylesheets tab. One can move the classes up and down and order them. But this order is not respected in the cc-global-class.css:

This leads to the default class overriding the applied class:

Regenerating all the HTML and CSS in the cwicly settings does not help. For my forthcoming this is really a critical issue.

Thx in advance

  • WordPress version: 6.4.2
  • Cwicly Plugin version:

Hello @jan,

Thanks for the report.

Indeed, the order should be respected, and is for me on the backend whenever I make modifications to the order.
However, I can confirm that it requires a save - refresh and save to have it apply on the final stylesheet.
I’ll investigate further and we should have a fix in the next update.
Regenerating the Global Class CSS does solve the issue on my end.

Would you mind quickly checking out if regenerating the Global Class CSS works on this installation:$2y$10$Bi0yJtAghMHkwUO7RS61b.J9F6B8VJ19A08T2GkY/LmRnETiXF9rK

You can see the order take effect on the default Hello World! post.

Thanks in advance!


Hi @Louis,

thanks for the quick reply. I looked into the sample page. When I open it it already has the right order in the file.
I also tried again to regenerate the CSS on my side and indeed, it works. Maybe I had some browser caching going on (no WP or Server caching is activated)?! Or I did something else additionally?! Wasn’t able to isolate the behaviour. Happy to see you were able to so quickly! :+1:

Okay, now after I regenerated it worked on the one component but I observe the problem in another part of the page?!

I played around with that in the test installation you sent.

What it looks like is, that the order of CREATION of the classes is taken into account. So, if I create a class .aaa then .ccc then .bbb then .ddd it will add them in this order to the file.
When I regenerate after reordering in the Stylesheet tab it is correct again. But after changing anything in the Paragraph (f.e. the text) it breaks again. This is what we observed and confirmed so far.

But it doesn’t only affect the Block in which you changed something, but all blocks and classes on the page.

I added a third paragraph and added the classes .d4, .a1, b2, .c3 by creating them in this order to it. Then, again, I reordered them in Stylsheet tab. And regenerating the css. Everything gets ordered correctly.

Than I change the text of the third paragraph and the order gets messed up again. But not only for the third paragraph, but also for the classes of the second paragraph.

@Louis, here comes the new aspect.
What I can not reproduce yet is how regenerating the CSS fixes one but messes up the other order?!
This is the result on my page AFTER regenerating the css (the opacity is the problem):

How to “fix” it? Reorder the class in the stylesheet tab and save. Even ordering it wrong (.hs-slide–active above .hs-slide) will work. This is due to the problem we already found. When changing something it will generate the file based on the order of creation of the classes. Since I created .hs-slide–active after .hs-slide it works.
What I don’t understand ist why the regeneration messes it up?! Again, the screenshot above is taken AFTER css regeneration.

I also don’t quiet understand why it is splitting the .hs-slide class into multiple antries and adding a .hs-slide::before?! The only css I added manually in the advanced > custom css is the vertical-align:top, which I would expect to be added to one single .hs-slide class entry alongside all the other properties set.

Hi @jan,

Thank you for bringing this to our attention!

This should now be fixed with 1.4 .

Kindly let me know if this is the case on your end.
Thank you in advance.

1 Like