[PP-1] Rewrite book module to use a standard, reusable API for creating hierarchies

No.

As explained, I want to keep this one, and refactor it, Taxonomy, Menu (and possibly Comment) based on a single "Parent entity" hierarchical field.

Damien: Any starting points? I'd be interested.

I'm interested in maintaining book and to keep it in core.

Can we benefit from chx new project Entity Tree

@good_man, book is staying in core, and I think there's already a maintainer (you'd have to check MAINTAINERS.txt to be sure), but your help would certainly be appreciated here: http://drupal.org/project/issues/drupal?text=&status=Open&priorities=All...

Yes I think pwolanin is the maintainer, but it needs a serious refactoring, I'll try to catch with him on IRC to talk about this issue.

Did anything actually happen on this?

Huh? Where was that decided?

We should revisit this for Drupal 9.

#1627676: Display stats on enabled components (e.g. modules included in a project) would certainly help to understand how much real-world use book module gets.

Agreed. No matter how much you simplify and refactor book I would say it is still not a common enough use case to warrant core functionality (and this is coming from someone who works daily on a site that uses book heavily).

What core offers and doesn't offer is still a very weird mix.

When we manage to convert the menu system into a generic tree component, the book module might be a good prove that this tree component is flexible enough for us. Of course this doesn't change the decision whether we want to keep the book module or not, but at least it could be done somehow.

@dawehner that sounds very similar to #2 from 2011 but agreed if we actually did that it'd be a good test case.

OTOH, another way to do this is to implement a general "entity hierarchy" API in core but toss the book-specific interface parts out in contrib land.

@catch @dawehner Is the plan to wait till 2021 before that happens or rip it out before?

@Bojhan
Well nothing will happen before D9, that's for sure :) But yeah maybe deprecate it, point people to some contrib project and then maybe get that into core or so

I think that makes more sense for sure.

@fuzzy76 we already have taxonomy and menu hierarchies in core. Book was refactored in 6.x or 7.x to re-use the menu hierarchy, however that had to be undone at the last minute in 8.x due to routing/menu link changes - so it has its own custom implementation copying the implementation of menu links at the moment.

The feature of having an outliner to manually group a set of content is very useful.
The current ui for it is very much not good. (It sucks)
It sounds like it's carrying around more custom code than it should.

How fair is it to say that the main difference between "book" and "create a menu and add links to your content from there" is getting automatic previous/next links in the case of book? I imagine a menu specific setting to "add prev/next links to content in this menu".

How fair is it to say that the main difference between "book" and "create a menu and add links to your content from there" is getting automatic previous/next links in the case of book? I imagine a menu specific setting to "add prev/next links to content in this menu".

The only other thing I can think of is the ability to start a book outline from the node form - the equivalent would be a 'new menu' option in the menu selector.

@catch re #21, I still think book, menu and taxonomy should use the same entity hierarchy layer. It would simplify all three, and provide an API contrib could use. Unfortunately I don't have free time to donate to the cause. :-/

I was linked here from #2871733: Remove the book content type from the book module and this issue too proves that there are some issues with the implementation of the book module.

Reading though this issue I agree that it would be nice to have some method for having hierarchical content in core. Book, menu and taxonomy would be perfect candidates for such a system and it might even be useful for another weirdness in Drupal: Too many ways to achieve a link to content.

One of the biggest issues I run into when training new team members is that they cannot oversee the menu system. There are menu links created from within entities (nodes, views, panels, etc) and there are manual links to custom urls. All my new team members follow the logical path, structure > menu > main menu > add menu item and they provide the url to their newly created view, while the older team members created the links from within the view. (This caused a lot of trouble with localization in Drupal 7.)

I realize I am going a bit off topic here, but if there were to come a hierarchy API, could we tackle this as well? I would be very happy to see a method where the 'add menu item' would not only offer an url, but something like an entity reference as well (Since Drupal 8 it appears to be possible to reference nodes from the add menu item form). If node, views, panels, etc. would be able to tap into this system, it might even be possible to create and edit the same menu item from multiple places without issues?

Using such a system would also allow the book, menu and taxonomy structure to be built with the same UI. I like #24 very much.

UPDATE, the menu idea has been proposed as stand alone idea here: #2875183: Rework the menu system to be more entity reference based.

Well well, look at this: #2862096: Replace Book module

(via https://www.drupal.org/node/2858431#comment-11995831)

Makes sense, let do that.

When more information surfaces on that approach lets revisit this.

Simply NO! Please don't ever think of removing Book module from the core! The Book module is the reason for which I have abandoned all other content management systems.

Something like this? :-)

I'm interested in this, possibly a good starting point that would benefit a lot of people right away would be converting the list of child pages on book nodes to be a View.

Would anyone be interested in doing this, probably needs a child issue? I might have time to do it in the future if no one else does.

I'm assuming this would be best done as a Block that is just automatically placed in the Content region?

Hi Aaron,

As Colan suggested in #28, we should first focus on some sort of entity hierarchy API. Multiple implementations (including this one) could benefit from that.

@Neograph734 thanks for linking that issue, that make sense

I've taking a few hours to put together some thoughts and a proposal that I think would be a good way forward with minimal effort over on #267855: Provide an entity hierarchy API, as per previous suggestions let's continue discussing over there.

Also changed this to just "Posponed" as that seemed to make more sense, D.o really should have a way for issues to have more contextual postponed status, like linking the issue that caused them to be posponed or providing a reason that shows right at the top as a status message. Oh well guess that's a discussion for another time and place, in any case added that contextual info to this issue's summary.

just to show there is one issue to address before this can be started

D.o really should have a way for issues to have more contextual postponed status, like linking the issue that caused them to be posponed or providing a reason that shows right at the top as a status message.

4 years later, guess I'll settle for the community driven pattern of that we have of [PP-X] in the issue title 😄

Since this issue was opened, book got some refactoring #2100577: Phase 1 - Decouple book module from menu inc - it doesn't change the current status (still need a generic entity hierarchy API to refactor it again on top of) but the starting point is a bit different.

https://www.drupal.org/project/entity_hierarchy is the great candidate to reuse for rewrite book module on more modern code

Wouldn't it make more sense to just remove the book module from core (as was done with the blog module) and let it live on as a contributed module? It hasn't evolved much over the years and it's severely lacking some features (see https://www.drupal.org/project/drupal/issues/3173808 for an example). I'm not suggesting that the API idea is bad, it's just I think it isn't going anywhere fast because the book module is a part of core and we're beholden to that grander workflow/process.

Wouldn't it make more sense to just remove the book module from core (as was done with the blog module) and let it live on as a contributed module? It hasn't evolved much over the years and it's severely lacking some features (see https://www.drupal.org/project/drupal/issues/3173808 for an example).

That's an idea worth considering, after a very short Slack discussion, I've opened #3265493: [Policy] Move book to contrib in Drupal 11 so that there's a space to discuss this further.

I'm not suggesting that the API idea is bad, it's just I think it isn't going anywhere fast because the book module is a part of core and we're beholden to that grander workflow/process.

Even if book is moved to contrib, there's probably still an argument for having this proposed API in Core, since it could be useful for defining arbitrary entity hierarchies in contrib/custom projects, and potentially take some of what the taxonomy module does and turn it into a generic implementation which taxonomy simply uses.

There are some very old core issues where we tried to introduce nested set hierarchy storage, to use for menu, book, taxonomy etc.

https://www.drupal.org/project/entity_hierarchy and https://www.drupal.org/project/nested_set are examples in contrib.

#344019: New implementation for database tree parsing ( taxonomy / comment ) is probably still the most relevant core issue.