Why?

The one problem I noticed with my example above is that is doesn't provide any Back/Forward links. However, a small function placed in Views Tree could return the next or previous item.

Relation could probably be used as well, but I'm not sure how far along it is.

Comments

Dave Reid’s picture

No.

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

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

colan’s picture

Sorry, I must have missed that in the shuffle. Works for me. :)

scroogie’s picture

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

good_man’s picture

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

Can we benefit from chx new project Entity Tree

cweagans’s picture

@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...

good_man’s picture

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.

fuzzy76’s picture

Did anything actually happen on this?

colan’s picture

I think the plan is to go with Tree, but it might be a while before it gets into core.

cweagans’s picture

Huh? Where was that decided?

colan’s picture

I'm not sure it ever was; I'm just trying to read DamZ's mind. ;)

catch’s picture

Version: 8.0.x-dev » 9.x-dev
Issue summary: View changes
Status: Closed (won't fix) » Active

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.

fuzzy76’s picture

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.

dawehner’s picture

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.

catch’s picture

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

catch’s picture

Project: Drupal core » Drupal core ideas
Version: 9.x-dev »
Component: book.module » Idea
fuzzy76’s picture

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.

Bojhan’s picture

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

dawehner’s picture

@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

Bojhan’s picture

I think that makes more sense for sure.

catch’s picture

@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.

yoroy’s picture

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".

catch’s picture

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.

fuzzy76’s picture

@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. :-/

colan’s picture

To extend what was said in #17, we could make the API work similar to the Entity Revisions API, which can be implemented as per Making an entity revisionable. So we'll have an Entity Hierarchy API, with a Making an entity hierarchical doc page instead.

As far as storage goes, we would need to store a parent ID (at least).

catch's blog post is related: The accumulation of technical debt, or how a recently opened critical core bug is 15 years old refers to #2858431: Book storage and UI is not revision aware, changes to drafts leak into live site.