Contrib.social

Add "OO" bundle inheritance features

Open on Drupal.org →
Created on 2 December 2006, over 18 years ago
Updated 28 May 2025, 2 months ago

Problem/Motivation

Drupal provides no way to model hierarchical bundle relationships, making it tedious and error prone to build many content types with significant field reuse, and making it difficult to reuse code on the business and display layers. In practice, content is often related in the way classes are related in object-oriented programming. Consider the following (contrived and over-simplified) example of a sports website with pages for teams and players.

There is a category of content types for players with similarities and differences: they both need identical name and photo fields, they both need a team reference field but each should be configured differently (e.g., a football player should only be able to reference a football team), and each needs something the other doesn't (a sport-specific statistic). Given Drupal's current content modeling tools, this would require two player content types and two team content types with ad hoc field reuse, separate templates for all of them, and no intrinsic knowledge of the fact that any of these things are variants of others.

Proposed resolution

  1. Add the concept of bundle inheritance with the ability to add default fields and settings on a parent whose children can override their settings and add other fields to them as well as have their own form display and display configurations.
  2. Add the concept of an "abstract" bundle (or an interface or a generic or what-have-you) that never has entity instances (e.g., Sports player in the example above).
  3. Add support Views filters and entity references field constraints (among other things) (e.g., such that you could filter a View to anything that "is a" Sports player and get back both Baseball players and Football players--and Soccer players would come back to, if they were added to the hierarchy later, without having to modify the View).
  4. Add the ability to determine in code an entity's place in the hierarchy (e.g., being able to ask whether a Baseball player entity "is a" Sports player).
  5. Add hooks and template suggestions that allow for code reuse at the new semantic level.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

✨ Feature request
Status

Active

Version

11.0 🔥

Component

entity system

Created by

🇨🇦Canada combolog

Live updates comments and jobs are added and updated live.
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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024