Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem
- To define the bundles of an entity type, the raw configuration of another (config) entity type has to be read in manually (since ConfigEntity objects cannot be loaded within hook_entity_info()).
Goal
- Allow one entity type to act as "bundle service/factory" for another entity type.
Details
- To define the bundles of an entity type, we don't need the actual entities, the raw config is sufficient.
- That's no difference to how entity types are defined today -- taxonomy_entity_info() queries the raw vocabulary data from the database. The difference with config entities is just a different storage.
- Eventually, we should investigate whether bundles need to be defined at all, when there's a notion of ConfigEntity objects. The entity system could just simply take a reference to another entity type and retrieve the bundles when actually needed.
- ...which in turn gets us to a true Bundle API.
Proposed solution
-
function node_entity_info() { $types['node_type'] = array( //... ); $types['node'] = array( //... 'bundles' => 'node_type', //... ); return $types; }
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedSeems like a useful shorthand to me.
Comment #2
andypostIs not it a duplicate of #1763974: Convert entity type info into plugins we could use discovery methods to define this relation which probably needed for #1801304: Add Entity reference field
Also I'd like to pay attention on #1803630: Rename entity bundles to avoid confusion
Comment #3
andypostshortcut module could point to menu-links with this? does it makes sense?
Comment #4
fubhy CreditAttribution: fubhy commentedI am not sure if that is enough. The bundles of an entity type might be computed bundles without a UI or any other means to create them manually. Anyways, referencing a different entity type is a good idea. But it should not entirely replace the current behavior. That would be a regression.
I like the overall proposal though.
Comment #5
sunComputed bundles? I don't quite see how that would work. Isn't it that Field API + Co need a reliable, static definition of bundles, because they are attaching stored data to them and have to maintain that? If a bundle could come and go and vanish at any time, then there's no way to maintain the attached data.
I think the proper answer to that needs to be that if someone has computed bundles, then those bundles need to be properly created/updated/deleted through the corresponding API.
Comment #6
fubhy CreditAttribution: fubhy commented@sun By computed bundle I mean hard-coded, static bundles that may be defined by a module. Not dynamically computed ones. Think about the anonymous user api issue. At some point someone proposed to have a 'registered user' vs. 'anonymous user' bundle for user entities. Those two would be static, without a config entity behind them.
Comment #7
yched CreditAttribution: yched commentedNote : in #1822458-1: Move dynamic parts (view modes, bundles) out of entity_info() I propose to move the list of bundles out of hook_entity_info() and into a separate method in the entity class.
Also, we do need a crud cycle on bundles - at least, some notifications that a bundle is being created / renamed / deleted. That's currently done by the entity type manually calling field_attach_create_bundle() (that in turn invokes the associated hook), but should move out of Field API into Entity API.
Comment #8
fago+1 for doing so. It's what I've done in entity.module for d7 also, and seems to be sane to me. Having a proper API for bundle objects also makes it a big plus.
The only thing we need to make sure is that a bundle type can act as bundle for multiple entity types. Use case: node types are bundles for comments and nodes.
Then create a new entity type and provide the default config, where's the problem? It seems overkill in the first place, where is the problem or weight it adds? The only weight it adds is yet another entity type, but we get something for it: a proper bundle API that works consistently for all entity types.
Exactly. And we've an API for CRUD: the entity api + notifications built in.
Comment #9
wundo CreditAttribution: wundo commented@fago, I don't really understand why one bundle type would need to act as a bundle for multiple entity types, could you elaborate?
Comment #10
BerdirThis is all possible now and is used for all core entity types except tests using bundle_of/bundle_entity_type annotations.