-2

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?

3
  • 1
    IMHO you are misjudging your problem: Reading your question I think you are looking for hierarchical navigation, not for hierarchical content. And when your content is narrow enough that it fits into a website navigation (--> dozens of pages, not thousands), you maybe should just start working and prototyping, instead of overthinking it. Testing is always better then the best theory. – Hudri May 25 '20 at 8:15
  • @Hudri that’s good advice in general but I definitely need hierarchical content. I’ve updated the question. – Patrick Kenny May 25 '20 at 8:19
  • 1
    Taxonomy is the categorization of the content. It doesn't make sense that it would be the content itself. – Jaypan May 25 '20 at 13:38
-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

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.

1
  • 2
    Now the hierarchy is stored in two places, in the menu listing the nodes and in the node itself To prevent replication, use Views or custom code to create the "menu" dynamically, don't create links with Drupal's menu UI. – No Sssweat May 25 '20 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.