Hi!
Today, I tried exporting a section from site 1(that has a few classes created to style the items in this section) and importing the section to site 2.
Unfortunately, I found there were no classes exported along as I don’t see any classes in the section imported.
Will this be available in the future?
Hi Jornes,
Yep, the topic is already on our ToDo list. Currently, only the key of the class is exported, which is pretty useless without a value (the styling). However, I strongly expect this to be possible in one of the following Bricks versions.
Best regards,
timmse
True. I really hope so.
I hope this to be done soon, then I can make some pre-made sections and share them with the community.
Hopefully this will be fixed with 1.4 
@Deanphillips It’ll be. I am currently working on it. Is not so much about fixing, but adding this as a new feature 
Already got it working locally. Here is the logic I’m currently using:
If the global class name used in the template already exists in the installation Bricks adds the suffix __imported to it. If not, the global class will be imported as it is.
Example: Your site contains a global class named .bg-primary and the template you import contains this global class too.
In that case Bricks renames the class to .bg-primary__imported.
Merging class definitions could lead to conflicts/unwanted side-effects. That’s why this solution seems to be the most flexible. You can always rename the imported class name later on.
Also, every global class has a unique identifier in the database. So if you export a template and import it later in the same installation, Bricks won’t import this class definition (as a global class with this identifier already exists). This ensures we don’t create any unwanted duplicate class definitions.
Understood! I knew when I wrote it, fix was a bad term to use 
As for what you suggested, I think that’s a great idea, but personally I think using numerical increments would be better.
This way .bg.primary would become .bg.primary__1 and then if I imported another template which has .bg.primary again it would become bg.primary__2 - it’s a lot more forgivable for multiple different templates from different sites being imported imo.
This avoids names like .bg-primary__imported and then if someone imported again it would become .bg-primary__imported__imported or something just as long 
@thomas To add to that, it might be a good idea to include a class merger, when/if you decide to do a style manager in the future.
For example, if we were using tailwind classes or utility classes in general and importing templates from elsewhere that all use the same framework, we’d actually want the classes to be the same within the html as they’ll be pulling from a stylesheet/CDN.
Otherwise we’d get width—l__imported (or __1) and this wouldn’t trigger the tailwind or automaticcss class and we’d have to go through the elements and delete and add the other class manually which would be a pain point.
I know it would be a challenge performance wise as it would likely require a scan process to search the html but it would solve problems like this and could just be a scanning/waiting process - I’d be happy to have a loading screen that takes a minute vs adding it all manually anyway
Or this could all be done on the import - “xyz class exist already. Use existing classes?”
Thanks so much for your feedback, Dean. Yeah, having a global class manager later on would definitely bring this feature to the next level. But step by step
As long as you import templates that originate from the same installation those classes will be imported only once. That’s what I tried to explain in my previous message with the “unique identifier” that is associated with any class. That ensures no unnecessary duplicates are imported.
About the __imported suffix: I actually started out with an auto-incrementing integer. It makes it somewhat difficult to reason about & edit the class name if you are using a class-naming convention that is similar and/or includes parts like __1, etc. Using something unique & straightforward like __imported should help identifying an imported class with the same name.
We’ll monitor & see after 1.4 what users think about it. We could always provide a PHP filter that allows you to define the class name prefix of your choice.
Hello
What is the actual status of the CSS Classes, are they exportet as well with correct names when exporting a page/section etc.? And after importing the page/section etc, are the CSS Classes importet correctly?
If not, I would rather use the Theme Child style.css in Appearance > Theme File Editor