Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem
There is currently no standard (and easy) way in Drupal's Form API to allow for a user friendly form submission confirmation step.
We have ConfirmFormBase which can be used as a separate form for a single action, this is not fit for a multi-step flow in which you first want to gather input from the user. And it is especially not straightforward to ask for extra (to be validated) input during a confirmation step.
Exemplary is the current edit account page. In this case the Edit action and Confirm action are put together on the same page. Several usability studies, including the issue below, show that this pattern is confusing to users.
https://www.drupal.org/node/1259892
But also the new Content Layout functionality could benefit from this new option.
Solution
Introduce a confirmation modal, which optionally allows for extra user input that can be validated.
This allows for easily separating two dedicated user interaction steps from each other. So users only need to deal with one step at a time, and by using a modal the urgency is more clear and allows for a more fluid interaction.
By providing a standardized solution to this problem contrib can also create better forms.
Example
Please see how it can work in the following prototype.
This prototype uses the Edit Account page as an example. When submitting changed field(s) that require the current password to apply, show a modal window asking the user to confirm the changes by entering the current password.
http://prototype.goalgorilla.com/drupalux/currentpassword/#g=1&p=edit_ac...
API changes
We would need some new properties/methods to the Form API that allow to:
- Set that a form submission confirmation is always needed OR set a list of fields that need confirmation on change
- Give a custom confirmation form (class), which defaults to a default confirmation form like ConfirmFormBase.
Other examples
This design pattern is also widely used by other services.
Mailchimp:
Hubspot:
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | hubspot_modal.png | 48.82 KB | dmsmidt |
| #4 | mailchimp_modal.png | 28.79 KB | xinyuma |
Comments
Comment #2
xinyuma CreditAttribution: xinyuma commentedComment #3
cilefen CreditAttribution: cilefen commentedThis does not meet the criteria for a critical bug.
Comment #4
xinyuma CreditAttribution: xinyuma commentedComment #5
dmsmidtI really like the mock-up and the potential usability improvements for confirm steps of any form. This is especially true for the edit user form where the user needs to enter his current password.
This design pattern is a proven concept (see Mailchimp screenshot).
I found two related issues about using modals for a confirm step:
#2253257: Use a modal for entity delete operation links
#2254935: Use a modal for content entity form delete links confirmation forms
Also people are asking for this feature on StackExchange.
(Elaborated the IS after our Slack discussion)
Comment #6
dmsmidtFound another example by Hubspot.
Comment #7
yoroy CreditAttribution: yoroy at Roy Scholten commentedHere's another potential use case in core: https://www.drupal.org/node/2880374#comment-12152034
A situation where we might want to use an extra "are you really really sure" confirmation step.
Comment #13
cgomezgThere is any progress here?
Comment #15
ultrabob CreditAttribution: ultrabob commentedThe arguments for this being useful in core are very good, and I found this issue when looking for the best solution for my custom module, so it is definitely useful outside of core as well. Is there some process this needs to go through or does someone just need to start working on it and submitting patches?
Comment #17
idiaz.roncero+1, I came across this need for a project and it is too cumbersome to add a confirmation form.
In my case, the client sells "resources" (entity publication, amongst others) and those resources can be "consumed" on workflow state changes (i.e. when they "activate" an entity, the resource gets consumed, and this is costly for the user since "activation" is the scarcest resource).
We want to prompt the user for a confirmation in order to make it clear whenever their changes mean a resource will be consumed.
I think this is a common scenario and Drupal could provide for a simple way to "attach" a confirmation form or modal (i prefer forms because modals will introduce a Javascript dependency)
Comment #19
AaronMcHaleThis could be useful for user login, logout and password reset.
It could also be useful for the Entity API in deleting an Entity, the delete confirmation form would work well in a modal.
Comment #21
david.qdoscc CreditAttribution: david.qdoscc commentedI agree it would be nice to have this sitting between validateForm and submitForm
Comment #25
FeuerwagenThis maybe started as kind of a bug report, but apparently turned into a feature request shortly afterwards.
Btw: Looks useful to me as well. ;)
Comment #26
Tregonia CreditAttribution: Tregonia commented+1 for this being a potentially nice addition to core.
In my use-case, when a user is changed from Active to Blocked, several custom things are triggered. Having the ability to define a confirmation step between validation and submit would be a welcome addition, and better encapsulate all the form functionality.
Comment #27
maskedjellybeanI've love to see a solution for this.
I mistakenly thought I could solve this using
ConfirmFormBase(https://www.drupal.org/docs/drupal-apis/form-api/confirmformbase-to-conf...), but I've come to the disappointing conclusion that it's simply not feasible to add confirmation to an existing form that does not already extendConfirmFormBase. In order to add this to an existing form you would first need to override the existing form class with a new class that you control. This is possible. However, in order to avoid duplicating all of the code from the existing class, you would want to extend that class and only modify the necessary methods while calling the parent methods inside your modified methods when possible. But then of course your new class does not extendConfirmFormBase, so you are right back where you started.