XF 2.2 User profile banners, Username changes, Security locking accounts and more!

xenforo_profile_banners_3.png
Welcome to the first of our "Have you seen...?" (HYS) series for XenForo 2.2! To ensure you're kept up to date with future threads, we strongly recommend clicking the "Watch forum" link here and enabling email notifications if you haven't done so already 🙂

Over the course of the next few weeks we would like to not only introduce you to the new features we've been working hard on for the next version of XenForo, but also introduce you to some new members of the XenForo team! We'll introduce those new team members in the upcoming HYS threads.

But first...

New minimum requirements

You might remember that we started requiring PHP 5.6 starting with the release of XenForo 2.1. We base decisions like this on the "anonymous usage statistics" many of you kindly send to us periodically.

At the time we started the first HYS thread for XenForo 2.1 a whopping 44.7% of our customers were still using PHP 5.x. However, some time has passed and there has been a reasonable surge of usage in PHP 7.0 and above:

1590849917727.png

There is now only 14.4% of you running PHP 5.x (still too many!) and a whopping 86.6% of you are now comfortably enjoying PHP 7.x.

With this in mind, the time has finally come - we must leave behind PHP 5 and move onwards and upwards to PHP 7 and therefore XenForo 2.2 will require a minimum of PHP 7.0. But, don't worry, if you're worried that is too "bleeding-edge", just consider that PHP 7.0 was released nearly 5 years ago so, in actual fact, we'd strongly recommend you plan your upgrades to go as far as PHP 7.4 if you can.

But you don't care about that, right? What is actually new?!

User profile banners

xenforo_profile_banners_1.png

Ah the old, familiar user profile header. So... blue... so... familiar. This won't do. If a user wants to make their profile look at least 86.6% better than before, as long as they have permission, they just need to click the "Edit profile banner" button to be presented with an overlay which allows them to browse for and upload an image from their device.

After uploading the image is now displayed in the user profile header. Still so... blue... so... much fancier.

xenforo_profile_banners_2.png

Of course, there may be more interesting parts of the image to display, so you can change the focal point of the banner by clicking "Edit profile banner". All you need to do is click/touch and drag to reposition it to a different part of the image.

1590850014078.png


Still so blue... still so fancy...

xenforo_profile_banners_3.png

Of course it's only fair that we apply the same pizazz to the member tooltip too:

xenforo_profile_banners_4.png

From a forum admin's point of view there is, as mentioned earlier, a permission to control the ability to upload a profile banner or not:

1590850057466.png

And just like avatars, from the user edit page in your admin control panel you can view a user's current banner, delete it, or replace it with another.

1590850105092.png

And moderators who have permission to "Edit basic user profiles" can also view and delete the existing profile banner:

1590850120674.png

And that's it...! For this feature, at least... 👇

Username change management

While not particularly significant, we get around 50 requests per year from people wanting to change their username.

It's not a particularly arduous process but the user has to contact a staff member first, we then attempt to verify there aren't nefarious reasons for the request, then we check when they last changed their username as we don't like people changing their names too frequently, then we have to log in to the admin control panel to check the name isn't already in use before finally making the change, (sometimes) updating their custom user title and telling the customer that we've done it.

Wait... actually... that is arduous. So we made it simpler. And, while it is now simpler, there are quite a number of options to tune the system to your requirements.

First and foremost we've added a permission to control the ability to change your username. If you prefer not to allow users to change their own usernames then you can change this permission to "No" for the "Registered" group, otherwise you can keep it as "Yes" (its default) to enable the functionality.

xenforo_username_changes_0.png

Next, we've added an option so that you can control how frequently a user can change their usernames. By default we have set this to 30 days but it can be set to a much higher value, if desired, or set to a lower value or even 0 so users can change their usernames as frequently as they like. This is also the amount of time that needs to pass after a new user registers before they're able to change their username for the first time.

1590868350594.png

To change their username, a user simply needs to visit their Account details page and click the "Change" button that appears next to their current username. This will appear as long as they have the aforementioned permission and their last username change wasn't applied too recently.

The change username form looks how you might expect. We attempt to make it clear in this overlay that if there is a time limit on username changes then they will be prevented from changing the username again until that amount of time passes.

xenforo_username_changes_1.png

Once submitted the username is changed.

xenforo_username_changes_2.png

We also felt that it was important for there to be an approval process so that moderators or admins would be able to approve or reject username changes, if desired. This would allow some level of scrutiny of the name to make sure it isn't inappropriate or otherwise against your forum's rules.

