XF 1.2 User Group/Staff Banners

In XenForo 1.1, if you want to customize the display of certain users, you're generally limited to user titles and user name styling. However, sometimes this isn't flexible or clear enough. Sometimes you want to be able to draw attention to multiple things for a single user.

Enter user group banners:

ss-2013-05-29_14-57-28.webp


Banners can be configured per user group:

ss-2013-05-29_14-58-30.webp


(I am aware of the first banner on the second column having its top border wrapped back. This is a browser issue that we're looking into.)

You'll note that this set up is similar to how thread prefixes are configured. You can use custom CSS classes to completely change the display of banners (such as by replacing them with images).

I've demonstrated that you can have more than one banner displaying simultaneously. By default, they'll be displayed in the display style group order (highest first). If the user is a staff member, that banner will take priority.

You can disable this option and configure a few different options (globally):

ss-2013-05-29_15-01-15.webp

You'll also note that you have the option to override standard user titles with banners.

These banners are primarily displayed on messages, but they're also shown on profiles. There is a simple template helper function that can be used to display them anywhere.
 
I guess one userrank add-on less. I like it that you can style them like prefixes. Consistency ftw
All that's left are Thread Tags ;)
 
About this it pops a question, can many users with ~7,8 groups cause performance issues, since all groups do have their permissions? Does it needs to check permissions in all groups every page it loads?
 
XenForo would not implement anything that would introduce performance issues.

Most if not all of the data to ascertain a user's group etc. is already fetched in every single post.
 
(I am aware of the first banner on the second column having its top border wrapped back. This is a browser issue that we're looking into.)
For Chrome, removing the column-break-inside: avoid from the li element actually seems to fix this problem, which is weird since I figured it was supposed to help avoid this kind of issue. Not sure how that affects the majority of other browsers though.

These banners are something I've seen a lot on other XF forums and I've always thought they made the message user block a bit more appealing. For almost 2 years I've been meaning to add them, but never got around to it, so this works out well for me. :D
 
XenForo would not implement anything that would introduce performance issues.
Most if not all of the data to ascertain a user's group etc. is already fetched in every single post.

But far I tested in the community test forum where i am admin, if i change to deny permission in acp and simply update the page, it will deny me the page, what makes me think the forum is running queries to check permissions every single page, with 8 groups isn't that 8x more queries?
(asking this because i will buy license for start my own forum soon)
 
Primarily Administrators and Moderators, but in 1.2 additional user groups can be set as staff.
I just want to clarify this as I said it elsewhere: groups have nothing to do with people being staff. People are individually tagged as staff or not. (This is why you can have hidden staff in 1.2.) Moderators and admins are normally defined as staff though.
 
This is great. I will use it for VIP membership banners.

Not sure if I'll use it for staff. I like people not knowing who staff are so they can figure it out themselves.
 
But far I tested in the community test forum where i am admin, if i change to deny permission in acp and simply update the page, it will deny me the page, what makes me think the forum is running queries to check permissions every single page, with 8 groups isn't that 8x more queries?
(asking this because i will buy license for start my own forum soon)

Just trust me when I say this:

Either the data will be already available (every post is joined to the user table to fetch the user data) or it will be pulled from a cache, or it will pull the data necessary in a single query. Mike would not introduce a feature that doesn't scale well to 8, 80 or even 800 groups.
 
Just trust me when I say this:

Either the data will be already available (every post is joined to the user table to fetch the user data) or it will be pulled from a cache, or it will pull the data necessary in a single query. Mike would not introduce a feature that doesn't scale well to 8, 80 or even 800 groups.

I'm catching the tail end of this convo but felt compelled to jump in and ask. What about 8 billion groups + lens flare + psp tubing. How would that scale? :D
 
Just trust me when I say this:
Either the data will be already available (every post is joined to the user table to fetch the user data) or it will be pulled from a cache, or it will pull the data necessary in a single query. Mike would not introduce a feature that doesn't scale well to 8, 80 or even 800 groups.
That is good to hear. :)
I'm catching the tail end of this convo but felt compelled to jump in and ask. What about 8 billion groups + lens flare + psp tubing. How would that scale? :D

Do you need a group for every single Human? I'm in. (y)
 
Top Bottom