Provide a schema definition for the the layout_option defnitions in drowl_paragraphs_bs_type_layout_slideshow

The layout_options.yml in drowl_paragraphs_bs_type_layout_slideshow should be the only one in drowl_paragraphs_bs.

Another one is located in drowl_layouts_bs: https://git.drupalcode.org/project/drowl_layouts_bs/-/blob/1.x/drowl_lay...

@Grevil: This is the mother issue: 🐛 Fix config schema Fixed

The issue branch here needs a rebase first, contains the old code, be careful!

First off, this issue has nothing to do with a missing schema. Even if we would define a schema here, we still can't set the type of the "options" parameter inside the schema (where these incorrect "false" / "true" strings are coming from).

As we see here:

The options are deliberately strings, as Drupal core doesn't allow us to specify non-string keys inside .yml files:

/var/www/html/web/modules/custom/drowl_paragraphs_bs/modules/drowl_paragraphs_bs_type_layout_slideshow/drowl_paragraphs_bs_type_layout_slideshow.layout_options.yml: Non-string keys are not supported. Quote your evaluable mapping keys instead

Other modules enable / disable a layout option through empty / !empty, for example here: https://git.drupalcode.org/project/ui_suite_dsfr/-/blob/1.0.x/ui_suite_d.... Let us do that instead and fix the default definition while we are at it.

I will provide a minor schema definition issue as a follow-up.

I am just seeing, that we are using global defaults as a fallback... Meaning that this issue isn't fixable... The current implementation is as best as it gets. We can not implement this like in https://git.drupalcode.org/project/ui_suite_dsfr/-/blob/1.0.x/ui_suite_d..., since this way we only have either TRUE or FALSE using !empty(). But we want TRUE / FALSE / NULL (for the global fallback). I don't see any way to fix this. The only thing is, that we create a core issue to let drupal core's "Drupal\Core\Discovery\YamlDiscovery->decode()" method allow non-string keys, as the yml format originally supports that. But, I doubt, that they will do anything about that.

Let's use this issue to create a schema in the future. Setting this to minor, as it doesn't have any big impact on the code rn.

I am just seeing, that we are using global defaults as a fallback... Meaning that this issue isn't fixable... The current implementation is as best as it gets. We can not implement this like in https://git.drupalcode.org/project/ui_suite_dsfr/-/blob/1.0.x/ui_suite_d..., since this way we only have either TRUE or FALSE using !empty(). But we want TRUE / FALSE / NULL (for the global fallback). I don't see any way to fix this. The only thing is, that we create a core issue to let drupal core's "Drupal\Core\Discovery\YamlDiscovery->decode()" method allow non-string keys, as the yml format originally supports that. But, I doubt, that they will do anything about that.

Let's use this issue to create a schema in the future. Setting this to minor, as it doesn't have any big impact on the code rn.

This is not easy to define. There seems to be no way to have schema errors to appear. I could try manually defining the schema, but I wouldn't know which layout options needs a schema and which don't.

I already defined a few layout option values through the layout builder of the article content type and created a test article afterward, but config inspector still didn't throw any errors. The tests also don't show any schema error, and I don't really see the point behind defining a schema.yml for another .yml defining layout_options...

Originally, we thought, that the missing schema leads to type errors. But it doesn't. That wasn't the missing schema's fault, but instead the way the layout_options "options" were defined in the layout options yml.

Concluding, I don't really see a reason defining a schema here. There are simply no benefits for a schema definition, and it is just too hard to even show a schema error for these layout options.

Ok, the schema errors appear in our "Vorlage" now. Let's see, if providing a schema will fix 'em.

Alright, we provided a working schema definition in 📌 Add schema.yml for all layout options RTBC . We can use that issue's solution as the groundwork for this issue.

@Grevil: What's left to be done here and how important would you rate this?