Port token_devel_token_object to D8

See devel_entity_type_alter() for how I'd imagine this could work in 8.x

Note that this already exists in TokenDevelController, so we can possibly just remove the old code. And we should also be able to simplify this a lot and get rid of all those wrapper methods in there.

I tested this with devel and it does not work at all. There was massive change required to get this working. I decided to split it and get devel integration at least working. We can add support for all entity types in a follow-up.

Attempting a fix... The problem was that there is no devel which produced slightly different configurations in routes and tasks. This should make it more consistent.

Looks nice already, but lets just complete this and clean up the controller to support everything, should be easy, see below.

1. +++ b/src/Routing/RouteSubscriber.php
   @@ -0,0 +1,79 @@
   +            '_controller' => '\Drupal\token\Controller\TokenDevelController::devel_token_' . $entity_type_id,
   

   There is really no need for this additional complexity. Drop the entity type in the method name and argument, we have an entity object that knows the type. Then you can drop all the alias methods and have a single method for all entity types.

2. +++ b/token.module
   @@ -286,24 +286,29 @@ function token_get_entity_mapping($value_type = 'token', $value = NULL, $fallbac
   +      // Remove this check later, once we support all entities.
   +      if (in_array($entity_type_id, ['node', 'comment', 'user', 'taxonomy_term'])) {
   +        $entity_type->setLinkTemplate('token-devel', $entity_type->getLinkTemplate('canonical') . '/devel/token');
   +      }
   

   then you can already drop this check. However, you should add a check to not define the token-devel template if it's already set.

Starting with a reroll to make sure we can get an interdiff later.

For comments in #7. I know it is not a lot of work to support all the entities, especially since the harder part is over. Still, I thought it simpler to stick to the scope and support what was possible in D7. I will attempt supporting other entities.

Okay, the change was not really that trivial. The method in the route could not take entity directly as the entity type id in the path would not match the parameter name in the controller method and produced an error like this:

RuntimeException: Controller "Drupal\token\Controller\TokenDevelController::renderTokenTree()" requires that you provide a value for the "$entity" argument (because there is no default value or because there is a non optional argument after this one). in Drupal\Core\Controller\ControllerResolver->doGetArguments() (line 171 of /.../core/lib/Drupal/Core/Controller/ControllerResolver.php).

I changed it to use RouteMatch similar to devel and it works now.

(Above is only to document how to fix this. The patch works fine now.)

Removing the check and restructuring the if block a bit. I tested this manually again and it works.

I see, yes, that was a bit more complicated :)

Looks a lot nicer now, though, just a few small things and it should be good to go

* We can extend from ControllerBase, then we don't need the implements + string translation trait
* renderTokenTree is missing a docblock and should be protected
* entityLoad is a strange method name, I'd go with entityTokens or so.
* not here, but we should move _token_token_tree_format_row() also to the tree builder service I think. The goal is to get rid of .pages.inc IMHO :)
* "'data' => [$entity_type => $entity]," => this should use the token entity mapper, the key should be the token_type not, the entity type. otherwise it won't work for taxonomy_term's.

Addressing points 1 and 2. I think the name is 'entityLoad' because it actually loads the entity from the RouteMatch and passes it on. I took it from devel. Of course, that doesn't mean it is right but I don't know what 'entityTokens' means. Can you reconsider the name?

As for the last point, should we do that in a follow-up? I didn't do anything there except change the array syntax. What do you think?

yes, it loads the entity, but that's just what it has to do to be able to do what it's actually about: *displaying tokens*, which is why I suggested entityTokens(). I haven't checked, but I'd guess devel calls it entityLoad() because it loads the entity and displays it, it probably also has entityRender/entityBuild or something like that.

I think we should fix the last point here, just means you need one more injected service and a method call there.

I see what you mean by 'entityTokens', but it is still not that intuitive, IMHO. I think it is not that important, though. Changing that and also fixing the point about token_type.

Hm, intuitive enough for me :) And agreed, not that important. committed, thanks!