Problem/Motivation
#3398982: ConfigFormBase + validation constraints: support non-1:1 form element-to-config property mapping again introduced the necessary infrastructure to remove validation logic from forms, move them into config schema instead, and have the validation constraints in config schema automatically applied.
A few days ago #3395555: Add validation constraints to olivero.settings landed, which removed olivero_theme_settings_validate()
because it now is obsolete, thanks to Olivero's config schema defining validation constraints and its theme settings form having adopted #config_target
🚀.
Which also reveals an opportunity for building on top of what #3398982 did and removing the need for duplication. This change landed:
- '#default_value' => theme_get_setting($key),
+ '#config_target' => "olivero.settings:$key",
'#attributes' => [
// Regex copied from Color::validateHex()
'pattern' => '^[#]?([0-9a-fA-F]{3}){1,2}$',
— the commit for #3395555.
But note how [#attributes' => ['pattern' => …]]
still repeats the exact same regex. This is what enables HTML 5's native client-side validation.
Steps to reproduce
N/A
Proposed resolution
Automatically set [#attributes' => ['pattern' => …]]
.
Remaining tasks
Implement this.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
HTML 5 client-side validation is now automatically applied to config forms for those form elements whose corresponding config key has the RegEx
validation constraint defined in its config schema.
Issue fork drupal-3420770
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
Wim LeersComment #3
catchAre we actually using client side validation in core anywhere? I vaguely remember there being reasons (translation?) we don't yet, but can't find a discussion.
Comment #4
Wim LeersHah, looks like this is pretty much the only place in Drupal core? 😅
I did find
\Drupal\Core\Render\Element\FormElement::processPattern()
though, which handles these, introduced in #2305839: Convert hook_element_info() to annotated classes.Comment #7
Wim LeersWow, those test failures make no sense at all 🙃
I did spot one problem in the current MR, but doubt that'll fix it.