The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
When a site has a single registration type (which may be the majority of sites using this module, or at least a decent percentage), it should be possible to enable a single step workflow for changing the host. This should be a simple form with no fields except a select with possible hosts in it.
Another possible use case is a site with multiple registration types that have the same fields.
Proposed resolution
Add new settings allowing site builders to specify either single step or multistep workflow, with guidance on when each is appropriate.
Add new settings allowing site builders to control the labels used for various "change host" related titles.
Add the new single step form, and adjust the existing controller to use it when indicated to do so by the new settings.
Remaining tasks
Implement the proposed solution, with tests.
User interface changes
The new change host module will provide an easier path for site admins when the single step workflow is enabled.
API changes
None
Data model changes
None
Issue fork registration-3502040
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
john.oltman commentedComment #3
john.oltman commentedComment #4
jonathanshawI agree it's a reasonable feature.
One of the reasons I didn't invest more in this approach was that I came to the conclusion that as a default or best practice it was probably good to get a registrant to re-confirm all of their submitted registration field values when they changed host.
One way of thinking about this is as a 3 way division:
(1) Changing host is a big deal, needs to be a separate action, have a fancy UX to explain the choices, and they have to reconfirm all their fields.
(2) Changing host is not such a big deal that they need to reconfirm all their fields, but it should still be a separate action and have a fancy UX for the list of choices.
(3) Changing host is no big deal, it can just be a widget on the regular form for editing a registration.
I'm a bit doubtful that (2) is a big group. I wonder if (3) is a use case worth investing in first.
Regarding the implementation proposal you give for (2) I wonder if there's a way to reuse the existing controller. If you could live with a second 'confirm' step then it'd be trivial to hide the edit form on the current ChangeHostForm.
Comment #5
john.oltman commentedUpdated proposed resolution.
Comment #8
john.oltman commented@jonathanshaw, if you pull this update, you should uninstall and reinstall the module so you get the new settings. To see or adjust these, go to the global settings page at /admin/structure/registration-settings.
I ended up implementing a hybrid of (2): Changing host is not such a big deal that they need to reconfirm all their fields, but it should still be a separate action. Because fields do not need to be reconfirmed, there is a simple UX for the list of choices.
I am leaving the choice of which interface, simple or complex, to the site builder. I am defaulting to the complex, since it is safer, and in this way it is benign to all the pre-existing tests and previous implementation.
Having this simple UX opens up the possibility of having "change host" permission do what it says, and allow access to change host without access to update all fields. It should be a simple matter to check the new workflow setting and adjust that access code not to enforce the update permission for the single step workflow. I'll see if I can work that in soon. It seems reasonable to continue checking update access for the multistep workflow.
Comment #9
john.oltman commentedThis commit also fixes a bug in the data loss checker, and adds the registration type to the possible hosts cacheability, since it checks the third party setting there.
Comment #12
john.oltman commentedAdded fixes for correct cachability