Add validation constraint to `type: label`: disallow multiple lines

Now that 📌 KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate Fixed is in, we'd be able to instantly see how much effect this would have. Let's find out!

Wow, zero violations, really?! Maybe the violations only occur in functional tests? 🤔

Verified again locally that this indeed works correctly by changing core/profiles/standard/config/install/taxonomy.vocabulary.tags.yml to have a multi-line description and running StandardTest. Fails as expected 👍

So let's:

1. Add explicit test coverage.
2. Run the full test suite again.

This needs another rebase it seems. Very suprised that only a few things in core were giving errors on this. Not sure if all the tests have ran on the last time, there is a change in drupalci.yml that needs to be undone.

Oops, yes, I forgot about that 🙈 Done! Probably hundreds of test failures now 😄

Well well … I guess almost nothing in Drupal core uses a multi-line label!

I really thought at least some contact form would trigger this, or a vocabulary description, or a menu description … but no! 😮

And sure enough, e.g. core/profiles/demo_umami/config/install/contact.form.feedback.yml uses a single line!

This looks great, even better that nothing fails but we still improve strictness.

Shouldn't we remove the incorrect uses of type: label mentioned in the issue summary (or at least have a follow-up to do that)? The UIs for these certainly would enable creating invalid config at the moment.

#10: works for me!

Turns out that taxonomy.vocabulary.*:description's UI actually does not allow multiple lines. So I'm wrong about that one. 🙈
Same for system.menu.*:description! 🙈
Both of these are apparently used in listing UIs and that's why they only allow a single line.

I am right about contact.form.*:message though. And I managed to find one more: field.widget.settings.text_textarea_with_summary:placeholder.

Since there are so few examples: let's fix them here? First pushed failing test coverage, then the fix (i.e. tweaking config schema).

Change looks good and appears all green.

Question though is if changing to text does that mean it can be translated?

Question though is if changing to text does that mean it can be translated?

Both type: label and type: text are translatable already:

# Human readable string that must be plain text and editable with a text field.
label:
  type: string
  label: 'Label'
  translatable: true

…
# Human readable string that can contain multiple lines of text or HTML.
text:
  type: string
  label: 'Text'
  translatable: true

— core.data_types.schema.yml

and:

function config_translation_config_schema_info_alter(&$definitions) {
  $map = [
    'label' => '\Drupal\config_translation\FormElement\Textfield',
    'text' => '\Drupal\config_translation\FormElement\Textarea',
    'date_format' => '\Drupal\config_translation\FormElement\DateFormat',
    'text_format' => '\Drupal\config_translation\FormElement\TextFormat',
    'mapping' => '\Drupal\config_translation\FormElement\ListElement',
    'sequence' => '\Drupal\config_translation\FormElement\ListElement',
    'plural_label' => '\Drupal\config_translation\FormElement\PluralVariants',
  ];

👍😊

Committed b7ee3dc and pushed to 11.x. Thanks!

lauriii → closed merge request !4491

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