Add validation constraints to search.settings

Sadly once again, just like

• book.settings (see #3422862-3: Add validation constraints to book.settings → )
• filter.settings (see 📌 Add validation constraints to filter.settings Fixed and #1932544: Remove all traces of fallback format concept from the (admin) UI → )
• contact.settings (see #3422872-4: Add validation constraints to contact.settings → )

this simple config violates the basic rule of simple config: that it cannot depend on other config entities. 😬 Fixing that is out of scope here.

Created 🐛 book.settings, contact.settings, filter.settings, search.settings all violate the basic rule of simple config: they cannot have dependencies Active for #4. Pointing to that in the updated \Drupal\Core\Config\Schema\SchemaCheckTrait::$ignoredPropertyPaths.

Now it should be green 🤞

Should a CR be written for the new config type "weight" or is there a centralized location developers can refer to? Know as I'm trying to validate my contrib modules been having difficult time finding the new stuff.

Yes, there will be a CR. But that doesn't mean this is not ready for review! That should just block RTBC.

Know as I'm trying to validate my contrib modules been having difficult time finding the new stuff.

This is a problem for every single scenario where developers are supposed to find which plugins are available for them to use 😞 Best example: the migration system…

Wonder if config inspector could list out all the constraints and types available?

#9: yep, I was thinking the same thing 😄 But on top of that, I think we need something like https://www.drupal.org/files/ConfigSchemaCheatSheet2.0.pdf → or https://www.drupal.org/files/d8_render_pipeline.pdf → but for config schema types. Perhaps … Config Schema Cheat Sheet 3.0? 🤓😄

I used that exact cheat sheet a year ago but so much has been added definitely could use a newer version.

It's actually still accurate, because it doesn't attempt to list all of the available types — it only explains how config schema works and the patterns available to use.

Per #8.

I have a couple of questions but otherwise this looks pretty straightforward to me.

📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed should land first. That already contains the change record for the new type: weight. And it'll make this MR much simpler.

📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed landed

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Indeed, this is now unblocked, and … I like @phenaproxima's pragmatic proposal. Will implement that. It's especially valuable for cases like this, where there's only ever one such config YAML to inspect/understand — for config entities it makes more sense to spend more time optimizing the config schema for clarity.

Will do that in the morning!

No objections here. I, too, appreciate how the default search page will be validated if it's set, and ignored if it's not.

Committed and pushed c9d305c508 to 11.x and b3b5d6abff to 10.3.x. Thanks!

longwave → closed merge request !6936

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