Book selection form can load thousands of nodes

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.

Moving to contrib.

I see this is major, and https://www.drupal.org/project/issues/search/book?text=&assigned=&submit... → mentioned being a blocker (and moved to major)... so I'm double checking, is this a blocker also for a full release?

As of right now 📌 Replace book_node_builder with entity fields Active and ✨ Make book child content-type configurable per enabled book content-type Postponed are the only 2 I'd want in before a full release.

Both are very big changes and most likely breaking any contrib that builds on them.

Hm. Good to know. We are trying to decide if we want to move from core to 1.x (which is a full release covered by the security policy, we also need to bring some patches with, but still fails some of our caching tests) or to 2.x (which we don't need the patches for, but might have more changes that need more QA). I'm unsure.

IMHO if you're building a site now it's worth starting with v2 and get used to its (limited) changes, rather than having to deal with it later.

Because of the major shift in 📌 Replace book_node_builder with entity fields Active I'm considering starting a 3.0.x branch

✨ Make book child content-type configurable per enabled book content-type Postponed I would like to land in 2.0.x though and think it's pretty safe if we land the update hook right.

So I started a new branch for the items mentioned in #17 as they could be big changes for contrib. So trying to address the few open bugs and then maybe can do an rc1 release?

I hope I'm not stepping on anyone's toes. I know there are big changes planned, but I really needed this so I began work on it. I have a first draft here (https://git.drupalcode.org/issue/book-3187277/-/tree/3187277-book-select...) and would welcome feedback.

Left comments on MR.

Thanks for the review @smustgrave.

Some of your comments indicate not wanting the new "status" field I added. Here's my thinking on that: the previous select list allowed you to do several things all in that single field:

1. Place the node into an existing book
2. Create a new book
3. Indicate that the node wasn't in a book at all

I struggle to see how we could do that with just an autocomplete. So I added a UI-only radio-button field that only displays in the appropriate circumstances to allow the user those controls. As a result, for the UI to look reasonable I did feel I had to change some of the text a bit, though I suppose we could continue to use the existing strings if you feel very strongly about it (I'm aware of the translation implications).

But maybe you have suggestions on another way to approach this?

Example of what it looks like (the "none" option isn't present here since the node is already in a book):

So the goal of this ticket is something like this which I got from larowlan

if ($count > Settings::get('entity_update_batch_size') {
  $widget['#type'] = 'entity_autocomplete';
}

As for tying the logic to the entity_update_batch_size that's fine. It's not a priority for me, but I get it and am happy to make that change. But when we do switch to the autocomplete widget how do you propose handling the "none" and "new" cases from a UX perspective? I don't see how the autocomplete can handle those. That's why my changes go a bit deeper.