Our solution for this is that username changes by default will go to the "Approval queue" before taking effect. It is made clear to the user that their username change is pending:

xenforo_username_changes_3.png

And moderators (who have the "Approve / reject username change" permission) will expect to find the username change amongst the approval queue:

xenforo_username_changes_4.png

The user will receive an alert / push notification once the change has been approved or rejected.

xenforo_username_changes_5.png


xenforo_username_changes_6.png

You may decide that having an approval process is unnecessary. In which case, you can allow users with permission to change their usernames without approval:

localhost_22x_admin.php_permissions_users_chris.1_.png

There is still quite a lot more to show you, including a couple more options. One such option allows you to control whether users are allowed to choose usernames that were recently in use by another user. It is disabled by default, but it is there if you need it:

localhost_22x_admin.php_options_groups_users_ (1).png

One of our use cases for XenForo community is that we often like username changes to be public. We currently do this manually, as I mentioned before, by changing the custom user title. Going forward username changes are logged and displayed publicly automatically via a menu that appears on the user's profile (and member tooltip):

xenforo_username_changes_7.png

In all cases we will show a maximum of five of the most recent username changes in this menu. The "See more" link will display if you are viewing your own profile, or if a moderator (with the "Bypass user privacy" permission) is viewing your profile. This enables the user to see all username changes:

xenforo_username_changes_8.png

This brings us nicely onto the final option which relates to what we consider to be a "recent" username change.

localhost_22x_admin.php_options_groups_users_ (4).png

By default the "Previous usernames" menu and overlay will only be available if a user has username changes within the last 30 days. The option allows you to set that to a higher amount or lower amount as required. Setting the value to 0 will disable displaying username changes publicly.

In some cases, a user may have a valid reason to change their username without it being displayed publicly. For example, they may be concerned about privacy so they would prefer the change to be kept private. The user would likely contact a member of staff privately to request the change. There is a new checkbox that appears below the username field when an admin is editing a user:

xenforo_username_changes_9.png

Username changes done in this fashion are not displayed publicly, but will still display in the "Previous usernames" menu and overlay for the aforementioned moderators with the bypass privacy permission and the user themselves.

Note that while editing a user we also display the date of their last username change, and the date of their next allowed username change.

While username changes have traditionally (and will continue to be) logged in the "User change log", this new username change feature actually maintains its own dedicated log called the "Username change log".

xenforo_username_changes_10.png

The toggle you see here allows you to set whether a particular username change is displayed publicly or not.

When you upgrade to XF 2.2 we will attempt to populate this log with existing values from the user change log.

In some cases there will only be a limited amount of data populated as we haven't always kept username change logs in the main user change log indefinitely. Username changes that we import from the user change log will not be displayed publicly.

Speaking of usernames, we do have another small feature that is relevant to both users registering and username changes.

Username validation and generic input validation

While this feature is very small and currently only used to validate username input, for developers it provides a small framework to provide generic input validation in other places. But we'll mostly focus on its application to username validation, for now.

Quite simply when a user is registering or attempting to change their username, we verify what they have written so far is a valid username and display an appropriate error. The following video should demonstrate how it works:


For developers, the implementation is as simple as adding a validation-url attribute to the input. That URL is responsible for performing the logic required to validate the username (running it through the username validator in this case) and returning some JSON params to indicate if there are errors and what the errors specifically are.

Speaking of developers, we will have a special HYS thread for you to get your teeth into at some point in the next few weeks so keep watching!

Security locking user accounts

There are a few situations where you might wish to protect a user's account. You might suspect unauthorized access on a specific account or have a general concern that some breach has occurred.

We attempt to cater for both of these situations by allowing you to "Security lock" user accounts. Primarily this is done when editing a user in the admin control panel:

localhost_22x_admin.php_users_chris_d.2_edit (1).png


security_lock.png

We'll outline in more detail the behaviour of each option below.

User must change password

If you suspect a more general breach and you want a user to change their password when they next log in to their account then this is the option to choose.

A user who has their account locked by this method will be met with the following screen when they use this account:

localhost_22x_account_security__xfRedirect=http%3A%2F%2Flocalhost%2F22x%2Fmembers%2F.png

After confirming their existing password and entering a new password, the user is redirected to the URL they tried to access originally.

User must reset password

If you suspect a more targeted attack against a specific user, or you detect unauthorized access to a specific account then requiring a password reset is a better approach.

