Hi,

as a result of a long-going and controverse discussion about integrating the "XML Sitemap" moule into Core I'm requesting a new feature that IMHO is desperately needed:

* An abstract mechanism that can handle hierarchical (as provided by the menu or the book mechanism) and non hierarchical relations between nodes (as provided by by taxonomy and several contributed modules), and offer this knowledge to contributed modules through an API.
* This mechanism could integrate the menu and book modules from Core, and provide structural data to modules like "XML sitemap", "Site map", "Site Menu", etc.

It would be the goal of something like a "structure.module" to manage and maintain the different kinds of relations between nodes. If the relations are hierarchical, they could be offered to something like "book.module" that handles displaying the structure to users. It's not a subset of taxonomy since those relations would have to be more low-level and include *all* content a Drupal site consists of so that a moule like "XML Sitemap" could be based on. Since I don't think that something like "XML sitemap" should get into core, even if many users are requesting this, I'm sure that an abstraction layer in core that collects and provides structural data about a site's contents and it's node's relations would be of great help for all of us.

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:

* Simple Sitemap, http://drupal.org/project/simplesitemap
* Node Relativity, http://drupal.org/project/relativity
* Related Links, http://drupal.org/project/relatedlinks
* Site map, http://drupal.org/project/site_map
* Node Hierarchy, http://drupal.org/project/nodehierarchy

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 a s 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

Comments

jscheel’s picture

I wonder if the push for getting RDF into D7 would help with this. Honestly, I don't even know if that is going to happen anymore, I've been out of the loop for a while...

Well, subscribing anyways.

mdupont’s picture

Version: 7.x-dev » 8.x-dev

I guess the most promising work in this direction currently is Relation module.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

colan’s picture

Title: Abstraction layer plus API for structural knowledge about a site's content in Core (book, menu, relativity and sitemap modules) » Provide an entity hierarchy API
Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: other » Idea
Category: Feature request » Plan

I've reviving this based on the discussion we've been having in #1261130: Rewrite book module to use a standard, reusable API for creating hierarchies.

It makes perfect sense for use by Menu, Taxonomy, and Book. The Book module could be kicked into Contrib or not (separate issue), but either way, it would use the API.

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

This would help a certain class of issues that have been popping up:

There's an Entity Reference Hierarchy module that may serve as a useful model. It already has a #2862096: Replace Book module issue.