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.
The notion of "entity bundle" is currently baked in Entity / EntityInterface.
But I don't see a case for config entities to have different "bundles", at least 99% of them don't. Moreover, many of them store things about a specific (content entity) bundle, and thus include a 'bundle' property, which is different from "their own bundle", and thus has to be disambiguated (targetBundle() or something).
Now that we have ContentEntityBase & ContentEntityInterface, why don't we limit the notion of bundles to content entities ?
Comments
Comment #1
yched CreditAttribution: yched commentedComment #2
BerdirI think we discussed this, and I don't remember all the reasons but there were some use cases where a general subtype/bundle concept is useful for config entities too.. to store settings per bundle and something like. Maybe config translation was one thing?
Was a long time ago in Portland where this discussion AFAIK happened. Maybe @timplunkett/@fago remember more, see also the first few comments in the other issue.
Comment #3
yched CreditAttribution: yched commentedHm, yes, that was originally in the scope of #2004244: Move entity revision, content translation, validation and field methods to ContentEntityInterface, but the reasoning was "we don't know, let's keep it" and it was dropped.
Dunno, the actual use cases beat me, looks like uneeded confusion to me...
Comment #4
tstoecklerI totally agree with this.
This is obvious, but still pointing it out for completeness: Any ConfigEntity that does want bundles, can still enforce a bundle on its MyConfigEntityInterface.
ConfigEntityInterface is just for the things that 80% of the config entities have in common. And in core there are no config entities, for which bundles make sense, as far as I'm aware, so IMO it's hard to argue this is an 80% use-case.