Class Manager reports conflict but search does not confirm conflict

How To
1

Hello Bricks Community,

I tried to load a second instance of a template from the Frames library on the same page.

When I loaded the first instance of the same template I renamed the classes and deleted the old ones.

However, the Bricks class manager shows the conflict message for a class but, as the screencast shows, the search performed in the class manager does not show the existence of the class cited in conflict.

So, the conflict exists?

I am using the latest stable version of Bricks and WP

Bye

2

Hi @Drugo,

the class name is different, but the internal ID (of the class, that we use), is still the same as the one as in the template. So, that’s why there is a conflict.

If you don’t import the new class, your Frames template should have the correct one applied - the one that you changed.

Can you test and let me know.
Thanks.
Matej

3

Matej, thank you for your response.

Certainly my inexperience is to blame, but I didn’t completely understand your answer. I will try to rephrase the question.

If I understood at the classes manager error message correctly, thanks also to your answer, the .fr-hero class assigned to the model to be imported has an ID equal to UD registered in Bricks.

So, if I locate the element (I think the appropriate term is “the selector” in Bricks that uses the subject ID, I could rename the ID and eliminate the conflict. Have I summarized the problem?

Maybe I am asking a stupid question but I am really clueless in this area so how can I locate the element/selector to eliminate the conflict.

Best

4

Hi,

there are no stupid questions. :wink: Sorry that I was unclear.

Let’s say that you import a template, with a .my-class. This my class, has internally some ID, in our example, let’s say that this ID/identification is abcdef.
So, whenever you use .my-class in your layout, internally, we reference it by abcdef id, that you don’t see.

To simplify, internally, the class is stored like

{
    name: ".my-class",
    id: "abcdef"
}

Next thing, you rename the class, so instead of .my-class it is now called .my-new-class. As so, internally, it will look like below. Note, that the ID is still the same.

{
    name: ".my-new-class",
    id: "abcdef"
}

Next, you import the template with the .my-class again. And it is the exact same template as before, so the .my-class from template has the abcdef id as well.

When importing, we match them by id, and then we compare the name and values. If it’s different, then we show a notice, and you have few choices:

  1. You can override the internal class: All changes that you made locally will be overriden. You probably don’t want that.
  2. You can skip the import or decline the imported class. This way, it would not import the new class and it would keep your local changes, but it would still apply your local class to the element. I guess this is what you want.

It’s best to try on a staging or somewhere, and you will see how it works. So to answer:

…you don’t. The class you renamed is the one that is conflicting. But it’s not an error per se, just a choice between overriding it or discarding/skipping it. :slight_smile:

I hope it’s understandable, otherwise let me know :wink:

Matej

5

Next thing, you rename the class, so instead of .my-class it is now called .my-new-class. As so, internally, it will look like below. Note, that the ID is still the same.

Thank you for your willingness to explain. I am left with only one doubt.

So, since my amateur workflow needs to load two instances of the same model, the first one is the one to which I apply the custom styles, the other one I need when I get lost on the way and the result obtained does not match the expectations, in that case it is useful for me to go back to look at the defaults.

In tis context the classes and deleting the old ones (the defaults) is not enough to avoid conflicts since the ID will remain the same in the two instances. Is that correct?

I admit that I have been fighting with class conflict for a while, I thought I had imaparated the correct workflow however, in the conflict cases that happened before, a conflict at the ID level never happened, as in this case.

Any suggestions are greatly appreciated.

Many thanks

6

Hey @Drugo,

In this case, you can override the classes, but keep in mind that your changes will be reverted to the original. So maybe this is not exactly what you would like.

My second idea is that you use second bricks installation, and check classes there :slight_smile:

Best regards,
Matej