The difference with this approach is that a password reset email is sent to the user's registered email address. In other words, the user has to demonstrate they have access to the email address on their account before being able to change their password and log in.

A user who has their account locked by this method will be met with the following screen when they use this account:

localhost_22x_members_.png

Shortly afterwards, an email should arrive to the email address on their account which will look like the following:

xenforo_security_lock_1.png

The "Reset password" button will take them to a form where they will be able to choose a new password:

xenforo_security_lock_2.png

And in this particular case it must be a new password. We prevent the user from picking the same password they already have.

localhost_22x_security-lock_2_reset_c=kgtY9rZKNi8y67aN (1).png

Again, once the password has been changed, the user can continue to use the site as normal.

But, what if you have concerns about multiple users...? 👇

New "Batch update users" actions

Due to the nature of some security breaches, you may wish to security lock most, or even all, user accounts on your forum. To enable you to do that we added the ability to set the security lock via "Batch update users":

localhost_22x_admin.php_users_batch-update_confirm.png

As well as setting either of the security lock types in this way, you can also remove existing security locks too via the same action by setting it to "None".

Note that to prevent awkward situations, security locking administrator accounts in this way isn't possible.


While not related to security locking, we have also added the ability to set user states via "Batch update users" too:

localhost_22x_admin.php_users_batch-update_confirm (1).png



And as the well-known saying goes: "All good 'Have you seen...?' threads must come to an end" but, don't worry, we'll be back later this week to introduce you to a new face and more new features.
 

JoyFreak

Well-known member
Kinda OT, but unless you've got a really large amount of conversations, the disk usage for conversations is negligible

Personally, I would never want to prune conversations - you never know if they contain valuable information for your members - even if they are many years old.

I just did a quick checkup and even on our largest forum, the total amount of disk usage for conversation related tables is < 1 GB, eg. nothing.


IIRC this is a private Add-on that can't be purchased by everybody, right?


Ack. This shoud be off by default for upgrades to keep compatibility with existing behaviour but can of course be enable for new installs.

@Bob add-on’s aren’t exactly private. You can easily visit his website here and access some of his add-ons. There are some add-ons that are missing there but all you’ll need to do is PM him privately and ask nicely :)
 

Kirby

Well-known member
@Chris D
I totally understand your toughts (and a bit of frustration? ;)) on username change defaults.
Of course you want and need to showncase new features and you are absolutely right that many customers might not notice such new features (that they would want to use) if they are not enabled by default.

My company operates about 70 forums on different platfoms (currently XenForo, WoltLab, vBulletin and phpBB) - only one (!) of them has an Add-on installed that allows users to change their username.
We've had such features enabled on more forms, but they tneded to get abused (even with limits in place) and this actually caused more harm than good for our community managers.

Therefore, I am almost certain that for the vast majority of our forums, the community managers would not want to have that feature enabled.
Right now I can perform a XF2 upgrade on all of our forums by firing a single command - if I afterwards have to manually change settings/permissions on a lot of forums this becomes a really time consuming and probably error prone task.
In fact we did this for reactions and they are actually disable (except like) on many forums, but if they are not it is not as bad as having users abusing name changes and cuasing a lot of confusion.

How about having a single step in the upgrader that just asks for the defaults for all new features?
This way you can still set defaults as you like, admins would be immediately aware of them and could change them from one convenient location, for CLI you could add an option to specify a presets file (JSON).

That IMHO could make everybody happy :)
 

ALMUSA

Well-known member
If people are absolutely emphatic that it must not be enabled by default, we can consider that, but the people asking us to do that are the kinds of people who are already comfortable with tweaking options and permissions ad-infinitum whereas the people we don't hear from otherwise may never know the feature exists, and there would be a disparity between a new install to 2.2 and a new upgrade to 2.2 in expected features, so therefore we should maybe just switch it off for everyone even on new installs to cater for the experienced amongst you preferring not to have to disable it manually...?

I do not think it is a major issue, certainly admins can take a minute or two to sort out their broads permissions accordingly. Small details like this should not be seen as a stumbling block if you ask me. While I do respect those who prefer "disable by default" I would put my focus now on putting the new version together and have it released as soon as possible. XF, we can not have enough of you. :love:

All I can say is hats off to XF developer team.
 

Bryan

Active member
We'd rather have upgrade permissions reflect the defaults of a new install where possible. So if a feature is on by default for a new install, it should be on by default when that feature is added via an upgrade.

