Entity Reference Hierarchy

Overview Entity hierarchy extends the standard Entity Reference field to store a nested set representation of the the hierarchy.

This allows for efficient querying of the hierarchy.

Features
* Integrates with views
* Render a list of children at any depth using views
* Integrates with Workbench access to provide section hierarchy (via sub-module)
* Custom breadcrumb builder (via sub-module)
* Provides ability to create Domain style microsites (via sub-module)
* Rather than re-implementnig a bespoke new site, Microsites are perfect to replace subsites where:
* A subsite can be represented by a hierarchy
* A subsite is primarily to segregate control / user access
* Subsite may want to be on its own domain, or a subdirectory of primary.
* Non-content based features and functionality will also be global, along with a shared library of common entities/assets/users/roles/features etc.
* The boundary between each site is really low
* Really good for some folks, not the best choice for others



Usage advice Deciding when to use an 'entity reference with hierarchy' field instead of a normal 'entity reference' is a key consideration when using this module.

Typically the decision point comes down to whether order is important or not

Content-types that you want to be a hierarchy for the sake of the Information Architecture (IA) but where the order of children doesn't matter, probably should use a normal entity reference field. E.g an Event content type would typically be ordered by event date. A news-item content-type would typically be ordered by the publication date. In most instances, you should use a normal entity reference field here. If you need to present this content in a hierarchy, you can always have the parent node in the hierarchy and work through a tree from there. The only exception to this rule is if you're using the microsites sub-module and you want these items to appear as though they're part of the sub-site.

Content-types where the order of children is important (e.g. in listing components on the parent) should use an entity reference hierarchy field

Requirements
* The previousnext/nested-set composer library.
* The dbal module.

Known problems Please use the issue queue to report issues. If you find your tree is out of whack, rebuild the whole thing if needed using drush entity-hierarchy-rebuild-tree field_parents node where field_parents is the field name and node is the entity type the field lives on. Given the tree is only a representation of the hierarchy, and the canonical source is the entity field values, this rebuilds the tree representation without touching the original values.

Future Improvements A planned improvement is a formatter that allows children to display a parent or grandparent, of arbitrary depth.

An extremely simple example of this sort of inheritance would be a section title and banner. You may have a website that uses the same section title/banner across several pages, so it would be desirable in this instance to only need to edit the information in one place (e.g. the great great grandparent).

Installation This module has composer dependencies and must be installed by composer

composer require "drupal/entity_hierarchy" Determine what entity type you want to have in your hierarchy. Visit the child bundle and add a new field of type Entity reference hierarchy. This will form the reference to the parent. Configure this as a single value field and give it the ability to reference the bundles that can be its parent. Repeat this for any other content-types that can live in the hierarchy.

Create some content and nominate the parent as appropriate.

Create a view and use the 'is child of' argument to filter down to the appropriate children and depth.