Problem/Motivation

On the site I work on, we ran into an issue where, if a page has an image inserted using media browser at the very start of the body, part of the media browser token as the meta description.

An easy workaround is to just manually enter the desired description instead of using the [node:summary] token, but we would prefer to not need to hunt down any pages that have this problem.

Proposed resolution

The quick solution I can see is to run the node body that is stored in $options['token data'] through the tidyValue function before passing it into the token_replace function. This gives media browser a chance to process its tokens and gives tidyValue a chance to strip out any html and whitespace it needs to before token_replace truncates the body text.

Remaining tasks

  1. Review needed

User interface changes

API changes

Data model changes

Release notes snippet

Original report by tristangraves

On the site I work on, we ran into an issue where, if a page has an image, inserted using media browser, at the very start of the body, the Metatag module was outputting part of the media browser token as the meta description. This seems to be caused by the way token_replace handles creating the [node:summary] from a node body when there is no summary and the character limit of the teaser display.

The Metatag module defaults to using [node:summary] for the meta description. When Metatag processes this to create the description, it will run it through token_replace to deal with any tokens. The token_replace function would see that we had no text in the summary of this node (or are not using a summary field at all) and would use the node body as a fallback. It would automatically use teaser as the display for the body as it converts the token, which on our site is the default limit of 600 characters. This is where the problem comes in. Media browser tokens tend to be extremely long (at least on this site) and in my case the media browser token was longer than 600 characters causing it to be cut off.

The processed token with the broken media browser token would then return to the Metatag module to be further parsed eventually making it to tidyValue which checks for media browser tokens and processes them. Since we have cut off a chunk of the token, the conversion fails, but Metatag continues on and uses the left over token bits for the meta description.

The solution I came up with is to run the node body that is stored in $options['token data'] through the tidyValue function before passing it into the token_replace function. This gives media browser a chance to process its tokens and gives tidyValue a chance to strip out any html and whitespace it needs to before token_replace truncates the body text.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tristangraves created an issue. See original summary.

tristangraves’s picture

tristangraves’s picture

Status: Active » Needs review
tristangraves’s picture

Issue summary: View changes

Updated the summary to use the Issue Summary Template. Thanks @nmillin for showing me this existed.

DamienMcKenna’s picture

Assigned: tristangraves » Unassigned
DamienMcKenna’s picture

Status: Needs review » Needs work

This needs to be language-safe, so hardcoding it to use "und" isn't a good idea here.

tristangraves’s picture

I updated the code to get a language code from field_language to use instead of hardcoding "und". I haven't had any experience working with multilingual sites or code, so I'm not sure if this is the correct way to do this. Please let me know if I have more work to do on this or if I completely missed the mark.

tristangraves’s picture

Looks like tests were failing for the last patch because I wasn't making sure there was a node to work with when checking the language. This patch should fix things I think.

DamienMcKenna’s picture

Thanks for putting that together, and for the test coverage, it's appreciated!

I split out the JSON encoded string into arrays that are then passed through json_encode(), just to make maintenance easier.

DamienMcKenna’s picture

Status: Needs review » Fixed

Committed. Thanks!

Status: Fixed » Closed (fixed)

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

ron_s’s picture

@tristangraves, fyi, the patch in this thread is causing a critical problem with the newest 7.x-1.26 release:
https://www.drupal.org/project/metatag/issues/3102817