Make book child content-type configurable per enabled book content-type

This extension is being deprecated, see 🌱 [Meta] Tasks to deprecate Book module Active . It will be removed from core and moved to a contrib project, 📌 [11.x] [Meta] Tasks to remove Book Active .

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project → and the Extensions approved for removal → policies.

This issue may be re-opened if it can be considered critical → , If unsure, re-open the issue and ask in a comment.

Oof, i feel issues should not be postponed/closed until they can be moved along with the core extension when it is moved to a contrib module.

Really, all core Drupal modules should be brought in by composer, so there is not this traumatic phase while a module is being moved to contrib (or from contrib). It should be easy to fork — or branch — a core module same as a contrib one (keep development in the same namespace but swappable).

Anyhow this patch works (you may get errors trying to print Add child page links until you save the new configuration for the first time) and i hope contributors here will put in to be maintainers of the book-in-contrib to be! (Also on that, #1261130 is a very interesting direction.)

Patch for Drupal 10.2.x but doesn't use the Config Target API that was recently changed.

Missed a file

Patch for Drupal 10.2.x but doesn't use the Config Target API that was recently changed.

Marking this as a must for a stable 2.0.x release.

This is an essential request for my organization. We have been using this for years and would appreciate the merge!

Been trying to to carve out time for months but actually needs a good amount of work still. Example the configuration structure approach doesn’t seem ideal

Thank you for all that you are doing!!

So believe trying to get to a structure like

allowed_types:
book:
child_type:
- article
- page

This opens it up that maybe in the future we can have multiple children. But need to verify this all can be validated in config.

I have put code based on the patch in #26 into the merge request and made some additional fixes. There are still schema errors and an undefined variable $current_value. I don't have more time to look at this right now.

Still on my list but not 100% sure that’s fully the path we wanted to go. So may revert some stuff, no worries though

smustgrave → closed merge request !81

smustgrave → changed the visibility of the branch 2.0.x to hidden.

smustgrave → changed the visibility of the branch 3.0.x to hidden.

Ready for a round of reviews.

Added the update hook so this should be ready

Would you consider a backport to 2.0.x?

(By the way, I noticed that tag 3.0.0-alpha1 is not on a branch. You could clean that up by merging it into 3.0.x.)

No this is too big a change to me to backport to 2.0.x this could easily break other modules that build on it.

I’m also anticipating bugs from this change eventually so want to have 2.0.x as a fallback for people.