This proposal is about stripping all non-account options from the 'Account settings' configuration page and moving them to a new configuration page below 'People' called 'Account workflow'.
I have been doing some work on the registration / authentication process in contrib space last couple months and found that, while being very flexible already, there are some areas that i feel could use some love. Some people say the registration process lacks a couple basic functions lots of other systems support, or at least a more structured way to configure it all. And not that we need to copy behaviour, or be like them, but I would like to propose to stay close to the people that actually have to use Drupal (end-users). While Drupal 7 is already a major step in the right direction, i believe we can do more, if only to offer more flexibility for site owners/administrators to change the registration workflow features, without having to start coding. (i'm taking about very basic thing here, like forcing a password field on registration, forcing people to change their passwords after using a one-time-login link, e-mail field confirmation on registration by adding an extra e-mail field on the form (people (end-users) are pretty used to that by now), and so on.) These are minor tweaks and features, but if you put them all together, you got a pretty nice stack of highly flexible options. (Features in this context has nothing to do with the 'features' module, nor does the 'context' module has anything to do with this line of text.) (just to be clear)
Another thing i myself believe could use some love, is the idea to provide a real 'home' for all known authentication/registration/cancellation/etc modules. There's a long list of 'package's modules use to define the group they belong on on the modules page, but even worse, the configuration page is getting larger and larger if you install just a couple of these modules. Why? They are not only placed under 'people', but also under 'system', a completely 'new' entry, with separate menu items (because the dev didn't figure out the fine details for context menu items), and so on. Why does this happen? Because developers dont find the 'people' page the correct place for their module's options/config page, or they just dont know, or the project is to big/complex to put it below 'People', etc, etc. For node type options it is so clear for everybody where to place their module's options, but for registration/auth/cancel options this structure doesn't exist.
So another part of the idea also includes providing a place where core could stash the account workflow options in a more flexible setup, including contrib module options. This way it's easier for contrib module developers to know where to place their module's options and site owners / administrators have 1 place to look for these options.
This is how the current Account settings page looks like in Drupal 7. In Drupal 8 this didn't change much yet, but i see issues in the queues that will expand this page, making it even longer.
While i already received 1 comment about this proposal possibly getting to complex, i would like to react that having a page with a lot of stuff on it just isn't the right way and i also think it's even more complex in a lot of cases, how people experience it. And not only that, next to this you have tablets, mini laptops, etc. People are overloaded with info and options; that's just how we human beings work (or at least a large part of the group). Nothing against that; that's just how it is, but we can tackle this i believe (at least for a large part).
(I believe the system e-mail templates also have nothing to do with user account settings whatsoever, nor the registration/cancellation process. To be honest, i actually believe the 'E-mail templates' also do not belong on the 'Account workflow' page, i moved it to a separate item below system, see the current demo and screenshots.)
I've created 3 albums. The first shows the fully functional demo that's active on my test server with all possible bells and whistles enabled and the second is the previous version of the patch, from before i created a simple and advanced option and forms. The third album contains a combination of new input / new ideas we can unleash on this concept. This album is created from the current patch.
- Album 3 - Still very close to the current patch Current version. Demo page link (give me a couple days)
- OLD Album 2 - this is the album from the previous version of the patch Demo page link (current)
- OLD Album 1 - the start of this proposal. Demo page link
Stage 1 (Drupal 8)
Refactor the 'Settings' page and prepare it for new options currently in development (with (semi-)working patches available). (linked below) The focus for this stage is on providing the structure.Done
- Make an inventory of possible changes we need to commit to get in the direction of the next stage. WIP
Stage 2 (Drupal 9)
- Code a patch for the 'pluggable/more flexible reg/auth/cancel/passreset-workflows'-idea that continues on the work provided by the patch currently attached to this proposal. This is an idea that we can have a layer on top of the 'simple' config page people can use to 'easy-set' some settings. For advanced users we just provide the rough options on the advanced form. (so they can fine-tune/tweak-along)
But it would be great to have it in D8, or at least a basic version, we can later upgrade in D9.
- Current patch has 1 dependency: Drupal 8 core. Later on we can make more changes to facilitate Much much more configurable options. (we have 16 days till Feature freeze.)
- A simple select now exist on the 'simple accounts config' page to set a mode. This is a simple beta, just showing how it could look. Next step could be to improve on this.
- We need to write tests.
- 'Configurable Limits' need to be created / moved.
- We could use the callbacks for saving 'site access profiles' and delete the submit function that now deals with it. (would save us some switch()es.)
- Fix a couple very basic options for issues listed below.
Related issues / ideas / suggestions:
Very much related to this proposal: (but not required)
- feature #115801: Allow password on registration without disabling e-mail verification
- feature #432962: Add option to disable password strength checking
- feature #494518: Allow for custom user registration approval email address
- bug #366950: "Administer Users" permission should be separate from "Administer Account Settings"
- bug #1359718: Password reset fails when a user has a username that matches another user's email address
- feature #75924: Include fields for resetting password on the one-time password reset page
- feature #111317: Allow users to login using either their username OR their e-mail address
- feature #1521996: Privacy issue with 'Request new password' form: anonymous can check if someone is registered
- task #1496534: Convert account settings to configuration system
- feature #286401: email not required for Drupal account
- bug #189544: Allow administrator to edit account without email address (regression: accounts can be created without email addresses also)
- feature #259103: make pluggable password hashing framework more generic and use class auto-loading. (think i might need to create yet another context menu item)
- feature #64483: permissions & variable for disallowing editing of user variables i found this Classic. Would be nice to be able to do something like that at some point.
- task #1816836: Different User Types - (Party Hats) (mentioned here: #1816218: Separate the account information from the user entity.)
- task #1681832: Password reset spammable (and shouldn't be) (flood control options)
I hope / guess that in the next couple days / weeks (at least) a couple of the related patches that are linked here will be commited.
- (bug?) And what about the cancel account form-spam? Now that we have almost all of 'these' fixed...
- (bug?) Create a sepate e-mail template for 'Account unblocked'. Current code sends out an activation e-mail on unblock, that can't be right, you can't edit it separately now.
- "Prevent identical username and e-mail address". (description: "Enable this to make sure people do not submit identical username and e-mail address during registration.")
- "Prevent people from using their e-mail address in the "username" field during registration."
- Offer configuration options for multiple system variables, like for example, the new expire variable on the pass reset form. > config('user.settings')->get('password_reset_timeout')
- module Passive e-mail verification
User interface changes
The patch now creates 2 versions of the accounts config page:
- 1. a simple config page with only 2 options: site access profile and advanced configuration.
- 2. a more advanced version, enable by checking the 'Advanced configuration' checkbox on the configuration page. We want to hide all that stuff for beginner i guess, else it's getting waaay to complex. Beginners just want to be able to set a simple authentication / login workflow with, if possible, only 1 or 2 clicks - and then it should work for them, but advanced users could deal with loads more functionality / flexibility.
The simple version is a minimal-click system, where you only have to click a minimum number of times to just set it to a working mode that works for like ?% of all people using Drupal. (simple mode would/should also be able to set some pretty interesting settings, all depends on how much 'site access profiles' we create and how complex they will be.) The questionmark? I'm not sure, but 60%? At least. (if i have to guess, but could be a lot higher)
Real tweaker can then still dive into the advanced config and set values according to their case. They access the advanced setting via a config option on the simple config page.
- Account settings page stripped down to 'account' related.
- Created a new configuration page: Account workflow.
- A new dropdown with 'Site Access Profiles' is shown on the account workflow settings page.
- By default, a new simplified config page is enabled, people can click on an advanced checkbox and save the form to get on the advanced config page.
- 1 new function: hook_user_site_access_profiles().
- * This hook creates an array of site user profile modes. A profile is used to
- * quickly set variables and such after people save the account workflow
- * form in simple configuration mode.