Not a bug Prefix CSS

[beerForo]

Affected version

2.3

If you quick set a group of prefixes and set custom CSS, it does take effect, but it is not saved in the Other box when you go back to the prefix.

 

[Jeremy P]

I can't reproduce this. If I use quick-set to set a custom CSS class, it saves properly and is shown when editing the selected prefixes.

 

[beerForo]

My style will display properly but this field will be empty after the update. This is one of the fields right now:

But on the forum it is the correct style (color) that was set.

 

[beerForo]

@Jeremy P I figured it out. I was naming some prefixes names already assigned by XF. So if I made a custom green prefix and called it "green" (with my CSS in extra.less), the custom box would remain empty and the green prefix would be selected, but it would show my style on the frontend. So what I need to do is be more unique with naming them. I didn't catch this before.

 

[beerForo]

However that might still be a bug, and I think the custom box should be checked and say: label label--green, as this is confusing and also the wrong green shows in other areas of admin etc.

 

[frm]

However that might still be a bug, and I think the custom box should be checked and say: label label--green, as this is confusing and also the wrong green shows in other areas of admin etc.

But green isn't a custom label CSS as it's hard coded out of the box in core_labels.less.

Perhaps there could be a (?) FA icon next to Other that has a tooltip stating which label usage you shouldn't use as labels, from what I've seen some admins do, are added in extra.less so this could easily be overlooked.

Or, XenForo repackage their labels with more unique naming such as xfDefaultGreen so that this issue could never happen with someone creating a simple named label such as green.

Alternatively, it could error out if it's used in core_labels.less and also found in extra.less.

But I don't think the CSS should be showing in that box unless they reconfigure the entire UI to where when you select a built in label, it fills in the built in CSS that's not editable, with an "Other" label selection at the end that doesn't fill in the CSS and makes you put in yours. However, the issue could still persist if you add custom CSS with the same name.

 

[beerForo]

But green isn't a custom label CSS

I named prefixes green, orange, blue, etc. I was baffled how they disappeared from the custom box but the style still showed on the forum. Then I realized when I entered "label label--green" it actually was marking the green radio after it saved. This also explains why in other parts of the acp the green was the old green and not the custom. IMO this is a bug and it should be saved, or perhaps it should produce an error to let us know to rename it. I can easily call it newgreen and this is no an issue. But the behavior of it disappearing may baffle others as well.

 

[frm]

I named prefixes green, orange, blue, etc. I was baffled how they disappeared from the custom box but the style still showed on the forum. Then I realized when I entered "label label--green" it actually was marking the green radio after it saved. This also explains why in other parts of the acp the green was the old green and not the custom. IMO this is a bug and it should be saved, or perhaps it should produce an error to let us know to rename it. I can easily call it newgreen and this is no an issue. But the behavior of it disappearing may baffle others as well.

If I had to guess, the extra.less isn't rendered inside the ACP as you wouldn't generally style anything inside the ACP, and that could be the reason for the discrepancies. To edit styles inside the ACP, I'd imagine you'd have to edit core.less to include a new template ({{ include('your_custom_style.less') }}) or edit one of the core_*.less templates.

To test this, I added this to extra.less

    .p-title-value {
        font-size: 50px;
    }

This would've made the font size for pages (like admin.php?users/list) have a huge title for "Users", but it only affected my forum.

Edit: That has to be the case. Could you imagine the amount of bug complaints for messed up ACPs if they did include that template? Forums with a lot of customization would have really funky looking ACPs that might even make them unusable.

Edit as I misunderstood:

Then I realized when I entered "label label--green" it actually was marking the green radio after it saved.

That's probably because when you actually save the radio, it's saving "label label--green" on the backend. So if you enter a custom one as "label label--green", all it knows from the core templates is the old green, so it selects that radio on refresh after you save it.

 

[Jeremy P]

The predefined options just save the corresponding class name behind the scenes, so the system isn't able to discern if they were entered manually or not. Even if we did track this and displayed them as manually entered, selecting the predefined green option would still use your customized styling anyway so it's not liable to be any less confusing.

The appearance in the control panel is taken from the master (default) style. Consider that you may have two or more custom styles which are able (and even encouraged) to change the appearance of the predefined options in different ways. In this sense, what appears in the control panel is only a rough approximation of the hue (or primary/accent colors). Note that you can already hover the predefined options to see the corresponding class names.

 

[beerForo]

Sure, but if I enter label label--green in Custom and click save, don't you think it should stay there and not disappear, with the radio above being selected? This is the confusion. I had no idea one was named green and when it disappeared it looked like a bug. Until I saw the system moved it from Custom to the radio above (green).

 

[beerForo]

Solve: I'm going to rename them.

 

[Jeremy P]

I do appreciate it's a little confusing, but given this is the first time this has come up in 13 years I think it's easier to just explain why it happened than over-complicate the way we track and store the selected option. Both internally and externally, selecting a predefined class name or entering one manually will have the same end result anyway. The same class will be applied, and the appearance (customized or not) will be the same.

 

[beerForo]

I was using extra.less. Just discovered they are in core_labels.less so if I change my green there it is also that green in acp, doh!

 

[Jeremy P]

The control panel only ever uses the master style, so customizations may not be reflected there.

 

[beerForo]

Ah! Wishful thinking, yeah I tried it.