Problem/Motivation
\Drupal\Core\Ajax\RedirectCommand allows redirecting users to a different route after processing form. However, there isn't currently a way to render a different dialog after processing a form. This is needed in some multi-step forms that are using dialogs where the system needs to take the users to a controller or a form behind another route. This is critical in particular when working with forms because form API always depends on the current route match to be up to date to know which route to submit the form.
One existing use-case for this is #3386762: Use modals in field creation and field edit flow.
Steps to reproduce
Proposed resolution
Create a command that replicates the functionality of the \Drupal\Core\Ajax\RedirectCommand but operates within dialogs.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3408738
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:
Comments
Comment #2
srishtiiee commentedComment #3
lauriiiComment #5
srishtiiee commentedComment #6
srishtiiee commentedComment #7
arisenThanks for the feature suggestion @srishtiiee.
Reviewed the Merge Request. The changes look good and working as expected.
Tested the same on a Drupal 11 installation.
Testing steps:
Attaching the screenshots.
This looks RTBC for me.
Comment #8
smustgrave commentedFeels like something that will need a CR
Comment #9
smustgrave commentedComment #10
benjifisherI am adding #1886616: Multistep Form Wizard as a related issue. I have not looked at it closely, but I think that is more specialized than this issue, trying to make it easier to create multi-step entity forms.
Comment #12
kunal.sachdev commentedUpdated the already existing CR for this.
Comment #13
kunal.sachdev commentedComment #14
smustgrave commentedCR reads well.
Applied the MR and used the snippet in the CR to open a dialog. I used a node add form, as that's something I'm currently working on in my project.
Reviewing the code and believe this is good
Comment #15
tim.plunkett+1 to RTBC, the Drupal.ajax vs ajax discussion in the MR can be resolved
Comment #16
wim leersThere are a bunch of small inconsistencies in the code. Some parameters/decisions should be documented. And most importantly: neither this MR nor the CR document how this relates to the multiple existing dialog-related AJAX commands. "When to use which?" is a critical portion of landing this.
Comment #18
arisenUpdated the CR to address this.
Comment #19
smustgrave commentedCR appears to have been updated with a usage.
Not sure where documentation should go though. Assuming here https://www.drupal.org/docs/drupal-apis/ajax-api/core-ajax-callback-comm... but imagine the update should be after the code is committed right?
Comment #20
wim leersThis is still missing crucial documentation, so it can't be RTBC.
Plus, based on the test coverage I just realized that this appears to be introducing a new potential attack surface 😰 So tagging as well…
Comment #22
omkar.podey commentedComment #23
wim leersComment #24
omkar.podey commentedComment #25
omkar.podey commentedComment #26
omkar.podey commentedSet to needs work for writing a better test.
Comment #27
wim leersDetailed my security concerns at https://git.drupalcode.org/project/drupal/-/merge_requests/5810#note_272697.
Comment #28
omkar.podey commentedComment #29
catchThe hardening and test coverage looks good to me.
Comment #30
smustgrave commentedHave posted to #security-discussion in slack so fingers crossed someone can pick up.
Comment #31
lauriiiThe aspect that required security review has been addressed. I think a regular committer review is sufficient now.
Comment #32
wim leersYes, agreed, the security concerns I raised are now addressed 👍
Just a few remarks to ensure A) docs are discoverable by developers, B) this stays aligned/in sync with the other place in core where this pattern is used.
Comment #33
omkar.podey commentedComment #34
lauriiiFeedback from @Wim Leers has been addressed 👍
Comment #37
catchOne more thought - we could add an extra method on UrlHelper for the local check, combining those two method calls. I was thinking about a trait, but why not just an extra helper method directly on that class.
Not for here though, so committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!
Comment #39
quietone commentedFollow up added #3437765: Add an extra method on UrlHelper for a local check