Allow tokens in "Entity: create new" for langcode

I have prepared a simple patch to solve this problem

Thanks a lot @k.prozorov for your contribution, this is really much appreciated.

I can see how token support for the language code can be helpful. Just wondering about the user interface because there the field is usually a drop-down and that doesn't allow the use of tokens. Any ideas on how to bring that together?

Then, a couple of housekeeping items:

• Feature requests and bug reports go into the latest dev release, that's why I've changed that status field accordingly
• Code contributions are only made through issue forks and merge requests, so if this issue moves forward, please remove tha patch and provide an MR instead

At the moment, the langcode config is textarea in buildConfigurationForm (modules/content/src/Plugin/Action/NewEntity.php)

$form['langcode'] = [
  '#type' => 'textfield',
  '#title' => $this->t('Language code'),
  '#default_value' => $this->configuration['langcode'],
  '#description' => $this->t('The language code of the new entity.'),
  '#weight' => -40,
];

And it will be convenient if you can use tokens there.
I have prepared a merge request based on my patch.

Best regards.

Thanks for following up on this. The MR is currently failing tests, which is because $this->tokenServices is no longer plural in ECA 2 and needs to be called $this->tokenService.

However, the fact that the language code field is not a select field (drop-down) seems to be an oversight and should be fixed. I've just checked, we do have language code field in 3 different places:

• \Drupal\eca_base\Plugin\Action\Translate::buildConfigurationForm
• \Drupal\eca_content\Plugin\Action\NewEntity::buildConfigurationForm
• \Drupal\eca_content\Service\EntityLoader::buildConfigurationForm

Only in the "New Entity" action plugin it's a text field, the others use select fields as expected. So we should unify the behaviour there and make is a select field everywhere.

To still be able to provide token support, we could add an item to the select list which says Defined by token and that expects a pre-defined token name, e.g. eca_langcode. Then, in all 3 plugins we can add the token replacement if the option for the token is being used, and users can use that by defining the language code in that token before calling one of these actions.

k.prozorov → changed the visibility of the branch 3421088-allow-tokens-in to hidden.

I have prepared a new merge request for the 2.0.x version of the module.
In action NewEntity made the language selection as select field (drop-down)
Also, in 3 places (Translate, NewEntity, EntityLoader), I added the option to select the "Defined by token" option, when selected, the language code will be obtained from the token eca_langcode.
I tested all changes on a clean install of drupal 10.2.3 and they work as expected.

This is very nice, thank you so much @k.prozorov

I've left a comment in the MR about error handling and fallback value. In addition, I wonder if we may shift the logic of those langcode fields into a trait so that we can avoid redundant code?

There is now also the issue ✨ Add "Use token" option to drop-down lists Active where we may come up with a more generic approach to token support in select fields. Should we generalize this, or should that be addressed separately?

jurgenhaas → closed merge request !402

I've rebased the MR so that tests are passing again.

@k.prozorov any chance we can move this forward? I'd love to get this included in the forthcoming beta release for ECA 2.0

This is now implemented in a generic way:

• The form element, which has an #option element, can now also have an item '#eca_token_select_option' => TRUE,. ECA will then automatically add an extra option to the drop down.
• To receive the value, if this magic option is being selected, just call $this->getTokenValue() with the field key from the config form and a default value. This method is available by using \Drupal\eca\Plugin\ECA\PluginFormTrait

This way, a configuration form can even have multiple drop downs, each of which supporting the value being defined by a token.

jurgenhaas → closed merge request !403

Thanks a lot @k.prozorov for your contribution, the final implementation took on a lot from your issue fork and you have also been credited for this work. Thanks again and looking forward to your next one.

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

Re-opening this since we forgot 2 plugins that also support langcodes: \Drupal\eca_access\Plugin\ECA\Event\AccessEvent and \Drupal\eca_language\Plugin\Action\SetCurrentLangcode

Updated the langcode handling in those 2 plugins as well.

Reverted the change for \Drupal\eca_access\Plugin\ECA\Event\AccessEvent since token support doesn't make sense for an event. There are no tokens available at that stage.

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