Problem/Motivation

Photos 6.0.5 causes warning related to Token 1.1.3 module in Drupal 10.1.6 and 10.1.7:

Warning: Undefined array key "name" in Drupal\token\Token->prepareMultisort() (line 89 of modules/contrib/token/src/Token.php).

Discussed in this Tokenb module issue

https://www.drupal.org/project/token/issues/3372497

Steps to reproduce

  • Flush cache
  • Navigate to Reports - Status Report
  • Top of page is warning.
  • Refresh page and warning goes away - only seen with first view of Status Report or some other admin pages after flushing cache.
  • If I navigate to mysite.com/admin/help/token I can see that all the other tokens have a name in the Name column, but photos_image does not.

Proposed resolution

If I understand the discussion in the Tokens module issue queue, the photos module needs to include a 'name' field.

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#9 add_name_field-3407709-9.patch444 bytesfrontmobe

Issue fork photos-3407709

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

  • 3407709-lack-of-token Comparechanges, plain diff MR !2
  • 1 hidden branch
  • 6.0.x Comparecompare

Comments

pheski created an issue. See original summary.

pheski’s picture

Note: I am using 6.0.5, but that option was not something I could select when starting the issue.

pheski’s picture

Title: lack of token name throws error in token 1.1.3 » lack of token name throws error in token 1.1.3 with photos 6.0.5
nathaniel’s picture

Status: Active » Needs work

Thanks for reporting this. Looks like we can add:

$data['types']['photos_image']['name'] = t('Photo');

To:
function photos_token_info_alter(&$data)

Frontmobe made their first commit to this issue’s fork.

Frontmobe changed the visibility of the branch 6.0.x to hidden.

frontmobe’s picture

Status: Needs work » Needs review

I created an issue fork where I added the suggested change. I tested the change locally and can confirm it solves the issue, so I went on and also made the merge request.

All we need now is a review and then hopefully a merge I suppose ;-)

frontmobe’s picture

StatusFileSize
new444 bytes

I just realised that other issues in this queue don't (yet) use the Gitlab merge request workflow, but use the patch workflow in stead.

I added a patch that does the same as the commit in the issue fork, use whatever works easiest I would say ;-)

nathaniel’s picture

Status: Needs review » Fixed

Thanks for this! Looks good to me.

frontmobe’s picture

Many thanks Nathaniel!
Do yo think tagging a new release would be possible to prevent the error from showing up after updating to version 6.0.5?

nathaniel’s picture

frontmobe’s picture

That's awesome Nathaniel, thanks for tagging the new release!

Status: Fixed » Closed (fixed)

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