As a bug-reporting n00b I couldn't find this on here, apologies if I've looked in the wrong place & duplicated! I have created a basic taxonomy tree, just a vocab with with 2 parent terms, and then a 3rd term which I made a shared child of the first 2. When I insert a "Term Reference" field for my vocab into a content type, the select box only shows the child under the first parent, and nothing under the second.

After some poking, it seems that the form gets its allowed values from the function taxonomy_allowed_values which parses a term tree into an array with the key => value pairs of tid => name. This means that it will never hold more than one term with the same tid. To confirm this I modified the code:

        foreach ($terms as $term) {
          $options[$term->tid] = str_repeat('-', $term->depth) . $term->name;
        }

to this:

        foreach ($terms as $index => $term) {
          $options[$index . $term->tid] = str_repeat('-', $term->depth) . $term->name;
        }

Obviously this won't work when the form is submitted, but it demonstrates than when the array items have unique keys then all the terms are displayed correctly. I've not dug deep enough into D7's APIs or into Taxonomy's code to see how easy it would be to implement something to take this into account, but it seems like a huge oversight to me! If there's info / solution somewhere already that I've missed then I'd be really grateful, otherwise I'll try & come up with a patch meself innit.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sunlight Studios’s picture

Title: taxonomy_allowed_values does not allow hirearchical tree » taxonomy_allowed_values does not allow hierarchical tree
Sunlight Studios’s picture

Title: taxonomy_allowed_values does not allow hierarchical tree » taxonomy_allowed_values does not allow shared parents in hierarchical tree

ahem sorry about title changes

sun’s picture

Title: taxonomy_allowed_values does not allow shared parents in hierarchical tree » taxonomy_allowed_values() does not allow shared parents in hierarchical tree
Version: 7.0 » 8.x-dev
Priority: Major » Normal
Issue tags: +Needs backport to D7

The code snippets of the actual error in the logic look like a stupid oversight to me, but I'm not able to understand/confirm the problem description/scenario. Could use some less wordy, more concrete clarification and steps to reproduce.

Sunlight Studios’s picture

To reproduce on 7.x (I've not tried on anything later than 7.8)...

1. Create a vocabulary
2. Add two items, "Parent One" and "Parent Two"
3. Add a third item, "Shared Child" and set this as belonging to the above two parent items.

Now, when you click the "list" tab to view the tree, it rightly displays "Shared Child" as belonging to both parents, a la:

- Parent One
-- Shared Child
- Parent Two
-- Shared Child

HOWEVER! When you add a "Term Reference" field for this vocabulary to a content type, "Shared Child" will only show up once, under the first parent ONLY, like this:

- Parent One
-- Shared Child
- Parent Two

The form is generated using an array returned by the function taxonomy_allowed_values() function, on line 1452 of taxonomy.module, which looks like this:

function taxonomy_allowed_values($field) {
  $options = array();
  foreach ($field['settings']['allowed_values'] as $tree) {
    if ($vocabulary = taxonomy_vocabulary_machine_name_load($tree['vocabulary'])) {
      if ($terms = taxonomy_get_tree($vocabulary->vid, $tree['parent'])) {
        foreach ($terms as $term) {
          $options[$term->tid] = str_repeat('-', $term->depth) . $term->name;
        }
      }
    }
  }
  return $options;
}

It now becomes obvious why it's only showing once, because the $options array is keyed by tid, so any given term can only be listed once, regardless of how many parent terms it should be listed under. Although this does not render the "Term Reference" field unusable (as it's always going to be the same term no matter which one you select) it does result in an inaccurate rendering of the vocabulary's tree.

It may also be worth noting that this behaviour is NOT present on Drupal 6, where the select list correctly shows the shared child term under all of its parents as expected.

emclaughlin’s picture

Status: Active » Needs review
FileSize
713 bytes

Since you can't have a term listed twice under the same parent, would the solution be to just add the parent tid to the key?

Status: Needs review » Needs work
Sunlight Studios’s picture

Unfortunately the array returned by taxonomy_allowed_values is used directly in the form. The tid key is used as the value for the drop-down options, so it needs to be a pure tid when submitting. Changing it to $term->tid . '-' . $term->parent would mean changing the submit handler too - I haven't looked into this so it might be a trivial thing or it might be looooooooooong.

emclaughlin’s picture

Dang, okay. The problem with going through and changing the submit handler and all that of everything is, I would think, that you'd then have to find everywhere every function that gets edited is being called and edit those two and so on and so forth until you find an end?

Alternately, the submit handlers aren't necessarily keying by TID, just using the TID so I could investigate that and, if the submit handlers go from array[tid]=>whatever to array[something]=>obj->tid obj->whatever then it would be simple enough to split on the hyphen and make everything work that way.

Really, I'm just talking out loud to myself at this point. So back to taking another stab at this one!

ETA: No. The answer is no to that entire second paragraph. No. Also no to this entire way of solving the issue.

jibran’s picture

Component: taxonomy.module » entity_reference.module

The bug described in #4 is still the same but now ER is responsible for this code.

amateescu’s picture

Component: entity_reference.module » taxonomy.module

Drupal\taxonomy\Plugin\EntityReferenceSelection\TermSelection is provided by the Taxonomy module, moving back to the right queue.

jibran’s picture

Title: taxonomy_allowed_values() does not allow shared parents in hierarchical tree » TermSelection::getReferenceableEntities() doesn't allow shared parents in hierarchical tree
jibran’s picture

Status: Needs work » Needs review
FileSize
972 bytes

Instead of using composite key why not do this?

Status: Needs review » Needs work

The last submitted patch, 12: 1061232-12.patch, failed testing.

Sunlight Studios’s picture

The issue with changing the array structure is that the form relies on it for its output. Also any change to what the form submits means changing the submit handler. A composite key would mean not having to change the way the form outputs its markup, but still requires the submit handler to be changed. I have no idea what sort of knock-on effect this would have, so I've not attempted a fix (plus I originally filed this for D7 & haven't done any development on D8 so things might be different again).

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Lendude’s picture

Issue tags: +Bug Smash Initiative

This came up as a daily triage target of the Bug Smash Initiative.

Looking at the code \Drupal\taxonomy\Plugin\EntityReferenceSelection\TermSelection::getReferenceableEntities it uses loadTree to get all the terms. The data returned doesn't actually contain the data for the parent when dealing with multiple parents, it always returns the last parent id as far as I could tell. So getting this to work might require work deeper down in core.

What I'm wondering though is, does it matter that you can't select these in all their possible parents? We aren't storing the parent information, just a term ID, so when loading/editing again, this information is lost anyway right? which would just raise more questions I think.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.