The issue proposes a solution for the problems listed in
#3585400: Simplify and stabilize ConfigSingleExportForm implementation
and
#3568570: Config single export JavaScript fails
Go to single config export page and click on select items.
Content is not updated accordingly.
This problem does not occur on a new install, but on a real instance with a lot of views, some of which are complex (8000+ lines of yml). I guess that processing long lists and bigger yml increases the issue that on a clean install is not visible.
Refactor code to
Considering that the form is fairly simple (2 selects and one textarea), the loss of performances due to the update of the whole form instead of only a portion of it (i.e. select or textarea) is not significant.
No changes, the UI looks like the previous implementation
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | Screenshot 2026-04-18 185418.png | 14.68 KB | veverka42 |
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
Comments
Comment #2
veverka42 commentedComment #3
veverka42 commentedComment #5
veverka42 commentedComment #6
quietone commentedIssues are fixed on the main branch first.
If this is a fix for another issue, the MR should be made in that issue. In Drupal we work collaboratively, typically on the same MR. Other MRs are sometimes created, to show a different approach or when needed for a different branch. I think the work here and comments should be moved to #3568570: Config single export JavaScript fails.
Comment #7
fathershawnIf this is not reproducible on a Drupal site without any additional modules, then I don't see how it can be an issue with the core implementation of this form.
Comment #8
fathershawnIs the implementation of chosen using drupal behaviors to attach it's JS?
Comment #9
fathershawnComment #10
veverka42 commentedFinally I found out the root cause of the problem. In my case, it was not due to "chosen" module (which is not installed on my instance), but "webform_devel".
Specifically, there is the hook webform_devel_form_config_single_export_form_alter which was meant to apply codemirror formatting but breaks the htmx functionality on the Single Export Page.
To find this:
- first I looked to "network" tab in web browser inspector. On a clean Drupal 11.3.7 install, changing"config_type" or "config_name" from the single config export page showed calls initiated by htmx.js. On the instance in which I noticed the issue, changing "config_name" was showing also a call initiated by jquery.js.
- then I wrote "drupalSettings ajax" in the web browser console, which showed this
The callback from _webform_devel_form_config_single_export_form_update_export is the clue...
Uninstalling Webform Devel module is only a temporary workaround to avoid the problem.
Note: with the change I proposed in the MR, the form was working correctly just as a side effect, because I was using the whole form as htmx target and select, therefore replacing the whole form instead of the single elements. Because of this, the issue did not occur. There is no need to apply the change I proposed, the actual code is correct. I will open an issue on Webform Devel module (which is part of this, not this), since the root cause is there.
Comment #11
veverka42 commentedComment #12
veverka42 commentedComment #13
nicxvan commentedMoving to the correct project.