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.

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.

Very much related to this proposal: (but not required)

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.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

I updated the summary with a few small English corrections.

@Rob C, do you have a plan for:

  1. what needs to be in before feature freeze?
  2. what can be done after that (but before the code/string freeze?
  3. and what can be done after code freeze but before 8.x release (the pure bug fix time)?

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.

YesCT’s picture

Issue summary: View changes

Updated issue summary for grammer mostly.

Rob C’s picture

Issue summary: View changes

Updated a bit of 'stage' info.

Rob C’s picture

Issue summary: View changes

More small tweaks

Rob C’s picture

Issue summary: View changes

Added suggestions.

Rob C’s picture

Issue summary: View changes

Added 75924 note.

Rob C’s picture

Issue summary: View changes

Added demo 2.

Rob C’s picture

Issue summary: View changes

More changes.

Rob C’s picture

Issue summary: View changes

More order.

Rob C’s picture

Issue summary: View changes

Small tweak.

Rob C’s picture

Issue summary: View changes

Removed drupal_password_reset-75924-46.patch as dependency. It's now a related issue.

Rob C’s picture

Issue summary: View changes

Added Album 3 screenshots link. More small updates. (preparing for the patch now)

Rob C’s picture

Issue summary: View changes

Minor update.

Rob C’s picture

Issue summary: View changes

Added 2 more patches i found to the 'related' list.

Rob C’s picture

Issue summary: View changes

Added more related issues, added expose hidden variables idea.

Rob C’s picture

@YesCT

1:

  • Investigate / tweak some not so flexible parts of the user module that are related to login/register/etc. and fix them up.
  • The basic structure needs to get in, we can continue to add options later on.
  • A basic version of the 'modes' and 'easy configuration' functionality for on the 'simple' config page have to be coded if we want that to get in D8, else > D9.

2:

  • Add more hidden system variables as options to the advanced config page.
  • Rewrite some parts of the current patch to maybe use more of the new JS functionality that's in core and other core functionality we can really benefit from.
  • More smaller tweaks and fixes as we go.

3:

  • Investigate and fix a couple issues listed on the issue, like the activation e-mail, the way the user pass reset function and others work (in regard to flexibility).
  • General bugs listed on this issue.

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!

Rob C’s picture

Issue summary: View changes

More tweaks.

Rob C’s picture

Issue summary: View changes

Added another related issue.

Rob C’s picture

Issue summary: View changes

Yet another related issue.

Rob C’s picture

Issue summary: View changes

Fixed oopsie.

Rob C’s picture

Issue summary: View changes

More issues, typo.

Rob C’s picture

Issue summary: View changes

Added even More details.

Rob C’s picture

Issue summary: View changes

1 space missing.

yautja_cetanu’s picture

Cool! 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.

Rob C’s picture

Status: Active » Needs review
FileSize
38.46 KB

The 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:

  • E-mail templates needs to be completely moved to the system.module. All related variables everywhere could be put under system.mail, but that's just a suggestion to make that more structured.
  • Limits need to be changed to have an option.
  • Global limits need to be implemented.
  • The fieldset summary javascript needs to be created to show a summary just like the node.js does.
  • There are some comments and TODO marks still in place, but that's just speed up future work.
  • See other related issues for more TODO's.

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.

Rob C’s picture

Issue summary: View changes

Updated issue to current state. Patch is done, will be added soon.

yoroy’s picture

Issue tags: +Usability

Adding
Improving the Sign In Registration and Account Management interactions
for ideas and prior art around the same topic

Status: Needs review » Needs work

The last submitted patch, 1837054-drupal-meta-refactor-account-workflow-and-config-4.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Updated to current state + added patch.

Rob C’s picture

Issue summary: View changes

Axed old stuff.

Rob C’s picture

Status: Needs work » Needs review
Issue tags: +Needs tests
FileSize
41.73 KB

This 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.

YesCT’s picture

adding tags.

@Rob C
some questions:

  1. are the list of related issues totally separate from the code/patch here?
    Or is the patch here just an easy way of trying out the patches from those related issues?
  2. the related issues in the issue summary that have (feature) in front, is that feature as in "need to be done before feature freeze"?
Rob C’s picture

@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:

  • Patches that offer configurable options that are related to registration/authentication/etc.
  • Functionalty that offers things like the 'Limits' (flood) related functionality would have to be patched to include a configuration option + obey to the 'global' 'Limits' (flood) option, if not overriden on the specific reg/auto/etc. configuration page.
  • To be created options / access to existing system variables. (So no new functionality, just expose things that already exist.)

(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.)

Rob C’s picture

Issue summary: View changes

Minor tweak.

Rob C’s picture

Issue summary: View changes

Minor update, added 1 module-suggestion.

Status: Needs review » Needs work
Carsten Müller’s picture

Issue summary: View changes

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.