As with everything, if you're unhappy with the defaults then you can just change the values.

This is generally how the majority of new features have worked over many releases.

This is like saying that when reactions are added, we shouldn't add anything except "Like" because you want to keep the existing behaviour. Or we shouldn't have enabled and exposed bookmarks by default because you want the existing behaviour, plus many more examples.

If people are absolutely emphatic that it must not be enabled by default, we can consider that, but the people asking us to do that are the kinds of people who are already comfortable with tweaking options and permissions ad-infinitum whereas the people we don't hear from otherwise may never know the feature exists, and there would be a disparity between a new install to 2.2 and a new upgrade to 2.2 in expected features, so therefore we should maybe just switch it off for everyone even on new installs to cater for the experienced amongst you preferring not to have to disable it manually...?

I'm not sure if I'm missing a significant situation where it is risky or undesirable or dangerous to have it enabled by default that can't be solved by just turning it off if that is your preference.

How about a section on first visiting the admin panel after an update that introduces you to the new options and asks you to select your defaults. Seems like a reasonable compromise.
 

JoyFreak

Well-known member
How about a section on first visiting the admin panel after an update that introduces you to the new options and asks you to select your defaults. Seems like a reasonable compromise.
New options are normally introduced via HYS, all they’ll need to do is skim through the threads and update the permissions if need be. You will have those who want it, some people who don’t and some people who don’t care. I personally prefer it the way it is now. Why fix what’s not broken?
 

Mike

XenForo developer
Staff member
In fact we did this for reactions and they are actually disable (except like) on many forums, but if they are not it is not as bad as having users abusing name changes and cuasing a lot of confusion.
Just to clarify that the defaults lead to approval rather than a direct name change. So unless those are approved, it shouldn't directly lead to a lot of confusion. If it's not desired when the requests come in, they can be rejected and things can be adjusted in the control panel.

This was one of the things that we considered when debating defaults (and we did debate them). If it wasn't subject to approval then the result likely would've been different.

As @Chris D mentioned, we do consider opinions, though of course it's important to understand that if there are people shouting one thing and we change that, we usually get the people we didn't hear from shouting that we changed it. So there are absolutely two sides to the coin.
 

Kirby

Well-known member
Just to clarify that the defaults lead to approval rather than a direct name change. So unless those are approved, it shouldn't directly lead to a lot of confusion. If it's not desired when the requests come in, they can be rejected and things can be adjusted in the control panel.
Sure. But having such features available created demand by users and they'll most likely start to moan if we turn if off later.
So for u, in man cases it would be better not have that avialable tight from the beginning.

As @Chris D mentioned, we do consider opinions, though of course it's important to understand that if there are people shouting one thing and we change that, we usually get the people we didn't hear from shouting that we changed it. So there are absolutely two sides to the coin.
Yes, absolutely - that's why I suggested to have a setup step for default confirmation as a compromise.

Anyway, it's not the end of the world if the default is on or off, we can always change it - it's just that I'd prefer it to be off.
 

ShikiSuen

Well-known member
I'm sorry to be a rain on your parade, but how User profile banners & Username changes are step forward?
It's step 20 years backward to Myspace times. I use IPB for my other forum for like 5 years. It already had these features when I bought it. Who cares about these things?! 50 requests a year to change a username? Big deal. Thousands requests a day for pages, that get back bunch of unused css, js, fa icons... That's what important. The speed of content delivery that is what important for forum visitors. Not a background of a user profile, that they will most likely never visit.

Why do you spend time creating features, that IPB had for years and it didn't let them take away leadership from xF? Create features, that Wordpress has, those that let them leave xF waaay behind.

Comrade, you can always completely disable user profile banners in the theme template.
Rest assured I will deliberately make it unavailable in my themes for XF 2.2 releases, unless better idea comes out.
 

btmgreg

Active member
Imagine the newfound possibilities with the cover feature. Facebook (I hate to compare) debuted video covers a few years back. It would be interesting to see what the developer community can come up with now this feature will be in the hands of everyone.
 

ShikiSuen

Well-known member
There is no need to disable user profile banners via editing templates.

As described in the first post, anyone who wishes to disable the feature can just set the permission to "No".
@Chris D
I know your good intention of introducing this function.
Here are my two dollars which may be helpful to you or not:
Compute the dominant color HSL from user avatar, and force this HSL to the user profile banner background (in lieu of a static image) with a little dynamic tweak of the light value of HSL.
 
Last edited:
Top