- Issue created by @ambient.impact
- 🇨🇦Canada ambient.impact Toronto
Fixed a silly typo and added missing link to
\Drupal\Core\Form\ConfigTarget.
After doing a bit of a deep dive into what's causing unexpected test failures on Drupal 10.2 in
🐛
Cannot access Block, Field UI, Views UI config pages when Config Enforce Devel is enabled
Needs review
(we use the system logging form for one of our tests), it looks like the new, opt-in #config_target form element property introduced in
#config_target in ConfigFormBase: using validation constraints for editing simple config →
is the reason. This doesn't prevent enforcing a config, but does cause Config Enforce (and Config Enforce Devel) to not associate a given config form that uses #config_target with a configuration, so our embedded enforce form never shows up on that form. Such forms are not required to list their config in getEditableConfigNames() which why our detection is now failing, as we rely on that method to give us the simple config names; see
📌
Do not require the config in #config_target to be listed in getEditableConfigNames()
Active
.
Visit any of these core forms in Drupal 10.2.x and observe that the Config Enforce embedded enforce form never shows up for these:
admin/config/development/logging (\Drupal\system\Form\LoggingForm)admin/config/media/file-system (\Drupal\system\Form\FileSystemForm)admin/config/services/jsonapi (\Drupal\jsonapi\Form\JsonApiSettingsForm)admin/structure/views/settings (\Drupal\views_ui\Form\BasicSettingsForm)How did I come up with this list? I looked at all the forms that use the new \Drupal\Core\Form\RedundantEditableConfigNamesTrait, which is a small number in core right now but will grow over time and likely be applied to all the forms in core that previously returned a non-empty array from getEditableConfigNames(); see https://git.drupalcode.org/project/drupal/-/merge_requests/5236/diffs
We need to add support for #config_target but re-implementing core behaviour would be dumb and thankfully core provides a new non-@internal \Drupal\Core\Form\ConfigTarget value object that has a fromForm() static method we can use.
We'll want to figure out how to handle Drupal core older than 10.2.x; we can probably just create a backwards compatible class_alias for \Drupal\Core\Form\ConfigTarget if it doesn't exist with dummy methods that return empty values?
TBD; see previous heading.
Config Enforce stuff shows up once again on the above forms so you can enforce from the form again.
Minimal or none? I suppose a backwards compatible wrapper might be an additional API addition which is technically a change in the broad sense but shouldn't change existing stuff.
Probably none.
Active
1.0
User interface
Fixed a silly typo and added missing link to \Drupal\Core\Form\ConfigTarget.