Adopt Drupal core 10.3 config validation infrastructure

The last submitted patch, 2: 3394172-2.patch, failed testing. View results →

📌 Introduce a new #config_target Form API property to make it super simple to use validation constraints on simple config forms, and adopt it in several core config forms Fixed landed and massively simplified things! 🤩

So let's adopt this in a contrib module … this one 🤓

It was mostly easy, but it's less obvious how to port the custom UI that presents 3 simple choices to the end users, but configures a bunch of trickier things under the hood. Specifically, it's not clear how to port:

  protected static function copyFormValuesToConfig(Config $config, FormStateInterface $form_state): void {
…
    // Vertical tab: 'Mapping'.
    if ($form_state->getValue(['mapping', 'type']) === 'simple') {
      // Only the 'extensions' condition is supported in this UI, to KISS.
      if ($simple_mapping['extensions_condition_toggle'] === 'limited') {
        // Set the 'extensions' condition unconditionally.
        $config->set('mapping.conditions.extensions', explode(' ', trim($simple_mapping['extensions_condition_value'])));
      }
      // Plus one particular common preset: 'nocssjs', which means all files
      // except CSS and JS.
      elseif ($simple_mapping['extensions_condition_toggle'] === 'nocssjs') {
        $config->set('mapping.conditions', static::CONDITIONS_PRESET_NOCSSJS);
      }
      else {
        // Remove the 'not' or 'extensions' conditions if set.
        $conditions = $config->getOriginal('mapping.type') === 'simple' ? $config->getOriginal('mapping.conditions') : [];
        if (isset($conditions['not'])) {
          unset($conditions['not']);
        }
        if (isset($conditions['extensions'])) {
          unset($conditions['extensions']);
        }
        $config->set('mapping.conditions', $conditions);
      }
    }
…
  }

Cleanup.

End result:

 cdn_ui/src/Form/CdnSettingsForm.php | 145 ++++++++++++++++++++++++++++++++++++++++-----------------------------------
 1 file changed, 78 insertions(+), 67 deletions(-)

… but that's largely due to much more comments.

Doing this work uncovered a core bug/regression introduced by 📌 Introduce a new #config_target Form API property to make it super simple to use validation constraints on simple config forms, and adopt it in several core config forms Fixed : 🐛 Follow-up for #3382510: FormStateInterface::setErrorByName() needs not #name but a variation Closed: duplicate .

And one more bug: 📌 ConfigFormBase + validation constraints: support composite form elements Needs review .

The CDN module has been using validation constraints for years, but it only did so for A) things in the UI, B) things I knew once caused bug reports.

This gets us to 100% config validatability.

🐛 Follow-up for #3382510: FormStateInterface::setErrorByName() needs not #name but a variation Closed: duplicate was merged into 📌 ConfigFormBase + validation constraints: support composite form elements Needs review .

FYI: discussion about this at https://drupal.slack.com/archives/C2THUBAVA/p1699266350427109

I see the interdiff at #5 was wrong. Here's the right one.

Based on #11: proposing to restore ::mapConfigKeyToFormElementName() in core and making copyFormValuesToConfig() protected.

Will move the core patch to a core issue shortly.

Forgot the interdiff 😅

Now moved the core patch from #13 into the core issue queue at #3398982-9: ConfigFormBase + validation constraints: support composite form elements → .

Wim Leers → credited alexpott → .

Update to stay in sync with #3398982-25: ConfigFormBase + validation constraints: support non-1:1 form element-to-config property mapping again → , where I implemented @alexpott's suggestion.

Note: 📌 Allow all callables in ConfigTarget Fixed will allow making #17 far less verbose 😊

Update for 📌 Allow all callables in ConfigTarget Fixed , since that's also in now!

Far less verbose 🤩

Comment tweak because 📌 ConfigFormBase + validation constraints: support composite form elements Needs review now is always passing FormState as the second parameter.

Updated for #3398982-54: ConfigFormBase + validation constraints: support non-1:1 form element-to-config property mapping again → .

Updated for #3398982-59: ConfigFormBase + validation constraints: support non-1:1 form element-to-config property mapping again → .

#3398982 landed!

A new 4.1.x branch only makes sense after 📌 Adopt GitLab CI: PHPStan compliance + test against 9.5/10.0/10.1/10.2/11.x + max PHP version Fixed is done.

📌 Adopt GitLab CI: PHPStan compliance + test against 9.5/10.0/10.1/10.2/11.x + max PHP version Fixed landed.

Per #3421351-8: 5.x to require PHP 8.3 and >=10.3: bump requirements + fix deprecations → : 10.3 added some crucial infrastructure, 10.2 alone does not get us far enough.

🌱 5.x requiring PHP 8.2 and >=10.2, 6.x requiring PHP 8.3 and >=11? Or skip that 5.x? Active is in, rebasing on top of that, to start seeing the actual failures instead of out-of-scope D10-to-11 trivialities.

This is both more thorough than the validation ever was and friendlier for the end user!

I'm satisfied with where this has arrived.

(I'm less satisfied with the anticipation of complex CDN configurations that likely nobody ever used … and now I'm carrying forward the internal complexity for that 😅)

Automatically closed - issue fixed for 2 weeks with no activity.