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.
 
I’m sensing we’re potentially at risk of taking the focus of the discussion away from what was announced and getting into a fairly pointless debate about different software.

I have a question about announced "User profile banners" feature.
Desktop user ads a 2000x300px banner that is 1.5Mb. He is on a cable so he doesn't see a difference in page load speed.
Now mobile visitors (more than 50% these days, and growing) will notice that a page loads almost twice longer.
So will xF 2.2 have such things like srcset/sizes/<picture> & webP support ? Otherwise this feature is not just useless but harmful.
 
Where's the giphy support? Does anyone care about user banners?
This update leaves me feeling just whelmed
Me too, these are changes that I imagine my users really won't care two hoots about I've only had one name change request and nobody really cares about the background of their profile, however I'm happy for those who do find these features to be great - it's also great that developers do take note of some of the suggestion threads.

But then come to think of it, my members probably wouldn't care about the features I would like (such as decent SEO) because it's kind of invisible to them. All they really want is the platform to discuss, for it to perform well and be secure.

But I do trust that there is a lot more to come in this release that actually will be useful for the majority of forums. These HYSs are really a bit of a teaser.

In my opinion, I would say it's to early to judge and critic new updates. Let's wait for full list of features or release, and then we can judge and complain about features, etc.

I totally agree, I withdraw my above comment. :)
 
I have a question about announced "User profile banners" feature.
Desktop user ads a 2000x300px banner that is 1.5Mb. He is on a cable so he doesn't see a difference in page load speed.
Now mobile visitors (more than 50% these days, and growing) will notice that a page loads almost twice longer.
So will xF 2.2 have such things like srcset/sizes/<picture> & webP support ? Otherwise this feature is not just useless but harmful.
It is neither useless, nor harmful because if those things were somehow a significant risk to your forum or your users then you'd be able to just disable it using permissions.

As it happens, we store two sizes. The "large" size is resized to a maximum width of 1280px and the "medium" size is resized to a maximum of 640px.

The large size is what is displayed on the user's profile. The medium size is shown in other places, such as the smaller preview image when editing a user via the admin CP and on the member tooltip.
 
Last edited:
@Chris D, is it possible to clarify on user profile banners? The banner system will have its own handler that will handle banners with the possibility of simple implementation for different types of content such as threads, resources, etc?
 
Desktop user ads a 2000x300px banner that is 1.5Mb.
Just as a way to address this example specifically...

Here's a 2000px x 500px image:
City-Montage-2000x500.jpg


It is 1.1MB so not quite 1.5MB but this will be a good example.

Here it is after being uploaded as a profile banner:
1.jpg


It is now 1280px x 320px and 282KB.

The medium size:
1591097797727.png


640px x 160px and 66KB.

In the grand scheme of things, that shouldn't be a significant overhead. And if your users will never visit the profiles anyway, as you mentioned, then I assume even that additional load will be insignificant for many.
 
@Chris D, is it possible to clarify on user profile banners? The banner system will have its own handler that will handle banners with the possibility of simple implementation for different types of content such as threads, resources, etc?
We've never really considered or intended other uses for this system so it is just focused on user profile banners at the moment. Actually very similar to the user avatar system in many ways.
 
Thanks for a reply, Chris.

As it happens, we store two sizes. The "large" size is resized to a maximum width of 1280px and the "medium" size is resized to a maximum of 640px.

The large size is what is displayed on the user's profile. The medium size is shown in other places, such as the smaller preview image when editing a user via the admin CP and on the member tooltip.

Yep. Exactly my point. Software for desktop users.

Just as a way to address this example specifically...
Yeah, I got it from the starting post.

And if your users will never visit the profiles anyway, as you mentioned, then I assume even that additional load will be insignificant for many.
As I already wrote who cares about profile backgrounds?)
I'm a little bit ahead of the conversation. I do care about pictures in posts. attach=full is my headache for the last year since I moved to xF. Mobile visitors have to download 1.5-5Mb pictures to view a thread...
After reading User profile banners announcement I don't have to be Sherlock to figure out that I should not expect that xF 2.2 will be cured from that.
[sad sad almost crying smilie ] )))
 
What I would like to see in the new Xenforo, besides visual design.

1. Automatic deletion of inactive private messages that are more than a year old and they are not used and only increase the size of the forum - this tool should be in the standard version, it is important.
2. Resizing photo attachments, based on a high-quality algorithm that could automatically reduce the inserted photos.
3. The ability to work with attachments directly, rename, crop, modify. To keep the attachment name the same, its thumbnail copies were with clear names.
4. Automatic resizing of avatars, as well as their reduction.
5. Creating an addon Blogs, high-quality, understandable, convenient, as much as possible integrated into the forum.
 
Ah great, looking forward to what is new!

While also worried how much work to convert :LOL: at least it going gold is a long time off and plenty of time to test and plan

Feels like 2.1 was only the other month
 
Automatic deletion of inactive private messages that are more than a year old and they are not used and only increase the size of the forum - this tool should be in the standard version, it is important.
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.

Let me introduce you to @Bob 's Blog add-on.
IIRC this is a private Add-on that can't be purchased by everybody, right?

Agreed, the default when upgrading a forum should be behaviour as now, not automatically setting new permissions.
Ack. This shoud be off by default for upgrades to keep compatibility with existing behaviour but can of course be enabled for new installs.
 
Last edited:
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.
 
I understand that personal correspondence is possible and does not take up much space if you remove large photos from them, but still, I really want to have all the necessary tools for optimization, I want to transfer most of the points to the shoulders of automatic processing. You undoubtedly have done a lot, working with mail and processing user complaints is simply brilliance, beyond praise. I would like for all other points the same high level of processing. Although many do not begin to use certain tools, it’s good if they are. For example, you have created tools for changing Names, it may not be very popular on my forum, but I say this is a great success, it will come in handy and many will say thanks. Maybe we will make a vote of the Forum Administrators, what tools would they most like to see in their forum? Let it be only 5-8 points, but we will immediately see which directions a lot of users are concerned about. They will select points 1 or 3, pay close attention to them and try to narrow the search for changes that interest them. I don’t want the forum to become like competitors, I like your forum, really like it, but like all users I want changes and new significant functions, new breakthrough solutions, interesting new plugins, such as a media library. Well, let's create blogs from scratch, for a fee, let those who are of interest to them buy, let the price be high, $ 200, but many will buy and it will come in handy for them, like a media library. Yes, no one can do it as you do, and no third-party addon will work the way you forum developers do.

Sorry for my english, this is google translator
 
The forum is as international as possible, I think the time has come to translate all the instructions and the forum itself into the most basic languages, choose the best translators and simplify its capabilities to new users as much as possible. And then they will read, the audience will increase.
Yes, the official translation of the forum will be paid, but it will be of high quality, I will buy as well as thousands of users from the same Russia, by the way there are a lot of them.
 
Back
Top Bottom