Creating content with a hierarchy

Question

I want to create hierarchical content in Drupal, and I am trying to decide between nodes and terms.

What I want to do

I want to implement books.

Each piece of content may be a book (containing chapters) or a chapter (containing pages) or just a page.

These various pieces of content should be related to each other in a tree (the tree will be stored in a menu).

For nodes, I am thinking of using a single content type that contains an entity reference field (children) to store the hierarchy between books, chapters, and pages.

Why I am not using the book module

The navigation links provided by the book module in Drupal 8/9 do not follow the same design patterns as the rest of core (the navigation is not a block, and it's not a menu). Out of the box, you can't even choose where book navigation is displayed (it is displayed on the node's full view mode only). Since the Book module went from 8.0 to 8.8 with basically no changes, it seems to have survived only by preserving compatibility with Drupal's past. Book doesn't even have enough interest to get its own tag here on Drupal Answers.

Why hierarchical content, not navigation

In addition to being displayed on the website, all this content needs to be formatted for export as an ebook. I have already written working code for this using twig templates and preprocess functions.

Having the hierarchy in the content makes writing the ebook export a lot easier.

Terms vs. nodes

So, I am trying to decide whether to use terms vs. nodes. I already asked a general question about terms vs. nodes for content. The consensus there was "use nodes for content, and terms for organizing the content."

But which should you use if that organizational hierarchy is part of the content?

Answer 1

Here's my examination of the advantages and disadvantages of each type.

Implementing the book as nodes

• An entity reference field children needs to be added to the node content type to store the hierarchical relationship.
• Menus must be created separately that match the hierarchy. Now the hierarchy is stored in two places, in the menu listing the nodes and in the node itself. This duplication of data could be a maintenance issue if people are not careful because now the position must be changed in two places.

Implementing the book as taxonomy terms

• Taxonomy terms have a hierarchical relationship by default.
• A menu can be created automatically based on a vocabulary with modules like Taxonomy Menu or Hierarchical Taxonomy Menu.

So if the goal is to have a hierarchical (tree) relationship among content, it seems like terms offer an easier-to-maintain solution than nodes. This is semantically incorrect ("terms" suggests "categories of content," not "content"), but from a technical maintenance standpoint, this way appears easier.