not able to find that within the editor …“The class name for the selected block should always be unique. If you want to use additional classes, you can do so via the Additional Classes field”
Hi @FZwo,
Sorry for the confusion. Additional classes are now referred to as Virtual classes and can be found alongside the Global class field.
Thank you for pointing out the inconsistency in our docs, we’ll be sure to update them as soon as possible!
no problem, did not know that custom classes are named “virtual classes” with in your editor
Hi,
I think there is a confusion here between virtual and global classes.
If you need additional classes, you have both solutions:
- either global (custom, framework, utility, etc.)
- either virtual (generated by Cwicly for other blocks that you want to mimic without creating global classes)
That’s what I understood, at least!
But virtual classes only work within the page. That said, it doesn’t work for a different page.
For example, I have a well-styled block without using a global class on the home page, and then I want to use the virtual class on another page is not possible(it couldn’t be searched). I hope the virtual class is available entire site because I am lazy to think of the class names sometimes.
I wonder how could virtual classes work across pages…
It would mean that all blocks classes from every page/post/template are stored somewhere with the associated CSS, accessible from everywhere.
Might be overrated for me, and that’s the purpose of global classes, or template parts or fragments, isn’t it?
Yes. I wonder if it’s possible.
Yes. I have this thought just because I’m lazy to name the global classes when designing my website sometimes 
. So, for example, I take the virtual-class as the global styling(without the need to create global classes) but able to use it globally.
In case they are 3rd party, they would be virtual classes, not global ones.
Just in case you didn’t know.
Indeed, I’ve just tested an import…
It doesn’t make sense to me, very unintuitive.
External classes should definitely be accessible as global and not virtual.
No, as global classes are controlled exclusively through the block inspector.
Anything else would be a virtual class thing.
Might be some general confusion on your side.
Could you elaborate here as well?
Might just confirm my feeling that there is some lack in the general understanding of the system.
Well, page X doesn’t know what is on page Y, not the same DOM and stylesheets, so it cannot provide with blocks classes from page Y.
Unless everything is stored somewhere globally accessible, which would be awesome but somewhat complex to retrieve, I guess.
As for the external classes, yes I’m very confused.
They have nothing to do with the actual virtual classes (classes that are not created or imported but classes that are already generated by Cwicly and correspond to other existing blocks).
The only thing they have in common is that they cannot be edited, maybe that’s why they are in the virtual dropdown?
Block classes are stored per page/post/template/etc. basis.
They are not global.
Virtual classes are only references of already existing or even not existing classes.
Virtual classes, as mentioned, can be anything, except global and block classes.
Block classes and global classes both serve one specific purpose, while virtual classes can be used in a dozen of scenarios. External classes is only one of them.
1 Like
OK I get it, so I guess I dont’ like the “virtual” semantics 
External classes don’t sound “virtual” to me, since they really exist, with name and CSS. They are just defined elsewhere.
On the contrary, virtual classes have not been created per say, but they reference a block.
Even if the result is pretty similar 
Another issue I have is that I need to select the right dropdown to find my classes, so I need to remember if the class I’m looking for is external (virtual) or global.
With other builders, you just start typing and suggestions show all classes (because external are the same as global).
Well, they are virtual, as they are not available/accessible through the designer to apply your styles.
They might exist, but on another layer.
You treat them differently.
Previously, they were named additional classes which confused also a lot of people.
Yes, it’s kind of important how they are named to get a basic understanding or a good first idea of their purpose.
But there is no universal solution to make it perfect sense to everyone.
Once there is a basic understanding, it doesn’t matter how they are named.
Well, I’m pretty sure you will get used to it as well.
You even have the possibility to manage them (global and external classes) separately, which is a huge advantage imo.
Throwing everything together isn’t something what I’d like to see.
Especially, as already mentioned, they have different abilities and purposes.
It wouldn’t even be possible to combine them without creating a horrible experience.
1 Like
Well I guess it’s a matter of habits. We work like this with Oxygen and Bricks and there’s nothing horrible
On the contrary, only one dropdown is much easier.
And you can lock the classes you want if you don’t want them editable.
But I agree that having external classes automatically not editable (or locked) is also a good point.
The best solution I can imagine is unifying the 2 dropdowns and automatically locking all external classes.
1 Like
Yes, I 100% agree with this.
Cwicly is working differently. So you can’t compare it.
Mixing global and external classes together would result in chaos.
Just give yourself some time, explore the tool and you’ll discover that everything makes perfect sense.
External classes are only a minor part of virtual classes, so it wouldn’t make sense at all.
Virtual classes, as soon as understanding what they are able to do, is something you don’t want to miss anymore.
The only thing a virtual class does is to get printed inside the HTML of the corresponding block.
If there is a reference, it will, for example, pick up a styling. Otherwise it just doesn’t do anything.
It is not added to the stylesheet, as they are only virtual.
Things do not necessarily make sense just because everyone else do it the same way.
I’ve understood what is a virtual class and how it is powerful.
Well, external classes are not virtual, see the doc. Virtual are the classes generated for blocks which you want to reuse style. That’s all. Or maybe there are other uses not described here?
The confusion for me comes from the fact that external classes appear in virtual dropdown, whereas they don’t come from blocks.
And I mispoke with unifying dropdowns, I meant unify global and external classes, and keep virtual separated.
(I don’t see why it would be chaos, I’ve been working for years like this, it is OK.)
Another advantage would be to not polluting external/global dropdown with all virtual classes coming from blocks if we don’t want to search them.
Maybe @Louis has an opinion about this?
For me virtual is a reference to blocks, which makes sense, and are linked to the corresponding blocks.
And all others (external , global) are associated to custom/external CSS, and are independant from any blocks.
Just want to leave this here:
My final recommendation:
Spend time and learn Cwicly.
Not talking about a couple of hours.
Read the forum, watch the YouTube videos.
Forget what you know about other builders.
It will prevent you to discover the full power of Cwicly.
It’s not a builder to learn.
It’s the concept which you need to understand.
While it’s not something completely different, some general approaches are.
In case you see in Cwicly just another builder, then yes. I can follow your thoughts completely.
PS:
I totally get your point regarding unifying global and external classes.
The issue I see here, they work differently inside the builder (while technically they are the same on front-end), so it wouldn’t make much sense to have them in the same dropdown.
In my opinion, it would confuse more than it would improve.
But when people find, it makes much more sense to them…
Maybe this can be made available as an option?
Why not checking out what other users think by creating a feedback thread?
In my opinion, there is too much logic behind it and too many possible scenarios, which will lead into issues.
Everything makes perfect sense as it currently is, but wouldn’t vote against anything, as long it’s optional.
Another drawback I can imagine is with a lot of external classes, when I search a block class in the virtual dropdown, I see all my framework classes and have to scroll until I find the one.
So I made a test, importing a CSS stylesheet, and now this is what I call horrible:
Real virtual (!) classes are lost among all external classes (false virtual) in the virtual dropdown, and the “- EXT” suffix ruins lisibility.
Sorry but I think this is not the right way to do this.
You can’t mix virtual and external, they are definitively different beasts.
It might fit when you have very few external classes, but not in the general case.
To go a bit further, as much as I love the concept of virtual class, it is not good practice to have a class named “heading-c72fcaf”, since you can’t tell its purpose by its name.
So you need to rename the class to a meaningful name.
So why not just create a global class and move the block style to the new class instead?
(With a direct button like “add global class with block style and remove block class”.)
I admit it would add a bit of bloat, since it seems that a virtual class is local to the post/page/template and global are… global, but it would be healthier for me.
Or… Keep the mechanism, but call these classes “local” instead of “virtual” And keep them separated from external, of course.
But this would add a third dropdown, which is not a good thing either…
Well, this is a real puzzle, I like it 
I guess I’ll have more ideas when I actually start a site with Cwicly, which could be in the next days.