Problem

Token types are objects that cannot just be converted to a particular piece of output automatically. Example: node_tokens() handles node:created tokens, and instead of letting system_tokens() (which defines the date type) handle the replacement entirely, it only does so for node:created:property tokens. node:created is replaced by node_tokens(), and so is node:changed.

Solution

Require data types to have a default property, so the token API can relieve hook_tokens() implementations of some of their responsibilities and create more consistency among replacements.

CommentFileSizeAuthor
#5 drupal_1975126_01.patch10.64 KBxano
#1 drupal_1975126_00.patch2.21 KBxano

Comments

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Assigned: Unassigned » xano
Status: Active » Needs review
StatusFileSize
new drupal_1975126_00.patch2.21 KB

This patch takes a slightly different approach. It hardly alters the token API and keeps hook_tokens() implementations responsible for the default tokens, but it moves this responsibility from scattered implementations to the implementation of the module that actually defines the token type. The patch currently only converts the node:author token to this new approach as an example, but converting the other tokens should not be hard.

Status: Needs review » Needs work

The last submitted patch, drupal_1975126_00.patch, failed testing.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Status: Needs work » Needs review

#1: drupal_1975126_00.patch queued for re-testing.

Tests pass locally.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
StatusFileSize
new drupal_1975126_01.patch10.64 KB

This patch converts some more (if not all) default tokens.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Very interesting. I feel like it's a bit of magic with an empty string as the $name, which makes sense, but it's hard to explain that to people implementing the token API that it means that it's the default token, and should not be used more than once. And that it should not be implemented for global tokens.

I wish that we could make this work by using information in token_info() by setting a 'default' => TRUE flag on a specific token for a specific type, but this may be a good start.

+++ b/core/modules/system/system.tokens.incundefined
+++ b/core/modules/system/system.tokens.incundefined
@@ -146,6 +146,8 @@ function system_tokens($type, $tokens, array $data = array(), array $options = a

@@ -146,6 +146,8 @@ function system_tokens($type, $tokens, array $data = array(), array $options = a
   if ($type == 'site') {
     foreach ($tokens as $name => $original) {
       switch ($name) {
+        // The site name is the default token.
+        case '':
         case 'name':
           $site_name = config('system.site')->get('name');
           $replacements[$original] = $sanitize ? check_plain($site_name) : $site_name;

[site:] is a global token, and should not have a default token name.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Very interesting. I feel like it's a bit of magic with an empty string as the $name, which makes sense, but it's hard to explain that to people implementing the token API that it means that it's the default token, and should not be used more than once.

I share your point of view. It makes sense, because there is no child token, yet using an empty identifier to identify something is conceptually weird.

And that it should not be implemented for global tokens.

[site:] is a global token, and should not have a default token name.

Why not?

I wish that we could make this work by using information in token_info() by setting a 'default' => TRUE flag on a specific token for a specific type, but this may be a good start.

What if there are multiple default tokens? If we want this, a better solution may be to specify the default token on the token type, than on the tokens themselves.

I am starting to think we may get rid of these defaults altogether and just say [site] and [node] and [user] are invalid tokens and will not be replaced. The main problem I wanted to solve here was that hook_tokens() implementations don't all have their own (possibly different) implementations of default tokens for the exact same token type, which leads to duplicate code and inconsistencies.

alansaviolobo queued 5: drupal_1975126_01.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 5: drupal_1975126_01.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Issue summary: View changes
Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

smustgrave commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

Since there's been no follow up in 3+ months going to close this one out, but if still a desired feature please re-open.

Thanks!