When a new term is added through the widget it lands at the top of the vocabulary. Being able to save the term lineage, so a new term is created under a chosen parent, would keep the vocabulary ordered.
A widget setting naming the parent term for auto created terms, applied where the term is created. Showing the hierarchy in the suggestions is #3240897: Add Display Term Parent Hierarchy.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3104486-2-term-parent.png | 89.01 KB | rajab natshah |
| #7 | 3104486-1-setting.png | 190.47 KB | rajab natshah |
| #6 | 3104486-term-under-parent.png | 114.26 KB | rajab natshah |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
rajab natshahComment #3
rajab natshahThank you, Martijn for asking.
Scoped it to what the widget can own: a setting naming the parent that auto created terms go under. Showing the existing hierarchy in the suggestion list is #3240897: Add Display Term Parent Hierarchy. Leaving it active, open for a merge request.
Comment #5
rajab natshahI have opened a merge request against 2.1.x and the pipeline is green.
There is a new widget setting, Parent of a new term, empty by default and only shown on a taxonomy field, since a vocabulary is the only thing here that has a hierarchy at all. A term the widget creates is filed under that parent instead of landing at the top of the vocabulary.
Drupal builds an automatically created term with no parent, and by the time the widget sees it the term already exists as an unsaved entity. So the chosen parent is carried along with the element and set on the term in a validate step that runs after Drupal's own, which is the first moment the term is actually there to change.
It is deliberately careful about what it does not touch. A term that was already saved is never moved. A parent that something else has already set is left alone. And with the setting empty nothing happens at all.
There is one trap in here that cost me some time, and it is worth knowing if you review this. A taxonomy term carries a parent of
0to mean "top of the vocabulary", so the parent field is never genuinely empty and anisEmpty()check quietly skips every single term. Only a parent that actually points at another term counts as one already given. The kernel test fails with "0 is identical to 1" if that check is put back, so the mistake cannot creep in again unnoticed.On Drupal 11.4.5 a new term created with the setting on lands under the chosen parent, and with the setting empty it stays at the top. Terms picked from the suggestion list are untouched either way.
It is covered by a kernel test with four cases. I drove the element directly rather than through a browser because the setting stores a term ID, and the browser suite deliberately keeps term IDs out of its fixtures.
Prepared with AI assistance (Claude), reviewed and driven by the maintainer.
Comment #6
rajab natshahRebased onto the current branch and retested on a clean Drupal 11.4.5 site with realistic content: a Topics vocabulary of fifteen editorial subjects, with "Uncategorised" named as the parent for anything an editor invents.
Typing a topic that does not exist and committing it files the new term under that parent, while every existing term stays where it was.
With the setting left empty a new term stays at the top of the vocabulary, and terms picked from the suggestions are never touched either way. All fourteen PHP tests pass against the rebased code.
Two things came out of the rebase worth mentioning. The widget now takes the entity type manager as a required argument, following the approach taken in #3112680, so the optional fallback I had here is gone and the two agree. And the commit that only existed to quieten phpstan about that fallback is dropped, since there is no longer a fallback to quieten.
Comment #7
rajab natshahTested this again more thoroughly, because one screenshot of a vocabulary listing did not really show what the feature does. Three images this time, following the whole path.
One. The setting itself. It sits with the other widget settings on manage form display, and only appears for a taxonomy field.
Two. Where the new term ends up. Typing a topic that does not exist and saving the article creates it under that parent. This is the term's own edit form, with Uncategorised selected under Parent terms.
Three. The vocabulary afterwards. The new term is nested and nothing that was already there has moved.
Two things worth reporting from the deeper pass.
The setting is offered only where it means something. Building the widget settings form for a taxonomy field and for a node reference field on the same content type, the taxonomy one offers "Parent of a new term" and the node one does not, which is what the guard intends.
The setting also takes a plain term name. Typing "Uncategorised" into it, with no ID, stored term 16. That matters for testing, because it means a browser test can set this up without a term ID hardcoded in a fixture, which is what had stopped me writing one earlier.
Comment #9
rajab natshah