The Needs Review Queue Bot โ tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide โ to find step-by-step guides for working with issues.
- Status changed to Postponed: needs info
over 1 year ago 7:55pm 11 May 2023 - ๐บ๐ธUnited States bnjmnm Ann Arbor, MI
I think this was a really good suggestion in 2011 when Drupal was less mature. This kind of improvement could happen on a major release and it would be a natural part of the upgrade adjustment process.
Given that Drupal has switched to Semver and there's been 12 additional years of "bundles" since this issue was filed, I think this needs to be postponed to and do a >= 2023 feasibility + pros/cons assessment before any additional efforts take place. I suspect there would be no shortage of justification as to why such a change would be nice to have, but there are other things to consider :
- there are ~250 core methods that have "bundle" in their name - is it worth either introducing dissonance between the function names and human-label-names (or would it be worth renaming all of those which would require deprecation paths?)
- Does anyone have the stamina to review modifications the ~10000 other uses of "bundle" in core?
- How much documentation and contrib use will now be inaccurate due to the change?
- It is worth the disconnect as existing sites will have "bundle" DB columns for every field ?
Any issue that's been open for this long should probably get a can-we/should-we assessment every 5 years or so.
- ๐ซ๐ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin
One aspect here is that we actually try to avoid bundle or subtype whenever possible. Just like the word "entity". Whenever possible, we want to talk about the specific case of subtypes/bundles. Node types, vocabularies, content block types, ... Only in very generic cases we use the word bundle in the UI. And many of the ones that still are using bundle are actually bugs and the code should be improved to display a better label.
I would like to make a suggestion that might be more linguistically appropriate and ultimately understood. Also in the rest of the world. What about:
Entity type variant (instead of bundle)
- ๐ซ๐ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin
Which of course does not want to undermine the well lay out and very reasonable thoughts @bnjmnm added to such a big change (I didn't know that this term is spread so much already) and which I fully agree with. It came just from a newer discussion where it popped up again that bundle seem to be chosen very unfortunate.
- ๐ฌ๐งUnited Kingdom catch
On top of #247 I can't think of any places where we use 'bundle' in the UI. Generally when you're dealing with 'bundles', you're dealing with something on the entity type itself, so node 'types', taxonomy 'vocabularies' and in those contexts there's no need to say 'bundle'. If there are places we use it in core interfaces or help text, a separate ticket to remove/replace those usages would be good.
That would then make this a DX issue only, not a UX/product one.
- ๐ซ๐ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin
Yeah, as I sad in #250 in other words: To change something spread like this and which is so opinionated somewhere else than in UI could become a true worm whole. As long as it is on a level where you know what you do like dealing with custom entities etc there is no need to know about that term before. Like your examples has shown very well @catch.
For reference - The docs solved it in this way. https://www.drupal.org/docs/drupal-apis/entity-api/bundles โ
- ๐ซ๐ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin
One problem in the whole discussion seems to be (and turned out on Slack again) that one concern seem to be: unless you know Drupal, you canโt hope to know which one comes first. I think this is why sub-type (like in the link above) has been introduced in descriptions and help texts.
Problem is that we mix sometimes the way we use it in short and on which level. Even in the discussion on Slack while thinking about it. It is not like Entity type & Entity variant. Then I would agree regarding a level issue. It is Entity type and Entity type variant what I have suggested. Or in short: An Entity and its variants. Same in Page manager. A variant of a page. It is not Page type and Page variant. It is Page and Page variant in short. Or Page type and Page type variant in long. Type is just an additional word to Page saying that there other types too. But Page would be actually enough. Same with Entity.
That's why it is actually wrong to say Node bundle type. My fault in the other thread. ;-) It rather should be Entity type bundle or Node bundle since Node already refers to (replaces) Entity type.
- ๐ซ๐ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin
Again, sorry for the noise and coming from the bottom up with my thoughts in 249/253, which 70% cover what has been already discussed. But it has some useful additions in it worth reading and I would like to explicitly go with the well layout thoughts in #247 and #251 forward and would REALLY like to see any final tendency here. Could we try to finally give this issue a direction and a go? 1.) If we keep on scratching the surface and create 2 terms for the same thing or 2.) if we change it drastically under the hood.
And I can't repeat enough how much I agree with the list of worries pointed in #247. But again, I am not sure if the massive work described in there not also would go for the confusion and issues created by having 2 terms for the same thing? From a developers perspective it would surely be the previous work mentioned. But from people's perspective who help on the docs and for users and contributors who try to understand Drupal and humble over things like ::bundle(type) or ->getBundleInfo() and need explicit code comments declaring that this refers to what we call sub-type in UI, can become a massive work too - to get all this "bridged", commented and explained.
But as I sad before in previous comments: On the other hand we have Entity type Node and call it "Content type" and over the years it became a known Drupalizm, which has not caused that much confusion as maybe someone would expect. So my worries are maybe a little bit "over-do".
Another option would be to leave bundle as it is :-) like Node. And revert all docs to bundle? NO. That would be also massive work. There a surely good reasons for why this issue kept being open for so long... But I think we should make a shot one day. In one or the other direction.
Maybe we should go with #251 and break the back'nforth loop here. And there is a way how it can be "mixed" (to prevent all the massive work options discussed): What we do in our offices in all our docs and help texts is that we started to use both over the time and so it was not a big issue of work in one shot but a sliding change with bridging info to both terms. The way we do it is to put always the one in Parentheses which is not in focus. So on code level we say node (Content type) and on UI we say Content type (node). This way Drupalizms get repeatably remembered. So it could be Entity sub-type (bundle) in docs and bundle (entity sub-type) in code. And this could be a soft introducing change and not a time limited task since such changes are no release blockers.