Morrigan Posted December 17, 2020 Posted December 17, 2020 So this just is something I see come up a lot and it requires a manual post template edit in order to do it. It would be nice to simply have it added to the core template. Basically add the members group ID to their comment classes. This would allow for a lot of "per group" customization that isn't currently available by adding simple CSS edits. This would help things from per group highlighting to per group colors, per group borders, per group badge colors and more. I am asking because I frequently see requests for it and it would be far simpler to throw CSS at someone then CSS and a template edit.
CoffeeCake Posted December 17, 2020 Posted December 17, 2020 This is a great example of something that would be nice, but absolutely should be enabled by toggle on/off only, and then again at the group level. We have a use case where members are added to groups whose membership we would not want to disclose publicly (even if it would mean hidden in the class definitions of something somewhere). While this is not how others communities work, it is how ours works. I wouldn't want someone to suddenly be able to view source or inspect an element and see that a particular member has a certain class applied to their content that others do not without explicitly configuring that as an option for members of a particular group.
Morrigan Posted December 17, 2020 Author Posted December 17, 2020 (edited) This would be their primary group. So it would be the publicly displayed group. Secondary groups are normally hidden save for in searches. I don't support a toggle on/off. I mean people can figure out a users group even without this. It is already in the code provided. <----- Clients Let me know if you want me to get more technical. Edited December 17, 2020 by Morrigan
CoffeeCake Posted December 17, 2020 Posted December 17, 2020 We don't expose groups to search. Consider the following screenshot from my dev environment. Three distinct groups that appear as "Members" in the front end, yet have different permissions and settings associated: I don't think the group ID is presently exposed in the theme out of the box, but may be wrong on that. Yes, the name of the group is, yet the names do not need to be unique. Is it crazy that someone would do this? Maybe to you and I? Maybe to a community finding creative ways to handle challenges surrounding the provisioning of their membership the answer is no. It's helpful to consider how others may use the software in ways different than our own frame of reference, and I'm just wanting to add on a note that what sounds like a great idea for many (maybe even most!) may have unintended consequences for others. In general, I think it's a good idea to be mindful of that and to introduce new behaviors and features as opt-in, and off by default.
Morrigan Posted December 17, 2020 Author Posted December 17, 2020 If you don't allow your members to user member search, then no. This doesn't change the fact that overall adding in custom theming based on group is a pain in the butt as it stands right now. The only thing that you get to customize easily is the display of a users name which is fabulous for sites that, that's all they want. However you want to make other changes and whatnot (anywhere) and you're having to dig in. I can/have and do, do it, its not for me. Its for users like this: There are dozens of others as well asking similar questions even for changing the post highlighting on post or custom borders like what I do on my site.
Recommended Posts