Field Inheritance

Introduction

The Field Inheritance module can be considered to be a field-level entity reference alternative. It allows site administrators to inherit any field from any entity into any other entity. 

Data Modelling Concept

The main premise of the Field Inheritance data model is a configuration entity called Field Inheritance. This config entity describes the way that data gets inherited from a source to a destination entity. The entity stores the mappings between entities and their bundles. An editor can select the source entity type and bundle, and select the field to inherit. Then a destination entity type and bundle can be specified. An editor can also choose an inheritance strategy that describes how the data gets inherited.

A field inheritance mapping consists of the following:

• Name - Name and label the inheritance mapping.
• Source Entity Type - What entity type should the data be inherited from?
• Source Entity Bundle - What entity bundle should the data be inherited from, because different bundles can contain different fields?
• Source Field - What field on the bundle should be inherited?
• Destination Entity Type - What entity type should the data be inherited to?
• Destination Entity Bundle - What entity bundle should the data be inherited to, because different bundles can contain different fields?
• (Optional) Destination Field - Depending on how a field is inherited, there are certain strategies that require a field specified on the destination entity bundle too.
• Strategy - How should data be inherited?
• Plugin - What inheritance plugin should be used?

There are four different field inheritance strategies built into field_inheritance.

1. Inherit – a field that is inherited means is taken directly from the source bundle and made available to the destination bundle.
2. Prepend - a field that is prepended means that any contents of a defined destination bundle field is added before the contents of a defined source bundle field.
3. Append - a field that is appended means that any contents of a defined destination bundle field is added after the contents of a defined source bundle field.
4. Fallback - a field that is configured to be a fallback field will show the contents of a defined destination bundle field if set, otherwise it will show the contents of the defined source bundle field.

Hooks, extensibility and APIs

The field_inheritance module exposes its own hooks to use to modify core functionality. These hooks are defined in field_inheritance.api.php. Custom modules can be written to modify, or enhance the core functionality of field_inheritance by making use of these hooks.

The field_inheritance module has a number of FieldInheritance plugins written to handle core fields, and custom plugins can be created providing they implement the FieldInheritance annotation and extend the FieldInheritancePluginBase class. The core plugins are defined in src/Plugin/FieldInheritance. In order for a FieldInheritance plugin to be available for a particular field type, that field type will either need to be explicitly defined in the types annotation, or the value any should be specified, for an example see DefaultFieldInheritancePlugin​​​​​​.

Similar Modules

The closest comparison would be the entity_reference module, which adds a way of referencing other entities. However, there is no simple way to pull in a specific field's data from the referenced entity. In a way, field_inheritance is more of an extension of entity_reference rather than an alternative to it.

Example Use Cases

• The recurring_events module makes heavy use of the field_inheritance module to inherit data from a parent (wrapper) event series down to the instances of that recurring event. For example, the title of the event series is inherited down to the instances, so all instances share the same title, and updates to the event series title cascade automatically to all the instances.
• A corporate site has a node type named employee and each employee can work in a specific branch or location of the company. On the employee biography pages on the site, the site administrators want to display a map of the location of that employee. All the address and geolocation data are stored against in the location node, not the employee content-type. Quite simply, a field inheritance could be created where the source entity is node, the source bundle would be location and the source field would be the geolocation field. Then the destination entity would also be node but the destination bundle would be employee. Then an editor could see the display formatter of the inherited field to use the map display, and then the map will be displayed on the employee page.