Problem/Motivation

Discovered while working on #3116822: Make project_issue compatible with PHP7+.

If you install project_issue from scratch (instead of updating a copy from the Drupal 1.0 days all the way to D7), the special handling for the issue tags field on issue nodes doesn't work. project_issue_issue_tag_autocomplete() is never getting called, and the code to order tags based on most-used-first doesn't happen.

On d.o, the Issue tags input form element points here:

value="https://www.drupal.org/index.php?q=taxonomy/autocomplete/taxonomy_vocabulary_9"

Whereas on my local site, it points here:

value="http://localhost/drupal-7/index.php?q=taxonomy/autocomplete/field_tags"

So we have a bug in project_issue_menu_alter() where it's assuming D6 (or earlier?) taxonomy autocomplete URLs. Now that vocabs have a machine name, not just a numeric ID, we need to be altering a different path for all this to work.

Proposed resolution

Fix project_issue_menu_alter() to more correctly handle where the autocomplete paths live for a specific vocabulary.

Remaining tasks

  1. Do it.
  2. Tests.
  3. Review.
  4. RTBC.
  5. Commit.

User interface changes

Issue tag suggestions will be ordered by frequency of tag usage on all project_issue sites (as intended).

API changes

Nope.

Data model changes

N/A

Release notes snippet

TBD.

Comments

dww created an issue.

dww’s picture

Further debugging. These autocomplete taxonomy paths are not (directly) determined by the vocabulary at all (neither vid nor machine_name). What actually matters and determines the path is the machine name of the term reference field on the issue node type(s). It just so happens to work on d.o since "we" (I've lost track of who) created the field on issue nodes as "taxonomy_vocabulary_9" to match what this code is expecting. Most sites will have something like "field_issue_tags" or whatever. So, we need to figure out the machine name for any term reference field on issue node types that corresponds to a vocab that's configured as an issue tags vocab and then we'll know the right menu item to alter. Fun. ;)

drumm’s picture

Right, I can probably take the blame for that one. At some point I became aware that string concatenation was the wrong way to find taxonomy fields, and haven’t had the time or motivation to correct that. project_release’s api tid has the same problem. As far as I know, we’d have to scan through the field config and find it. Or maybe the configuration could switch from storing the vocabulary ID to store the field name.

dww’s picture

I can probably take the blame for that one.

I'm not so sure. ;) It could very easily have been a dww + hunmonk decision in the D7 porting frenzy. There was a lot of: "There's no time to Do It Right(tm), just Make It Work(tm)!" influencing decisions in those days. ;)

Or maybe the configuration could switch from storing the vocabulary ID to store the field name.

Yeah, I looked into all the related code for a bit last night. I was coming to the same conclusion. Instead of config variables like this:

project_issue_taxonomy_vocabulary_issue_queue_2 = 'autocomplete'

It'd be a lot more convenient for various spots in the code to have something more like this:

project_issue_issue_queue_tag_vocabularies = [
  // Keyed by vocabulary machine_name.
  'issue_tags' => [
    'field_name' => 'field_issue_tags',
    'vid' => 2,
    'widget' => 'autocomplete',
  ]
]

(or something).

The values on d.o would look like:

project_issue_issue_queue_tag_vocabularies = [
  // Keyed by vocabulary machine_name.
  'vocabulary_9' => [
    'field_name' => 'taxonomy_vocabulary_9',
    'vid' => 9,
    'widget' => 'autocomplete',
  ]
]

Where exactly to set this correctly is a bit TBD, but I suppose the existing code when you submit a vocab could notice if you set the widget, and if so, do all the field config lookup to figure out the right stuff. Or something. ;)

Cheers,
-Derek