I’m not sure what exactly is doing it but a(ny) CSS code I use to do this seems to turn on and off at random, I don’t know if it’s from an update, some setting, etc…
The one I’ve used for the longest is
.topic-post .Veeps a {
color: #66FF00;
}
With “Veeps” being my Custom Group. It was working as of either yesterday or the day prior but I noticed today all the colors except the ones linked to specific usernames are back to default, on every theme. I made a new theme and wiped all modifications to try and literally none work. It works perfectly fine with premade groups like “admin” “staff” moderator, but I can’t get any to trigger for custom groups. I’ve made sure it’s set to Primary Group, made it the only group they were apart of, tried on different custom groups (“Owner”), nothing. Now if I apply it to specific usernames it works fine, but it’s tedious to have to make 100 separate entries for individuals, that doesn’t update if their group changes.
span.username.staff a {
color: #00A9DB;
}
Works, but also not for Custom Groups. I know it WAS possible to make Custom Groups work because for years it’s worked for multiple (except when it doesn’t). Is there some better CSS to use, or some setting that I’m inadvertently messing with?
div.topic-post.group-Veeps div.names span.username a {
color: #8A2BE2;
}
To function how I won’t, but I haven’t installed this (or been using that CSS) for the last couple years so it doesn’t help me understand what exactly stopped working/what to fix, just hitting the nail in with the drill.
Yes, sorry for the inconvenience but the previous way we were adding the group class name was a little error prone… it meant that any group name that happens to match a class name in our CSS would cause layout issues.
For example, a group named “hidden” would add the class .hidden, which would hide usernames. Adding the group-- prefix avoids this issue, and this shouldn’t need to be changed again in the future. So you should just need to update .Veeps to .group--veeps
Thank you for letting me know, I feel slightly less stupid that I somehow broke something trying to fix something else as is often the case! I’ve played around with a few different cases and they all work fine and I’ve been able to work it out with this information.
Does it require the use of GitHub - discourse/discourse-groups-css-classes-in-body to still use custom Primary Groups in this fashion I was asking about, or is it unnecessary? I possibly misunderstood the purpose of that plugin in the first place and it was never required for what I was doing; I just removed it from my test theme to see if the custom primary group codes were still trigger, and they do, so it seems like it’s not needed…but I would rather be sure before I just turn it off and find something unexpected down the road.
I’m having the same problem too, I don’t know what’s wrong, impressive that even using the competent theme or the code, because the members’ names don’t change color, I even used the cogido and the component theme in a raw theme without any css or changes and it doesn’t change anything about the colors of the title
I just noticed something intriguing, if I put someone in the group as the owner, the change code works and the colors of the names of the members that I set as the owner are changed, but the members who are not the owners do not change