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.
 

Fatih Ozcan

Active member
By far most of our username requests are privacy related

@Chris D I am totally agree with @Alfa1 All my username change requests are privacy related. My users ate generally using their realnames as username. They don't want to show their username in search engines. Can you make any improvement about username and/or account privacy?

And I want to thank to all these usefull updates. And I like to see account suspend/delete feature also. İf registration is a choice, account delete should be choice as native.
 

Brad Padgett

Well-known member
Very exiting to see this updates. I really like the user profile banner idea. Another good idea is a featured thread widget. I posted that suggestion a while back and got quite a bit of likes on it. But I am definitely appreciating all the hard work you guys are putting through. Fantastic job.
 

STNN

Active member
What i am worried about is the impact on performance. I hope it's not too terrible.

Not interested in these changes. Looking forward to what's next in pipeline
 

Favori

Member
Great additions, looking forward to more.

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.

I'd prefer a separate option for the new users. In my forum most of the requests are from new users. They don't care the username at registration and they want to change it later. For example I'd prefer 7 days limit for the new users and 365 days limit for after first username change. That would be great for me.
 

Aivaras

Active member
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.

The introduction of markdown conversion would serve as a good example of a feature that needs to be turned off by default because it substantially interferes with some website configurations (see this post).

Adding features may also break custom styles. Having those features off by default may be less intrusive. Overall though, it must be judged case by case whether a new feature should be on or off by default. A reasonable criterion for such a judgment would be the degree of intrusion/disruption a new feature is likely to cause for XF websites already in operation.
 

Lawrence

Well-known member
What i am worried about is the impact on performance. I hope it's not too terrible.

For profile banners? There should be no impact. As stated by Chris in this thread, uploaded banners are resized to two different sizes, one for the profile page and a smaller one used elsewhere, like the tooltip when hovering over a username/avatar.
 

Chris D

XenForo developer
Staff member
The introduction of markdown conversion would serve as a good example of a feature that needs to be turned off by default because it substantially interferes with some website configurations (see this post).

Adding features may also break custom styles. Having those features off by default may be less intrusive. Overall though, it must be judged case by case whether a new feature should be on or off by default. A reasonable criterion for such a judgment would be the degree of intrusion/disruption a new feature is likely to cause for XF websites already in operation.
Indeed, and we reviewed the feedback surrounding Markdown and we did change the defaults eventually. It was changed between 2.1.0 and 2.1.1. Indeed we'll monitor feedback throughout the public beta stages and see what the consensus becomes.

In this case, we don't envisage this change to be intrusive in anywhere near the same way.
 

Xon

Well-known member
Kinda OT, but unless you've got a really large amount of conversations, the disk usage for conversations is negligible
One of my sites has nearly 5 million conversation messages, which is about 5.4gb in raw file size. Except I use ZFS, so that is actually 2.6gb compressed on disk. That is tiny (compared to the rest of the database)
 

Matthew S

Well-known member
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.

I know you have already made your peace with this, but I just wanted to express my surprise that you would consider upgrading 70 forums to a major software release with a single command. I'm presuming the features in this thread are small potatoes compared to what we'll see soon.
 

RallyFan

Active member
Some interesting new features and the security ones are good to see. Means the dev squad re taking current and future security breaches seriously.

Banners - I'll be disabling them as with various themes it's just asking for someone to do a black on black or white on white number. It's also an unnecessary distraction in my opinion.

Username changes - This might be a @Chris D one, but will they have the ability to link up with disallowed words and titles?
Currently using Siropu's Username Change addon and it allows for username changes to be reported into a specific thread which is a really nice feature. Makes staff aware that a user has changed names.

With regards to all the changes - Would it be possible to get a change log (on release) that mentions all the new permissions, and anything deprecated? I keep an Excel spreadsheet and Word Doc with all my config in it, so that if I ever have a major issue and need a ground up rebuild I can see what permissions/changes are made, etc.

Why did I build a new site before 2.2 was released, endless headaches incoming :X3:

Looks great, can't wait to play around :)
I'm literally days away from launching a brand spanking 2.1 forum after months of work lol. 😧
 

Mendalla

Well-known member
I'm literally days away from launching a brand spanking 2.1 forum after months of work lol. 😧

2.1 to 2.2 will likely be a fairly painless upgrade, not like 1.x to 2.x. I once jumped from 1.3 to 1.5 (forget what the third points were for those) without any major effort, just helping people get used to some new features. So go live on 2.1 and get a test environment ready so you can try out 2.2 when it comes.
 

RallyFan

Active member
2.1 to 2.2 will likely be a fairly painless upgrade, not like 1.x to 2.x. I once jumped from 1.3 to 1.5 (forget what the third points were for those) without any major effort, just helping people get used to some new features. So go live on 2.1 and get a test environment ready so you can try out 2.2 when it comes.
Thanks :) Yeah I've had experience with v1.3 and 2.1 ... huge differences :)
 

Serpius

Active member
One thing that kind of perplexes me about the title of this Forum category, 'Have you seen...?'

This is asking a question assuming that Xenforo already has released a new version with new features and/or fixes.

The question also assumes that he/she has already seen the new features/versions of that release.

It's an oxymoron to give this category a label that is self-contradictory.
 
Top