Consistent tokens support across all entities and fields

This is currently not done on purpose to avoid conflicts and duplicate between manually defined and generated tokens. E.g. node token names don't match 1:1 to field names and that will result in confusing duplicates and also even more tokens than there already are, which makes the UI overload problem worse until there is a better one.

I see very strong arguments on both sides of this. Some possible ways of reconciling:

1) Hide the extra tokens this patch causes from the UI

2) Allow a setting to toggle the behavior, as suggested by @chrisolof

3) Create a new 'fields' group for each entity type, and put the full set of automatic tokens generated by this patch under that. So it's [node:fields:my_computed_base_field] and you have both [node:fields:title] and [node:title]. Because the extra fields are all collapsed up under 'fields' the clutter is minimised.

I think 3 is cleanest.

I tried #6 but I cannot see my computed field token in the list.

EDIT: Probably because my computed field is a bundle field, added via hook_entity_bundle_field_info_alter()?

My usecase was to have the UUID in the path using pathauto. I was slightly surprised that the token module didn't natively support this as this is core entity data. Anyway, I didn't like the idea of using a module specially for this - so I tried @chrisolof 's patch #6. It worked perfectly. Thanks very much indeed.

I have the same problem as #9 while using the same hook.

I too was struggling with bundle base fields and have updated the patch, it probably needs some tests but I am not sure the best way to approach those. Attached is a patch and interdiff for adding bundle base field support too.

Here's a proposal: Add a setting to control this. Similar to how pathauto has an entity type setting for which entity types the path field should be enabled.

To keep the existing behavior, support NULL as an implicit default-behavior value.

We can extend \Drupal\token\TokenEntityMapper with a methods to make it easier to access that information.

If the stored value is an explicit TRUE or FALSE, respect that, if there is no value set, then fall back to the existing check. Once someone visits the settings page, and saves it, we store an explicit TRUE/FALSE for any entity type. That could also be useful if you know that some entity types will never be used for tokens, then you can disable that for you site.

Someone interested in working on that?

Just FYI, I ran into a case with MetaTags where I needed to reference a Token for a computed field. Used the patch in #12 on my D9.0.10 site and seems to have worked. +1 for getting this in as an option somehow.

I used patch from #12 with D9.3 to get [node:uuid] working for URL alias patterns. Hope we could get this patch into some of the next releases.

Furthermore, we should let the user decide, if the token module should even create a token for an entity, maybe via annotation.
I am currently working on a module, which needs tokens to display different legal text saved by entities. So additionally to my custom tokens defined in the module file, it automatically creates attribute tokens for my entity, which I want to permit. Doing this is currently quite dirty, since I need to use "hook_token_info_alter" to unset these tokens.

It works, but doing so, will still show the tokens in the Token Help Menu, even if they are not usable.

So perhaps we could add an Entity annotation for automatically creating tokens? What do you guys think? Or did I miss a fundamental way to do this properly?

Looks like the latest release stopped the patch from applying, so I did a quick reroll

Used patch from #17 and works.
I use it for [taxonomy_term:uuid].

The issue probably should write out tasks so it is easier to see what is done and still needs to be done?

+1 to #13. But for now, i'm just going to use the latest patch.

Re-rolled #17 against latest dev.

Hello @Berdir,

Does your proposal from #13 still valid? Does it worth to put effort on this?

In that case I could invest some time to try to push this issue.

Opened #3466573: Expose UUID tokens for all content entities in Drupal core that adds UUID support for built-in content entities in Drupal core.

Re #21, yes, I still think that might be a viable way forward.

+1 one for this patch.
I have a custom entity type, for which I was provided some custom tokens, but there is no way to have standard tokens work (like id, label, etc.).
This patch solves the issue.

#20 still requires the field module to be installed, even though generic field support has been added:

  // Call proxy implementations.
  if (\Drupal::moduleHandler()->moduleExists('field')) {
    _field_token_info_alter($info);
  }

The module exists check can be removed.

#3466573: Expose UUID tokens for all content entities in Drupal core has been committed to 11.x.

I was using a patch in this issue to generate UUID tokens for custom entities, but I am now able to remove the patch and I still have UUID tokens as a result of the change referenced above.

Is there still a need for this issue? It seems like it has now been fixed upstream for most? use cases.

My proposal from #13 is still valid and useful

Updated the proposed solution based on Berdir's comment at #13, please double check.

For those who were using patch #20 I have re-rolled the patch against version 1.17

There was a typo in previous patch :( sorry

That was really not a good idea to re-roll the patch in a rush, because there is another typo :(