Token for link field URL

@jienckebd I tried to check but it not reproduce. Please provide steps how to check the changes.

I modified the previous patch to make sure that the definition of the url token is included in `field_token_info_alter` which will make the link token also appear in the 'show tokens' ajax box.

The actual replacements of the url tokens are not created such as "absolute" or "relative". For example [paragraph:field_link:url:absolute] should create the absolute url.

Patch attached

Neither patch is correct on its own, what's needed is a combined version. So that both link_field:url and link_field:url:absolute works. A test would be good as well. We have existing field tests, so just need to add a link field as well and then we can test the expected token output.

How about utilising other stuff from elsewhere to make it more fully featured? It'll match other tokens then?

If this suits, I'm happy to write some tests - just we're ultra busy right now so I'd need to do it in a few weeks.

I guess now I think about it;

if (isset($field_item->$property_name)) {
  $replacements[$original] = $field_item->$property_name;
}

...would have been a bit cleaner. Meh, I'll alter that in a couple weeks when I can finally breathe after our big push.

The token system is recursive. If you define it as type url you shouldn't have to duplicate the code. You just need to handle the default token, and pass any nested tokens along like #6 is doing.

I'd misunderstood what you said in #7 then.

Simple fix.

Problem is, as you requested;

So that both link_field:url and...

But ... link_field:url doesn't work like this, and IDK why that is yet (I've no time to dig into it).

Yes, that's what I mean with combine the two patches. See how it works for the daterange type for example. If it's exactly "url" or "0:url" then you need to implement replace it yourself, if it's a nested token, you pass it along.

Indeed stupid of me not seeing that.

Tests added to patch.

Furthermore, the link field gives the possibility to also add an external link. For example https://www.drupal.org/foo/bar. When url:path token is added you expect to print the path of that external url "/foo/bar". This is currently not implemented and will return "/".
By validating if the url is external we can specify the correct results on every external url:* token. Although the external url implementation works, I am not sure if there are any core functionality that could replace these implementations.

Looks like that's triggering an alias lookup in the existing tests. I've yet to review what the code there is doing, but I'm not sure it should be combined into this issue. That other change will affect all existing link tokens and it's even more things to write tests for.

If you can clarify ... this is what's required, come end of next week - I'll have some time to write some tests.

@pobster:

Good one to check the actual properties. A few thinks that should be discussed about.

First, should we not only generate the tokens that core does not provide as what this module initially is for? The tokens uri and title are already provided by core. Probably by just checking if the property_name equals to url we only generate the tokens that core does not provide, right? The following code should then be enough:

elseif ($field_item->getFieldDefinition()->getType() == 'link' && $property_name === 'url') {
        /** @var \Drupal\Core\Url $url */
        if ($url = $field_item->getUrl()) {
          if (count($parts) > 1) {
            $field_tokens = \Drupal::token()->findWithPrefix($filtered_tokens, $property_name);
            $replacements += \Drupal::token()->generate('url', $field_tokens, ['url' => $url], $options, $bubbleable_metadata);
          }
          else {
            $replacements[$original] = $url->toString();
          }
        }
      }

As already used in patch 13 the Link FieldType has a method getUrl() that also includes the url options. see web/core/modules/link/src/Plugin/Field/FieldType/LinkItem.php.

@Berdir:

• Should we create a separate ticket for the correct external url parts tokens?
• The problem with the alias lookup is indeed also happing on my local environment, but only when a assertEquals fails.

Drupal core does not provide any field tokens. They exist right now because token.module generically provides tokens for defined properties, but with this snippet, we are probably skipping that generic implementation and need to check for it. A test will help to verify that.

• Removed external url parse_url implementation
• Skip tokens that are generically provided by the defined properties
• Add tests for uri and title tokens

...but with this snippet, we are probably skipping that generic implementation and need to check for it.

This is correct.

I'm attaching a mix of #16 and #19.

I think we still need the general implementation, because the same problem reported here also happens with the Link field. I have an external link with query strings and it gets HTML encoded, rendering & instead of &, for instance.

Therefore, I used the same technique of applying a Markup::create() to the strings so that they're not encoded afterwards.

I don't know if it's the best approach, but it is what works for me :)

I've also updated the Tests with the path property and a query string in one of the fields. I wasn't able to actually test it, though. I'm having a Base table or view not found: 1146 Table 'default.test24098324path_alias' doesn't exist in /var/www/docroot/core/lib/Drupal/Core/Database/Statement.php:59 exception when trying to run it... It's my first patch, as well as my first contact with Tests, so I don't know if I did something wrong.

In a nutshell:

• Added Markup::create() to the first two if/else statements in the new link implementation.
• Added Markup::create() to the path, absolute, relative and brief cases in the URL tokens implementation.
• Added a new value to the multivalued_field_link field in the tests and its respective expected tokens.
• Added the path property to the expected tokens as well.

Anyways, I hope it can help someone!

Sorry, wrong filename, I didn't notice the test report had been considered as a comment 😅

Pushed and rerolled patch from #22 in a MR

Hi there,
i need a token for the URL of a link field and found this here.
Unfortunaletely these patches cannot be applied to the latest token release.
Any advice or help is appreciated.
Thanks

The patch in my Merge Request applies on 1.x and 1.11.
If you don't know how to apply patches from a Merge Request, you can read this answer on stackoverflow.
In that specific case you can use that URL: https://git.drupalcode.org/project/token/-/merge_requests/24.patch

Thank you very much for the hint, DuaelFr.

If the token resolves to an internal URL (e.g. an internal node selected from an autocomplete lookup), this won't render as a link.

Have taken the 24.patch on GitLab and added:

if (strpos($uri, '/') === 0) {
  $uri = 'internal:' . $uri;
}

Before the:

$replacements[$original] = Markup::create($uri);

Unsure how to introduce path_alias into the test setup for this as TokenFieldUiTest extends TokenTestBase

What does the patch in #34 do? How is it different than #31? Can you provide any context to what the patch fixes?

I'm trying to write an embedded .mp3 player for a file field (displayed as a link) and Token appends "internal:" to the path, causing the player to fail. It's a site with not a ton of audio, so I'm working around it by rewriting the title to point to the file URL and using [node:field_audio_file:title] to send the URL to the player, but there should be an option to use the path without appending "internal:" to it.

My issue seems to be related to the discussion here, so I'm passing along the use case and trying to stay in the loop. This is a Drupal 10 site and the patch looks fairly substantial, so I'll hope for a commit. Thanks!

I'd like to know if it's posible to apply the patch to drupal 9.x and 10.x

Thanks.

I've re-rolled the patch against latest release 1.15.

Rerolled MR on latest dev version.

Is this issue similar or overlapping with this one, #1198032: Add modifiers to the [current-page:url] token to include the pager and the query string ?

Is this issue similar or overlapping with this one, #1198032: The [current-page:url] token should include the query string ?

Not especially ^^ this is distinct.

Needs to be rerolled now that #3545229: Convert hooks to OOP is in.

I did an iteration on it, but there is still an issue with this. It looks like there is a difference between [node:field_link_2:path] and [node:field_link_2:url:path]:

• [node:field_link_2:path] seems to return the relative path including the base URL (/web/foo/bar).
• [node:field_link_2:url:path] seems to return the relative path without the base URL (/foo/bar).

I have rebased the merge request and adjusted the tests so that they now pass. I am not sure that the test changes are correct; it may be that the test was right and the code is wrong.

This patch is for 8.x-1.16.

Applies to latest 1.17 release.

Syntax error in last patch...

Very useful issue. It solves a use case I had on a client project. Thanks for the patch!