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:
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
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.
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.
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.
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.
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:
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:
This brings us nicely onto the final option which relates to what we consider to be a "recent" username change.
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:
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".
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:
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:
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:
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":
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:
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.
