Problem/Motivation
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'.
Demo 2 (previous, but still very close, new demo soon)
Demo 1 (previous) (with a bunch of demo fields that are not part of any patch yet, but just exist to showcase the concept a bit).
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.
Let' start with a "Before picture":
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.)
After pictures:
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
Proposed resolution
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.
Remaining tasks
- 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: Allow password reset on account with the username matching another email; prevent registrations that match another account
- 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: Password reset form reveals whether an email or username is in use
- feature #2346389: Prevent registered e-mail address enumeration via user registration form
- task #1496534: Convert account settings to configuration system
- feature #286401: Make email not required for a Drupal site 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: [P-1] Separate the account information from the user entity.)
- task #1681832: Password reset form has no flood protection (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.
Other:
- (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.
API changes
- 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.
Comment | File | Size | Author |
---|---|---|---|
#7 | 1837054-drupal-meta-refactor-account-workflow-and-config-7.patch | 41.73 KB | Rob C |
#4 | 1837054-drupal-meta-refactor-account-workflow-and-config-4.patch | 38.46 KB | Rob C |
Comments
Comment #1
YesCT CreditAttribution: YesCT commentedI updated the summary with a few small English corrections.
@Rob C, do you have a plan for:
Observation... there are no tags on this. There might want to be a tag for this, that can also be added to the related issues.
Comment #1.0
YesCT CreditAttribution: YesCT commentedUpdated issue summary for grammer mostly.
Comment #1.1
Rob C CreditAttribution: Rob C commentedUpdated a bit of 'stage' info.
Comment #1.2
Rob C CreditAttribution: Rob C commentedMore small tweaks
Comment #1.3
Rob C CreditAttribution: Rob C commentedAdded suggestions.
Comment #1.4
Rob C CreditAttribution: Rob C commentedAdded 75924 note.
Comment #1.5
Rob C CreditAttribution: Rob C commentedAdded demo 2.
Comment #1.6
Rob C CreditAttribution: Rob C commentedMore changes.
Comment #1.7
Rob C CreditAttribution: Rob C commentedMore order.
Comment #1.8
Rob C CreditAttribution: Rob C commentedSmall tweak.
Comment #1.9
Rob C CreditAttribution: Rob C commentedRemoved drupal_password_reset-75924-46.patch as dependency. It's now a related issue.
Comment #1.10
Rob C CreditAttribution: Rob C commentedAdded Album 3 screenshots link. More small updates. (preparing for the patch now)
Comment #1.11
Rob C CreditAttribution: Rob C commentedMinor update.
Comment #1.12
Rob C CreditAttribution: Rob C commentedAdded 2 more patches i found to the 'related' list.
Comment #1.13
Rob C CreditAttribution: Rob C commentedAdded more related issues, added expose hidden variables idea.
Comment #2
Rob C CreditAttribution: Rob C commented@YesCT
1:
2:
3:
I will keep the issue as up to date as possibe, will post the concept patch for the structure redesign later today/tomorrow/day after that (with a bit of luck), then i'll focus on issues like the flood control for the pass reset functionality and others, but first things first.
O, and if anyone wants to add some useful tags, please do!
Comment #2.0
Rob C CreditAttribution: Rob C commentedMore tweaks.
Comment #2.1
Rob C CreditAttribution: Rob C commentedAdded another related issue.
Comment #2.2
Rob C CreditAttribution: Rob C commentedYet another related issue.
Comment #2.3
Rob C CreditAttribution: Rob C commentedFixed oopsie.
Comment #2.4
Rob C CreditAttribution: Rob C commentedMore issues, typo.
Comment #2.5
Rob C CreditAttribution: Rob C commentedAdded even More details.
Comment #2.6
Rob C CreditAttribution: Rob C commented1 space missing.
Comment #3
yautja_cetanu CreditAttribution: yautja_cetanu commentedCool! This definitely fits in with a bunch of stuff going on!
Kind of feel that ideally this would have something to do with Profile which can change some of the fields that appear on registration (I think).
Eventually the Panels-in-core stuff might impact this stuff.
Definitely agree that all this stuff needs a "home" there is loads of bugs and problems within Drupal that I think may get solved in one go if solved properly. Unfortunately I wonder if 20 days left till FF means that we're waiting until Drupal 9.
Comment #4
Rob C CreditAttribution: Rob C commentedThe first patch, this one mostly creates the structure to continue working on and implements the site_access_profiles-concept. Easy site setup for users who do not want to know about all fancy things you can set up on the advanced configuration page. (checkbox on the workflow settings page)
Issues that follow from this patch / already exist, but would be neat to get in:
Test the patch: (you need Drupal 8 before this can work.)
cd to the directory where Drupal 8 is installed, then execute:
wget http://drupal.org/files/1837054-drupal-meta-refactor-account-workflow-and-config-4.patch
patch -p1 --dry-run < 1837054-drupal-meta-refactor-account-workflow-and-config-4.patch
If this works without errors, try to apply it with:
git apply -v 1837054-drupal-meta-refactor-account-workflow-and-config-4.patch
And clear your cache, we created new menu items with this patch, so you need to clear your cache.
It does still need a bit of work, but let's see what our beloved testbot thinks about it.
Comment #4.0
Rob C CreditAttribution: Rob C commentedUpdated issue to current state. Patch is done, will be added soon.
Comment #5
yoroy CreditAttribution: yoroy commentedAdding
Improving the Sign In Registration and Account Management interactions
for ideas and prior art around the same topic
Comment #6.0
(not verified) CreditAttribution: commentedUpdated to current state + added patch.
Comment #6.1
Rob C CreditAttribution: Rob C commentedAxed old stuff.
Comment #7
Rob C CreditAttribution: Rob C commentedThis version does not add any new ideas, just changed related tests. More tests still have to be created for the new forms and all site access profiles, but i'm first having a go at site access profiles submit callbacks, just a small experiment. (and then we can create also tests for those). So if you would like to help out, write tests for all workflow/* submits, i didn't start on these yet.
Comment #8
YesCT CreditAttribution: YesCT commentedadding tags.
@Rob C
some questions:
Or is the patch here just an easy way of trying out the patches from those related issues?
Comment #9
Rob C CreditAttribution: Rob C commented@YesCT
1. Yes. It's totally separate. You only need Drupal 8 core.
2. If the current patch is accepted, you will currently have a lot of empty space, that is reserved for:
(And we could also hide all empty pages/fieldsets, until we have something to configure on that page/fieldset.)
The more new functionality get in that offer options the better. (For this patch that is. The more we have to render / change on the config pages, only helps us building the case that we need something like this at some point.)
Comment #9.0
Rob C CreditAttribution: Rob C commentedMinor tweak.
Comment #9.1
Rob C CreditAttribution: Rob C commentedMinor update, added 1 module-suggestion.
Comment #12
Carsten Müller CreditAttribution: Carsten Müller commented