Bug: Can't specify pathauto pattern for corporate body terms

[kayakr]

With a reasonably fresh playbook instance, if I visit /admin/config/search/path/patterns/add and try and specify a pathauto pattern for a corporate_body term, e.g. pattern=/agent/[term:name], when I submit the form I get "The website encountered an unexpected error. Please try again later." and dblog shows:
"Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity_bundle:taxonomy_term" plugin does not exist. Valid plugin IDs for Drupal\Core\Condition\ConditionManager are: request_path_exclusion, entity_bundle, group_type, media_has_term, file_uses_filesystem, node_had_namespace, parent_node_has_term, media_uses_filesystem, node_is_islandora_object, node_has_parent, content_entity_type, node_is_published, media_is_islandora_media, node_has_term, media_has_mimetype, language, node_type, current_theme, request_path, user_role in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /var/www/html/drupal/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php)."

• Using Pathauto 8.x-1.6 and CTools 8.x-3.2 on Drupal 8.8.2
• Pathauto patterns for nodes can be added ok.

Has anyone else tried this?

[kayakr]

Also occurs on a different instance running Drupal 8.7.12. It also occurs if you try to apply a pathauto pattern to tags vocabulary.

[kayakr]

Doing some digging via xdebug on Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition(), when DiscoveryTrait is Drupal\Core\Entity\EntityTypeManager doGetDefinition() is invoked with 69 $definitions items, but when the exception occurs DiscoveryTrait is applied to Drupal\Core\Condition\ConditionManager the number of definitions has dropped to 20 and $plugin_id entity_bundle:taxonomy_term is not one of them.

It looks like Pathauto, CTools, and Context might be implicated here.

[kayakr]

Just stood up a test instance on simplytest.me with pathauto and context and can add patterns to tags vocab plus a vocab I added to the site.

[kayakr]

A bit more digging. Submitting the pathauto pattern for taxonomy term flows via web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php -> doGetDefinition() with plugin_id=entity_bundle:taxonomy_term and errors with PluginNotFoundException. If I hack this to be just entity_bundle the form submission completes and I can save corporate_body terms and get an automatic alias.

But in the Pathauto pattern admin UI /admin/config/search/path/patterns the condition is listed as "Entity bundle in the list:" with no other data. This implicates islandora/src/Plugin/Condition/EntityBundle.php; the islandora condition is possibly interfering with other conditions?

[kayakr]

Ok, I think I might know the problem. Islandora defines an entity bundle condition in web/modules/contrib/islandora/src/Plugin/Condition/EntityBundle.php using id=entity_bundle but this has a naming collision with entity_bundle as used by ctools, see https://git.drupalcode.org/project/ctools/-/blob/8.x-3.x/src/Plugin/Condition/EntityBundle.php#L17

This causes weirdness, e.g. Islandora conditions operation in the context of defining pathauto patterns.

@dannylamb Can you check my thinking here? I think EntityBundle.php may need to refactored to use an id like islandora_entity_bundle instead, or should depend on and subclass ctools?

[dannylamb]

So I've looked into this and I think going forward it's probably best to just use the ctools plugins for looking at entity bundles. But it is done differently. It's a 'derived' plugin, so instead of one plugin for all types, there's one for each that's dynamically generated.

So I did an audit, and we're only using our plugin in one spot in islandora_defaults, and that's in the all_media context. That could be easily replaced with the ctools media flavour of entity_bundle. We could also programatically suss out what type of the new derived plugins to make by looking at the context_mapping. So we could theoretically do this for all contexts and write an update hook.

But are there any other places where conditions get exported? If there's too much leakage, it may be best just to rename and then deprecate it, urging people to use ctools instead.

Open to thoughts on this one.

[seth-shaw-unlv]

[I]t may be best just to rename and then deprecate it, urging people to use ctools instead.

That seems like the safest path forward until we fully understand the implications of this move, especially since the release is already late.

[whikloj]

Resolved with Islandora/islandora@7b24912 and Islandora/islandora_defaults@7963c98

[kayakr]

Thanks @whikloj