Tag form fields that support tokens

As part of this issue resolution I would suggest also adding a link to those fields to open the token browser. This will allow easy access to the token list and allow people to populate the field without searching for tokens.

I'm now seeing that after installing the Token module a link is added to the top of the ECA window to the Token Browser. I would suggest moving that link to the fields that support tokens and maybe (if possible) filtering the token list to what's allowed.

The second part with the #eca_token_reference form field property has just been implemented in ✨ Add token syntax validation where possible Fixed together with the form validation, that a token name comes without the brackets around it.

I'm now seeing that after installing the Token module a link is added to the top of the ECA window to the Token Browser. I would suggest moving that link to the fields that support tokens

Isn't that overwhelming the UI? I mean, with the new property #eca_token_replacement, this would technically be pretty easy, but I'm a bit uncertain if half a dozen similar links in a config form would actually make sense.

and maybe (if possible) filtering the token list to what's allowed.

That's pretty difficult, if not impossible. While building a model, it's not always known what tokens will be available when processing it. E.g. when starting with a Pre-save content entity event, it may be unknown which entity type will be the token entity. Or, if the model works with conditions, some tokens are only present if certain conditions are true.

All configuration forms are now properly tagged so that we can identify all fields that either reference a token or those that support token replacements.

All those fields get identical description texts, which is done in \Drupal\eca\Plugin\ECA\PluginFormTrait::updateConfigurationForm. There we can later add some extras, that have been suggested above.

Note, this only works for plugins where the maintainer provides the tags. We should encourage them to do that, at least there is a change record where they get informed about this: [#3381190]

You might already know that since this issue is not yet fixed, but anyway I've seen that currently most of the tagged form fields do not show the additional descriptions that are implemented in \Drupal\eca\Plugin\ECA\PluginFormTrait::updateConfigurationForm.

I've tried the condition plugin eca_current_user_id and action plugin eca_token_set_value that both have one of the newly introduced tags, but they're not showing the additional description:

Besides that, the currently implemented loop in \Drupal\eca\Plugin\ECA\PluginFormTrait::updateConfigurationForm is problematic:

<?php
protected function updateConfigurationForm(array $form): array {
    $containsTokenReplacement = FALSE;
    foreach ($form as &$value) {
      if (!empty($value['#eca_token_replacement'])) {
        //...
      }
    }
    unset($value);
?>

The problem above is that the foreach statement iterates through a renderable array, which may or may not contain arrays as $value. One proper way to iterate through its children is the following:

<?php
foreach (\Drupal\Core\Render\Element::children($form) as $child_key) {
  $value = &$form[$child_key];
  // ...       
}
unset($value);
?>

That loop needs to get fixed, so that we are able to pass through renderable arrays that already contain render information. Otherwise we may get fatal errors as !empty($value['#eca_token_replacement']) currently always tries to access $value as an array.

Thanks @mxh for pointing out these 2 issues. I actually didn't realize yet, that some plugins were missing the extra token info. The reason for that is, that we didn't follow the same sequence of form building everywhere. What we have almost everywhere is to define the plugin specific form elements first, and then call the parent form builder:

  public function buildConfigurationForm(array $form, FormStateInterface $form_state): array {
    $form['user_id'] = [
      '#type' => 'textfield',
      '#title' => $this->t('User ID'),
      '#description' => $this->t('The user ID, which gets compared.'),
      '#default_value' => $this->configuration['user_id'],
      '#weight' => -10,
      '#eca_token_replacement' => TRUE,
    ];
    return parent::buildConfigurationForm($form, $form_state);
  }

The parent form builder is adding the extra and common pieces, like the token explanation. When that parent form builder is called first, then the extra fields don't exist yet, when adding the common pieces.

I've updated all form builders to follow the same sequence and started a change records for this in https://www.drupal.org/node/3427033 →

Also thanks for the correction of the loop with render elements. I've fixed that too. But we need to keep in mind, that especially the bpmn_io modeller won't show any of the markup in a form whatsoever. That's something we can hopefully add at some point in the future there.

I've now added some markup to the config form, when at least one fields supports tokens:

This template supports the usage of tokens. Please refer to the token chapter in the ECA Guide, and if you install and enable the token module, you will find a link to the token browser right below the property panel, which shows you all available tokens.

For the bpmn_io modeller, this is displayed in the template tab, as this is currently the only place, where we can add extra info. If we get better options from the upstream library, we can easily move that there and then hopefully add some markup with line breaks and links.

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