What are the steps required to reproduce the bug?
$config['taxonomy.settings']['override_selector'] = true; to your settings.phpWhat behavior were you expecting?
The term should be listed.
What happened instead?
The term is not listed. Without knowing the url or term id, you have no way of deleting or editing the term, although it still shows up in Views and you could potentially build a View of Terms to find and manage it.
--
Aside from the code, I could find no documentation at all on what "override_selector" even is. It appears to have been brought forward in the logic from previous versions of Drupal and looks like it was meant to prevent memory overruns and such in the event that a term had too large or deep a hierarchy of parent terms. In the code, the only use of it I can find is simply to prevent the "Parent terms" input from being added to the term create/edit form under the "Relations" fieldset.
The default for what seems like a very deceptively or poorly named "override_selector" setting does appear to be false. So it is unlikely that someone would run into this or want to change this value to true in a fresh Drupal install. And to be honest, I have no idea how my Drupal implementation wound up with a value of true. But this was a Drupal 6 to Drupal 8 migration and its deviation from the default could either have occurred due to that or a module or something that was messing with the original setting (taxonomy_override_selector) on the Drupal 6 side pre-migration. The Drupal 6 site had a high number of taxonomy-related modules in play including Taxonomy Menu, Taxonomy Images, Taxonomy Nodes, and Taxonomy Hierarchical Select. So that could very likely have been the case.
That said, it is possible that others could run into similar situations, and to be honest, it doesn't really matter what caused the value to be true; if you create a term, it should be listed on the "List terms"/Overview page for management, especially since override_selector does not appear to be a setting that otherwise is used or indicated to "hide" terms and only does so when TRUE at the time the term is saved.
This behavior appears to be due to the form not having a value for $form['relations']['parent'] when saved since the whole selector is removed per the reasons stated above. But there is no default value provided for when the input is removed.
The attached patch fixes this problem and removes some redundancy as well as moves some logic for setting the default parent value so it is able to be used elsewhere in function form of core/modules/taxonomy/src/TermForm.php without further redundancy.
It's possible that maybe this is not the right approach and that the situation should be fixed in the terms list builder instead, but this at least populates the term's value in the taxonomy_term_hierarchy table (soon to be taxonomy_term__parent), which I'm guessing is the real problem here, and likely why the fix needs to be a part of the submit instead, as fixed here.
It's also possible that the change in the logic for swapping taxonomy_term_hierarchy table for the new taxonomy_term__parent table may also have already fixed this as I'm only testing on 8.5. So someone should do a proper test/review.
Please review and consider adding this fix. Another thing to consider would be where to best document the purpose of override_selector in the first place and/or assess if it's purpose is no longer needed and should be deprecated.
Closed: duplicate
9.3
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I thought our Drupal 10.3 site was corrupted somehow until coming across this issue. We specifically had the issue of not being able to set a parent for a term through the create/edit form. This would also cause the parent to be lost when editing an existing term.
Thanks @DigitalFrontiersMedia
https://www.drupal.org/project/drupal/issues/2985762#comment-12686651 🐛 Terms created when override_selector = TRUE don't appear on Terms List/Overview page Closed: duplicate