[PP-2] Add validation constraints to book.settings

Just like filter.settings before it (see 📌 Add validation constraints to filter.settings Fixed and #1932544: Remove all traces of fallback format concept from the (admin) UI → ), 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.

But we can proceed here, thanks to \Drupal\Core\Config\Schema\SchemaCheckTrait::$ignoredPropertyPaths 👍

This MR copied the ExistsIn constraint that I wrote yesterday for 📌 Add config validation for workflow entities. Active . That should have its own issue, but that doesn't mean this cannot already be reviewed.

Asked in #needs-review-queue-initative but since book is deprecated we have postponed all issues for it. What do you think about breaking this apart? Open a new ticket for adding the new constraint and postpone this to have book update in contrib

Don't feel strongly about it either way. But was definitely going to create a new issue for ExistsIn anyway 👍

So I asked @catch and doesn't see this as an issue even though book is deprecated.

Left some comments on the MR>

Rerolled.

We may want to block this on ✨ [PP-1] Enum cases stored in config Postponed .

Needs feedback on how to proceed.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. 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.

So do want to mention that book is deprecated and we are trying to do a sub tree split and kinda falls back to what the process is going to be. If we are going to continue with pushing fixes to deprecated modules are we going to have and sub tree split every time?

So I see the concern around core/modules/book/config/schema/book.schema.yml and maintaining that list. For this particular instance I think it's a none problem as book is deprecated and being removed so I don't think it will be a problem for core. I'm going to be helping co-maintain book with @pwolanin and I don't mind maintaining this in contrib.

That may not help answer the question on what core should do for things that are remaining.

So in this instance change LGTM, will leave in review for a few more days for additional eyes.

Actually since this is a blocker for book subtree split going to mark now, hope that's okay!

We've not really resolved the threads on the MR yet. Why is this a blocker for the sub tree split?

Why is this a blocker for the sub tree split?

I'd love to understand this too.

Tagged ya both in the thread in #d11readiness. Guess I shouldn't say blocker but more advised to wait to avoid doing multiple subtree splits

So is the open question if this should be postponed on ✨ [PP-1] Enum cases stored in config Postponed

+1

📌 Deprecate Book module Postponed happened, so these settings will be gone in Drupal 11.

Moving to https://www.drupal.org/project/book → .

So I think I'm going to remove the required part of the settings for book. Part of removing the default book content type and moving it to a recipe means those keys could be empty.

tried that validation constraint patch, doesn't help

The only way I can get through this form is patch #2 from
🐛 "child_type_BUNDLE" is not a supported key Needs review

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