ConfigSingleExportForm uses the Ajax API to dynamically update the form.
Refactor the form to use HTMX. The existing ajax callbacks can be adapted however their calling context changes and that necessitates the adaptation. If they are called during form building then they need to build correctly when input has not been processed at which point FormState::getValues returns empty.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | single-export-form-refactor.gif | 1.51 MB | joaopauloc.dev |
Show commandsStart 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, plain diff MR !13206
Comments
Comment #2
nod_Comment #4
fathershawnComment #5
fathershawnAll tests passing - only changes to the form. Existing test could remain in place because of HTMX detection added in #3535173: Support dynamic forms using HTMX
Comment #6
joaopauloc.dev commentedI can confirm that the singles export item still working after the refactor.
Steps used to test:
New Drupal installation.
Checkout branch issue.
Navigated to /admin/config/development/configuration/single/export
Select the Configuration type.
Select the Configuration name.
The content of the settings loaded correct inside the textarea.
Attaching the evidence.
Comment #7
nod_very eager to get that in but a few things to fix first
Comment #8
fathershawnFeedback addressed and all tests passing.
Comment #9
nod_I attached the push url to the form itself, since it's not about the field itself it's more about the whole form. And refactored a bit to make only one call to the pushUrlHeader.
I've spent days on this form trying to understand the form api, and an other version of this form is used in the Htmx tests so I'm confident we got everything working. it's also an improvment compared to before because we can use the back button of the browser now :)
Comment #10
fathershawnComment #11
nod_seems like the last commit undid a bunch of things on the MR (including the fix to make sure we don't have "- Select -" in the push url).
reapplied the fixes and used the new method to get the trigger name.
Comment #12
fathershawnNice! Thank you @nod_
Comment #13
alexpottBackported to 11.3.x and this is not a disruptive change allowed during alpha.
Committed and pushed 9761c3f1048 to 11.x and 237e3e7b8e6 to 11.3.x. Thanks!
Comment #17
quietone commentedPublish CR
Comment #19
gábor hojtsyComment #20
wim leersJust wanted to say: I've noticed this change, and I very much appreciate it — a significant quality of life improvement! 👏🙏
(Catching up on months of core CRs, that's how I ended up finding and writing this!)
Comment #22
veverka42 commentedPlease reopen, i found an issue with the form. More details here https://www.drupal.org/project/chosen/issues/3568570#comment-16553454
Comment #23
fathershawnI suspect this is about chosen integration with the form not expecting htmx. If you find a specific issue with the form, please open a new issue.
Comment #24
veverka42 commentedFollowing your suggestion, I opened https://www.drupal.org/project/drupal/issues/3585442 with the problem description and proposed solution.
Comment #25
veverka42 commentedThe problem I reported was actually due to Webform Devel module, in which there is an hook which alters the ConfigSingleExportForm.
More details here https://www.drupal.org/project/drupal/issues/3585442#comment-16555761
Comment #26
veverka42 commentedSee https://www.drupal.org/project/drupal/issues/3586719 for an error occurring on a clean install (via composer create drupal/recommended-project)
Comment #28
veverka42 commentedthe problem reported in comment #26 occurs without additional modules installed
Comment #29
nicxvan commentedYes, we are tracking the bug in #3585442: Wrong values in ConfigSingleExportForm when paired with Webform Devel (part of Webform)