Let ECA models provide tokens by implementing hook_token_info

Maybe (or maybe not) related project: https://www.drupal.org/project/token_eca_alter →

Nice, thanks for linking this @mxh as I din't know about that module yet. Looks like an interesting feature set, which is in some way related to this issue. But I guess this one could provide some additional functionality.

The ECA module seems like it could provide some basic events to inject into the token build and token render context and allow dynamic generation of tokens for use around the site. Token alter seems interesting but that only seems to be for existing tokens, not generating all new ones.

These tokens are the traditional Drupal tokens, like [node:title].

It would be an incredible boon to site builders if they could create these tokens with the same interface ECA has. Right now custom tokens have to be developed in code. In general, most custom tokens come about for a need to 'show this if not that', conditionally, which ECA shines at building out.

Here is an example. I had an ask recently to 'change a string of text in content if the URL has a query parameter of X'.

/**
 * Implements hook_tokens().
 */
function demo_tokens_tokens($type, $tokens, array $data, array $options, BubbleableMetadata $bubbleable_metadata) {
  $replacements = [];

  if ($type == 'mytokengroup') {
    $request = \Drupal::request();
    $filter = $request->get('filter', []);
    $cid = !empty($filter['cid']) ? (int) $filter['cid'] : 0;

    foreach ($tokens as $name => $original) {
      switch ($name) {
        case 'signup_headline':
          $bubbleable_metadata->addCacheableDependency('url.query_args:filter');

          // basic logic example
          $text = match($cid) {
            1 => 'CID 1 specific text here',
            2 => 'CID 2 specific text here',
            3 => 'CID 3 specific text here',
            default => 'Unknown or unspecified CID - will default to content set in configuration.'
          };

          $replacements[$original] = $text;
          break;

        default:
          break;
      }
    }
  }

  return $replacements;
}

It was not hard to do, necessarily, but its just more time spent by developers and something still out of reach of site builders. ECA might be able to fulfill this need.

I created a PoC in !420 and played around with that for a bit. Not sure whether that's a good solution path. Had to add a recursion level flag and implemented without a hook inside ECA's token service, as hook_tokens are a bit late and might require more implementation logic when using hook_tokens instead. At least it just needs one additional event, then you can use already existing actions of eca_base like "Token: set value". Attached a small example model to demonstrate how it could work.

This is looking good to me, and I've fixed the test failures.

Now setting it to RTBC but would certainly be interested, what @kevinquillen thinks about it and if this approach satisfied his original proposal/request.

I can't seem to install or test this at the moment because it is on the 2.x branch which requires Drupal 10.3 and having trouble requiring it:

Problem 1
    - Root composer.json requires drupal/eca dev-2.0.x -> satisfiable by drupal/eca[dev-2.0.x].
    - drupal/eca dev-2.0.x requires drupal/core ^10.3 || ^11 -> found drupal/core[10.3.x-dev, 11.x-dev] but these were not loaded, likely because it conflicts with another require.

This is a new feature and will most likely not land in ECA 1.1, so for testing, a fresh Drupal test site with 10.3 and ECA 2.0 would be beneficial. Maybe worth having such a test installation around, as there will be plenty of things to test in the coming weeks and months ;-) Drupal 10.3 is just around the corner anyways.

Yeah I have a small install for this but I think there is a conflict elsewhere. I'll have to do a whole new 10.3 stack.

Dear all,
This new feature is interesting.

i am the author of https://www.drupal.org/project/token_eca_alter →

I discovered ECA and it is a great module for Drupal Site Builder and developers.
I also created some other ECA for my projects. It will interesting if i can help for distribute to ECA core:

My others ECA modules:
https://www.drupal.org/project/views_extender →
https://www.drupal.org/project/eca_helper →
https://www.drupal.org/project/eca_condition →

I've tested this again and decided to merge, as the ECA 2.0 beta release is coming in the next couple of days. The solution path is a good one, and if we find any follow-up tasks, they can be addressed in separate issues.

Automatically closed - issue fixed for 2 weeks with no activity.