Tokens to access individual meta tag values

Noticed the same issue. When trying to use [node:field_meta_tags:value] I just get the serialized string:

a:4:{s:11:"description";s:28:"[node:field_meta_tags:value]";s:12:"og_site_name";s:11:"[site:name]";s:8:"og_title";s:12:"[node:title]";s:14:"og_description";s:14:"[node:summary]";}

Bumping into this as well.
Any workaround that can be used?

Any news on this?

Any update on this?

Nothing yet.

An initial pass at adding token support. Inspiration taken from the token contrib module.

My particular use-case is using metatag tokens for title, description, etc and injecting that into schema_metatag tags. This way an editor can set a custom description on a node and it will be reflected in the structured data.

A cleaned up version of the patch.

Applied #9 patch, it works fine.

I can't get [metatag:description] to work with #9, although [metatag:title] works.

I'm trying to set my OG and Twitter card title and description fields to use whatever my Basic metatag title and description is for each node. This approach works for the title but not for the description. I can reproduce it on SimplyTest.me as well as my current project.

Thanks for testing the patch, Phil.

Let's add some test coverage to itemize what this functionality is expected to actually do.

@Damien
Thank you for the patch

Same here.

Applied #9 and it doesn't work correctly

if I try to use [metatag:description] in another metatag field. As I see it in loop inside the between metatag_tokens() and generateTokenValues() in MetatagManager.php class.

Confirming the issue in #14. Site goes down with the patch when you put a metatag token into a metatag field.

Looking now.

Fairly certain the issue is on this line

$processed_value = PlainTextOutput::renderFromHtml(htmlspecialchars_decode($this->tokenService->replace($tag->value(), $token_replacements, ['langcode' => $langcode])));

I've fixed the recursion issue outlined in comments 14 & 15.

My interdiffs gone weird for some reason but essentially I took @berdirs approach from #2955407: Static caching for token processing; iconv_substr() is super slow and added a processedTokensCache to the MetatagManager class.

Then in metatag.tokens.inc I've added a check if the processedTokensCache is empty. It the processedTokensCache has data in it then it's already been run so we can safely break out of the infinite loop.

I originally wrote the patch for this for a site on metatag 1.11, I've tried to retrofit it into the latest commit on 1.x. It *shouldn't* break, but I haven't tested it yet. It needs a proper run through. And test coverage, of course. But I'm out of time for today.

Marking needs review to check the tests pass.

I just clicked after uploading the patch that the MetatagManagerInterface will need the new function & property added.

Seems like the patch needs to be rerolled or something? The 8.x-1.x branch doesn't have an existing metatag.tokens.inc file so the patch isn't applying correctly.

Ah. Yes. I rolled the path running git add --intent-to-add metatag.tokens.inc && git diff...

Seems that was the cause of my interdiff being weird as well. It hasn't marked metatag.tokens.inc as previously being /dev/null so it's failed. I won't have the chance today, but I'll fix it up tomorrow.

Lets try this one.

This is actually the patch I wrote for 1.11, but it applies to the latest dev as well.

Patch in #20 had a bug, so I'm uploading a new version here which works from my testing.. But to be honest I'm not happy enough with the performance of this patch to recommend including it.

If I get some more time on this I'll look into refining it further. But it's paused for now. I'm just uploading this patch so others can pick it up if it's a feature they need. :)

This is great work, thank you all.

If you don't mind, I'm putting it back to "needs work" so some test coverage can be added before we commit it, that way we can have a specific idea of what we're getting with the change.

While writing the test, I stumbled upon a couple of bugs.

Default configured metatags were not working, but only metatags that were added on e.g. node form.

The metatag for canonical-url was not working because of the dash instead of underscore.

I guess [current-page:metatag:title] makes more sense than [metatag:title]. Also it makes testing the tokens easier since we can use a lot of code of the token module.

+ I also added support for fields. e.g. [node:field_metatags:title] is now also working.

Excellent work, thank you all!

FYI this caused a regression for some sites: #3186770: System status report page indicates Metatag's token types do not have any tokens defined

One of the earlier patches that allowed `[metatag:title]` and `[metatag:description]` worked perfectly.

However, the merged patch broke being able to pull values from manually entered metatag title and description to other fields (like og:title and og:description), even when using the new token format `[node:field_metatags:title]` etc.

@Coufu: please open a new issue and we can look at it; we'll definitely need to extend the test coverage for additional use cases.