Reply to thread

Message: <blockquote data-quote="XenForo" data-source="post: 1430349" data-attributes="member: 1">[ATTACH=full]226621[/ATTACH]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 <a href="https://xenforo.com/community/forums/have-you-seen/">here</a> and enabling email notifications if you haven't done so already <img class="smilie smilie--emoji" loading="lazy" alt="🙂" title="Slightly smiling face    :slight_smile:" src="https://cdn.jsdelivr.net/joypixels/assets/6.0/png/unicode/64/1f642.png" data-shortname=":slight_smile:" />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...<h2>New minimum requirements</h2>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 <a href="https://xenforo.com/community/threads/push-notifications.154592/">first HYS thread for XenForo 2.1</a> 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:[ATTACH=full]226614[/ATTACH]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?!<h2>User profile banners</h2> [ATTACH=full]226619[/ATTACH]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.[ATTACH=full]226620[/ATTACH]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.[ATTACH=full]226615[/ATTACH] Still so blue... still so fancy...[ATTACH=full]226621[/ATTACH] Of course it's only fair that we apply the same pizazz to the member tooltip too:[ATTACH=full]226622[/ATTACH] 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:[ATTACH=full]226616[/ATTACH] 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.[ATTACH=full]226617[/ATTACH] And moderators who have permission to "Edit basic user profiles" can also view and delete the existing profile banner:[ATTACH=full]226618[/ATTACH] And that's it...! For this feature, at least... <img class="smilie smilie--emoji" loading="lazy" alt="👇" title="Backhand index pointing down    :point_down:" src="https://cdn.jsdelivr.net/joypixels/assets/6.0/png/unicode/64/1f447.png" data-shortname=":point_down:" /><h2>Username change management</h2>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.[ATTACH=full]226630[/ATTACH] 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.[ATTACH=full]226623[/ATTACH] To change their username, a user simply needs to visit their <a href="https://xenforo.com/community/account/account-details">Account details</a> 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.[ATTACH=full]226627[/ATTACH] Once submitted the username is changed.[ATTACH=full]226628[/ATTACH]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:[ATTACH=full]226629[/ATTACH] And moderators (who have the "Approve / reject username change" permission) will expect to find the username change amongst the approval queue: [ATTACH=full]226631[/ATTACH] The user will receive an alert / push notification once the change has been approved or rejected.[ATTACH=full]226632[/ATTACH] [ATTACH=full]226633[/ATTACH] 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:[ATTACH=full]226624[/ATTACH] 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:[ATTACH=full]226625[/ATTACH] 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):[ATTACH=full]226634[/ATTACH]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:[ATTACH=full]226635[/ATTACH]This brings us nicely onto the final option which relates to what we consider to be a "recent" username change.[ATTACH=full]226626[/ATTACH] 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:[ATTACH=full]226636[/ATTACH] 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".[ATTACH=full]226637[/ATTACH] 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.<h2>Username validation and generic input validation</h2>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:[ATTACH=full]226638[/ATTACH]For developers, the implementation is as simple as adding a [ICODE]validation-url[/ICODE] 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!<h2>Security locking user accounts</h2>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:[ATTACH=full]226639[/ATTACH] [ATTACH=full]226640[/ATTACH] We'll outline in more detail the behaviour of each option below.<h3>User must change password</h3>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:[ATTACH=full]226641[/ATTACH] After confirming their existing password and entering a new password, the user is redirected to the URL they tried to access originally.<h3>User must reset password</h3>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:[ATTACH=full]226642[/ATTACH] Shortly afterwards, an email should arrive to the email address on their account which will look like the following: [ATTACH=full]226644[/ATTACH] The "Reset password" button will take them to a form where they will be able to choose a new password: [ATTACH=full]226645[/ATTACH] And in this particular case it must be a new password. We prevent the user from picking the same password they already have. [ATTACH=full]226643[/ATTACH] 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...? <img class="smilie smilie--emoji" loading="lazy" alt="👇" title="Backhand index pointing down    :point_down:" src="https://cdn.jsdelivr.net/joypixels/assets/6.0/png/unicode/64/1f447.png" data-shortname=":point_down:" /><h2>New "Batch update users" actions</h2>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":[ATTACH=full]226646[/ATTACH] 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:[ATTACH=full]226647[/ATTACH] 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.</blockquote>

Verification