Global Classes removed when exporting/importing reusable blocks

From old feedback: Global Classes removed when exporting/importing reusable blocks | Cwicly

Exporting and then importing reusable blocks as JSON files is currently the most straightforward way to share blocks between sites.

Unfortunately, global classes are removed on import. Screenshot attached.

It does not happen if the class is applied in the “Additional Classes” input.

It’s possible the solution to this might tie into the request here:…

Attached images

Hi there Orrett,

Indeed, the global class will be removed if importing the block on a new/different installation since the Global Classes are not imported.

The Removed indicator simply means Cwicly cannot find the global class, but the reference to the global class is not lost.

An import/export option for global classes is indeed necessary and in the works.

The same will happen with Additional Classes if the specified one attached to its block is present on another page/post and hasn’t been imported into the new installation.

Makes sense, I hope you’re able to figure this out.

If I may, and without being too presumptive, I think there needs to be a review about how classes will be handled in Cwicly.

To give an idea of my workflow, I have a customized framework I use on all my sites, that heavily uses variables for fonts and spacing. These are declared in a separate stylesheets, so I’m very happy we can easily add/edit custom stylesheets in Cwicly.

While I do create global classes and style them in Cwicly, I often simply type in my framework classes to pull in the styling that is contained in the stylesheet. These styles were the ones being removed when I exported. My workaround is that I add classes from my stylesheets only to the “Additional Classes” box. I never need to edit them in Cwicly, of course, but I also don’t lose them if I export to a different site.

So, my hope is that we can better integrate Global Classes and custom stylesheets so it’s a really seamless experience. I don’t know how this might function, but at the moment, it’s just a little thing I have had to find a workaround.

Hi there @owynter,

The way you are currently proceeding is the correct one, that is:

  • Creating Global Classes for classes that you will style using Cwicly if needed globally (not block related)
  • Adding your custom stylesheets classes to the Additional Classes selector since they are not Global (and thus not referenced by Cwicly).

This is how working with classes with Cwicly was intended from the start.

The Global Class property in Cwicly is to be reserved to classes you create globally and works very much like our block classes, which allow you to rename them and have that rename applied throughout your installation without requiring you to review every instance the class appears in.

The same goes for the Additional Classes, which as their name imply are additions to the main block class.
This explains why when you export your blocks, the Additional Classes that were manually added (without reference) do not get removed.

Thank you so much for the clarification, Louis.
It makes sense, and I have just fallen into this method intuitively.
This is possibly a topic for greater elaboration to help other users who might also misunderstand.

1 Like

Indeed, you are absolutely correct! We’ll do our best to make things clearer in our docs (which are going through a re-work).
Thanks for bringing it up!