The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Instead of recreating node.module's 'Content type editing UI' for each extensible module's entity types, a reusable UI for managing entity types and sub-types would provide users and developers the ability to leverage all of the entity system's features in a familar way.
Related issues:
Comments
Comment #1
OnkelTem commentedAlso, I believe bundles are not needed at all.
What we really need is categorization and sub-entities, each one is fieldable of course.
Demonstration picture of categorization relationship:
Also see the discussion in ECK's issue queue: #1791230: Hierarchy behavior and FKs
Comment #2
tim.plunkettMost things so far that have UIs are config, or are moving to config. The more complex stuff is moving to ConfigEntity.
Entity types are plugins, not config, and I'm not sure how we'd write those to disk on the fly.
Comment #3
bojanz commentedThis issue is a big unclear, but seems to me that it's proposing a generic bundle management UI?
Comment #4
fmizzell commentedThis would be, in great part, what eck does, but a fully implemented entity type is more than just the plugin (info). So if this was to go into core we would need a way to define an entity types' db schema, and the properties (fields) metadata from the UI also, otherwise, a "management" UI for entity types would only display the entity types that already exist, and that hardly corresponds to management.
@bojanz I believe this isssue is related to entity types, and if it is decided that this is worth pursuing for D8, then a generic bundle management UI, will go with it.
@tim.plunkett If I understand plugins correctly, plugins are simply a way to define discoverable types of stuff, but, where a plugin's definition comes from does not matter. So we could easily be generating plugin definitions from a config object (this we can write to disk, right!?). Actually, if this is not possible after all the work that you have done to move entity types to plugins, it would greatly harm eck being moved to D8. I guess I need to pay more attention to your work over there :)
Comment #5
OnkelTem commentedWell, I'm not familiar much with D8 yet, so my messages may sound senseless, sorry for that (don't want to distract anyone working on D8).
I think Mitchell is talking about some generic UI for managing custom entities and bundles (so, @bojanz - yes), similar to what ECK module provides. And there is no need for specific "node" stuff, since this is a particular case of more common task.
As for my post - you may just skip it. It's about a data model, when any sub-types share same parent's primary key. This allows to
build categorization relationship. For example:
Parent entity: Content
Child entities: Article, Page
Child entities of Article: News, Blogpost
The advantage of this, is that Blog post entity, apart from having its own fields, has all parent's fields. A query schema will look like:
SELECT * from Content INNER JOIN Article INNER JOIN News.
Having pretty good background in database design, I personally really lack such things.
Comment #6
mitchell commented@bojanz: Similar to ECK, it's both for entity sub-types (bundles) and entity types. Separate but tightly integrated with this bundle management UI is field_ui, so that would be addressed in #1472348: Fields UI improvements using form builder pattern / #1515688: Redesign the Field UI. I think the biggest part that I haven't clarified is how relationships of entity types & sub-types (for hierarchies, inheritance, mixins, etc) would be represented in this "Entity Type UI".
@tim.plunkett & @fmizzell: I'll try to get some info about how the block / layout plugin UI is used to create plugins / plugin derivatives. I'm not clear on this works yet, but I think it's a close match to how this UI would be built and would generally take over the function of
core/modules/node/content_types.inc. If entity type plugins' schemas need to be created as files and not derivatives in the database, then would drupal_php_storage() make sense to use?@OnkelTem: I added links to the related issues about sub-types to the summary. Behaviors is another interesting aspect of this improvement, and fmizzell was just explaining something very cool in relation to this issue (more to follow); see also: #1803064: Horizontal extensibility of Fields: introduce the concept of behavior plugins and #1819256: Entity behaviors, bundle behaviors, bundle options. Thanks for the example in #5; it's an effective demonstration of hierarchical field inheritance. Do you have a mockup for a UI too? :-)
Also, if it's possible, please include the source file to your diagram so we can modify/extend it.
Comment #7
tstoecklerComment #7.0
tstoecklerAdded issues about sub-types
Comment #8
klonos@tstoeckler: we now have a dedicated section for related issues in the new issue edit form ;)
...getting used to using it and advocating its use in general is really important if we want to have actual two-way relations between issues. In other words, adding related issues in the issue summary adds them only there, while adding them in the "Issue relations" section adds them as actual meta-data to both the issue the are added from as well as to the linked issue(s). Also see:
#44162: Relationships between issues: support for parent issue and related issues
#1975806: Provide a way to represent the relationships between issues in a tree list format.
Comment #9
catchI think this is handled by list builders and #2089757: Auto generate routing entries for entities based on an 'admin_path' and 'admin_permission' annotation, marking 'by design'.