Provide an entity hierarchy API

Created on 7 June 2008, about 17 years ago
Updated 28 May 2025, about 1 month ago

This originally came from a discussion [years ago] on this issue #252846: Add XML Sitemap to Core , the original discussion on that issue no longer seems to be relevant but the ideas it spawned here are. Those relevant ideas are:

  • An abstract mechanism that can handle both hierarchical (such as the menu and the book mechanisms) and non hierarchical relations between nodes (such as taxonomy and several contributed modules), and offer this knowledge to contributed modules through an API.
  • This new mechanism could handle the relationships that the menu and book Core Modules require, and provide structural data to modules like XML sitemap , Sitemap , etc.

It would be the goal of something like a "structure.module" or "relationships.module" to manage and maintain the different kinds of relations between Entities (mainly Nodes). If the relations are hierarchical, they could be offered to something like "book.module" that handles displaying the structure to users.

This new mechanism would not be a subset of Menu, Taxonomy, Books or another Core Module since this API and the relations it establishes would have to be more low-level and not specific to one modules data structure or workflow, as well as providing the ability to *all* content a Drupal site consists of so that moules like Menu, Taxonomy and Books could be based on this API.

The Problem

Drupal Core does not know much about the relations of content in a Drupal site; some "connections" are created through taxonomy, others through the menu and book modules. Also, there is a plethora of contributed modules trying to add this information about parent-child-relations, etc.. All those modules try to solve similar problems and to generate similar data, thus multiplying the effort to maintain this knowledge about a site's structure. Additionally, most of those approaches do not make good use of data already available in other modules. When building a site, this can lead to unnecessary complex site structures with different navigation themes, different hierarchies, performance issues, etc. We all know these problems. That's the reason, why a solution in Core is needed.

Similar Approaches

Many contributed modules try to add knowlede about a Site to Drupal; some examples:

There are many more modules with similar requirements.

These modules have completely different goals, and different "targets":

  • "Simple Sitemap" and "XML Sitemap" are targeted to machines like search engines; they generated internal representations of a website's structure, but don't offer this to the site's human users
  • "Site map" and "Site menu" are targeted to end users; they build a visual representation about a site and provide a page with links, that a user can click
  • The core "Book" and "Menu" modules provide tools to edit relations between nodes, and/or to represent them in form of a table of contents page, or a menu.
  • Modules like "Node Hierarchy" or "Node Relativity" mostly help creating relations between nodes but don't display them to end users; also, they don't provide their data to other tools like "XML sitemap"
  • Modules like "Node Relativity" allows to create parent-child relationships, similar to the book mechanism, but don't integrate well to other structural tools.

Why does this need to be in Core and not in a contributed module?

IMHO it's as simple as this: Drupal is a framework offering an infrastructure to build intelligent websites. Knowledge about structural relations between nodes is such an infrastructure.

  • Harvesting a site for node's relations creates severe performance issues, especially on large sites; every contributed module has to find a solution on it's own. The developers of the "XML sitemap" module solved a lot of these issues during the last months, otheres like "Site Map" or "Site Menu" didn't; knowlegde in Core about a site's structure would provide the data to contributed modules, making a Drupal site perform better and reduce overhead;
  • Drupal Core already has mechanisms to manage hierarchical relations between nodes (book, and menu modules); but it can't handle non-hierarchical relations, and both modules should be integrated on a more abstract basis.
  • Contributed modules could concentrate fully on their specific goals (e.g. providing a XML sitemap to search engines, or provide a human-readable sitemap to users, or provide navigational menues, etc.)

I'm searching for quite some time for solutions to the described problems; so far, I only discovered approaches targeting parts of it. This feature request is intended to

  • either start a discussion about getting structural knowledge about a site's content into core,
  • or to point to already existing discussions about this topic if I missed those.

[Thanks & Greetings, -asb]

Feature request
Status

Active

Version

11.0 🔥

Component

entity system

Created by

🇩🇪Germany asb

Live updates comments and jobs are added and updated live.
  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇳🇿New Zealand quietone

    The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Production build 0.71.5 2024