Introduce a token to get site's base URL

Passing a string when $options['language'] needs to be a language object is invalid input and would cause PHP notices. This works as designed. Sounds like you want to be using 'Path based negotiation with fallback to default language if no defined path prefix identified.' mode for locale.module instead.

Pardon, it's the 'Path prefix only' setting on that will not output the default language prefix when using url() which is what you want.

Sorry I don't understand how I am supposed to obtain the base url via a token.
I want my open graph image path to be set as [site:url]/sites/default/files/og_image.jpg
Unfortunately the language prefix is added so the path http://www.mywebiste.com/fr/sites... does not exist.
What should I do ?

I had the same problem, finished creating my own token so that images in mail works. Just use [url-abs] and tadda, you have the web url without the language prefix.

/*Declare token*/
function mymodule_token_info() {
  $info['tokens']['site']['url-abs'] = array(
    'name' => t('Absolute URL'),
    'description' => t('Url of the site, no language prefix garanted'),
  );
  return $info;
}

/*Token replacement*/
function mymodule_tokens($type, $tokens, array $data = array(), array $options = array()) {
  $replacements = array();
  global $base_root;

  if ($type == 'site') {

    foreach ($tokens as $name => $original) {
      switch ($name) {
        case 'url-abs':
          $replacements[$original] = $base_root;
          break;
      }
    }
  }

  return $replacements;
}

Alternatively, if you do not wish to create a new module, you can use the Custom Tokens module and create the new custom token url-abs with the following PHP code in it:

global $base_root;
print $base_root;

I didn't manage to do #5 in template.php, which is a nice solution. I don't understand why standard token module does not have such a token.

Thanks @guile2912 I could use your code in menu_token to link to pdfs, as you can see here
https://drupal.org/node/1151856#comment-8794261

Just in case someone is looking for this answer, this comment has already made the shot:

https://api.drupal.org/comment/46528#comment-46528

This issue still seems to exist. Can we provide a token for this?

Yes, it exists, but it does so by design. "Fixing" it to work like you'd expect might break it for others that expect it.

The only solution would be to define a new token, something like [site:base]

True, this would make more sense. Should we use this issue or a new one for this?

This is true in Drupal 7 too, OMG! I've been using this wrong forever :/

This is so serious for Metatag module..

I tried to find the right place to fix this. The token contrib module doesn't seem to be providing the site tokens. Drupal core's system module provides them.

The attached patch fixes the issue for me. Three things are missing:

1) IS update

2) The other tokens add cachable dependencies:
$bubbleable_metadata->addCacheableDependency($result);
My patch doesn't for the new [site:base-url] token.

3) Test are missing.

For those that want to implement this in a custom module, here is a gist: https://gist.github.com/luksak/6e1d24e10be056a304b46ce77e90b71f

I've checked your patch and realized that it doesn't work, i'm providing own.

Patch works perfectly. Can't believe this is not in core...

Missing dot in the description text.

Adds test coverage.

Improving test and bubbleable metadata.

$bubbleable_metadata->addCacheContexts(['url.site']);

Update issue summary.

The description of the token [site:url] requires more details. The new and old token are very similar. It can be confusing. I suggest change the description of the old token [site:url].

diff --git a/core/modules/system/system.tokens.inc b/core/modules/system/system.tokens.inc
@@ -42,7 +42,7 @@ function system_token_info() {
   $site['url'] = [
     'name' => t("URL"),
-    'description' => t("The URL of the site's front page."),
+    'description' => t("The URL of the site's front page with the language prefix, if it exists."),

+++ b/core/modules/system/system.tokens.inc
@@ -36,9 +36,13 @@ function system_token_info() {
+  $site['base-url'] = [
+    'name' => t("Base URL"),
+    'description' => t("The site's base URL."),
+  ];

+++ b/core/modules/system/tests/src/Kernel/Token/TokenReplaceKernelTest.php
@@ -103,6 +103,7 @@ public function testSystemSiteTokenReplacement() {
+    $tests['[site:base-url]'] = \Drupal::request()->getSchemeAndHttpHost();

The words base url are complex in Drupal. The problem is what the Symfony request thinks of as the base URL and what Drupal defines it as are different concepts. See \Drupal\Core\DrupalKernel::initializeRequestGlobals() and what's called $base_root and $base_url and how the base url global in Drupal is changed depending on the script location.

Especially as this is user-facing text we need to describe this differently. Maybe something based around the Symfony words of the scheme and HTTP host.

I have tried to address #25 by coming up with "Origin URL" term which sounds more user-friendly IMHO.

+1 for #27!

+1 for #27 in my opinion.
Since "location.origin" indicates protocol + domain name, to me it sounds descriptive to call it "Origin URL" [site:origin-url].

Reroll of #27 against current 8.8.x; patch wasn't applying any more due to https://www.drupal.org/node/2731817

+1 for #30

I agree with #29: To be consistent, it should be

"origin-url" instead of "url-origin" which would mix things up. Positive side-effect: All URL tokens are ordered below each other.

1. I updated the issue summary according to recent comments (new token name).

2. We need a change record.

Prepared a change record at https://www.drupal.org/node/3092269.

I triggered tests for #30 on 8.9.x branch all tests passed successfully.

Since many people, +1'd the latest changes regarding the token name I am going to remove "needs usability review" tag and RTBC it.

+++ b/core/modules/system/system.tokens.inc
@@ -37,9 +37,13 @@ function system_token_info() {
-    'description' => t("The URL of the site's front page."),
+    'description' => t("The URL of the site's front page with the language prefix, if it exists."),

Doing a bit of thinking about this change. It's quite complicated because on multi-lingual sites where this is an issue what does actually mean? Which language and how it is determined.

Here's the list of site information URLs we have with core (name, token and description) - we now have both scheme and protocol describing essentially the same thing. Somehow all of these need to work together to make it is easy for the user to choose the correct one.

Login page	[site:login-url]	The URL of the site's login page.
Origin URL	[site:origin-url]	The scheme and HTTP host of the site.
URL	[site:url]	The URL of the site's front page with the language prefix, if it exists.
URL (brief)	[site:url-brief]	The URL of the site's front page without the protocol.

Another complicating factor is the fact that Drupal can be in a sub-directory and the Origin URL will not reflect that. I think the name and token need to replace that this is only the http-host and protocol/scheme. I don't think "Origin URL" quite covers that atm.

Maybe an alternative here would be to provide the HTTP_HOST only - minus the protocol/scheme. I'm pretty sure that's what people really wanted with the "URL (brief)" token and this way if people want to build URLs this will be flexible to provide the base for quite a few things. And it could be called "HTTP host" so it'd be very clear how it was different from everything else.

> Doing a bit of thinking about this change. It's quite complicated because on multi-lingual sites where this is an issue what does actually mean? Which language and how it is determined.

Note that there is actually no change here, the only change is documenting the existing behavior. It defaults to the current URL language (like all links that don't provide the language explicitly) or the language provided to the token replace call. So for example for [site:url] in an password recovery e-mail is for the language of the user the e-mail is sent to.

Which makes it quite hard to explain, as the description is static and has no way of knowing what "the language" will be.

About base and original. I think the token *should* include the base url, and then IMHO site:base-url is still the better name. The example in the issue summary ( [site:url]/sites/default/files/og_image.jpg) does require the base path. Also, the site:url cache context that we use has this implementation:

$request->getSchemeAndHttpHost() . $request->getBaseUrl()

which is base url, so I think we should use the same implementation and name. Additionally, it also maps to Url::fromUri('base:sites/default/files/og_image.jpg').

@Berdir great idea. +1

Updated the patch according to the latest suggestions -> [site:base-url].

I was not sure whether we should use $request->getBaseUrl() or $request->getBasePath(). When you are on drupal.test/subdir/index.php/user/login, $request->getBaseUrl() will return /subdir/index.php which can produce unwanted results when this token is used in the mentioned example [site:base-url]sites/default/files/og_image.jpg.

However, the same URL is resolved with Url::fromUri('base:sites/default/files/og_image.jpg') so I followed the same behavior...

Updated the issue summary and the change record https://www.drupal.org/node/3092269.

1. +++ b/core/modules/system/system.tokens.inc
   @@ -135,11 +135,9 @@ function system_tokens($type, $tokens, array $data, array $options, BubbleableMe
   -        case 'origin-url':
   -          /** @var \Symfony\Component\HttpFoundation\Request $origin_url */
   -          $origin_url = \Drupal::request()->getSchemeAndHttpHost();
   +        case 'base-url':
              $bubbleable_metadata->addCacheContexts(['url.site']);
   -          $replacements[$original] = $origin_url;
   +          $replacements[$original] = \Drupal::request()->getSchemeAndHttpHost() . \Drupal::request()->getBaseUrl();
   

   Hm, the index.php thing is interesting. If Url::fromUri('base:') works the same way then maybe we should keep it consistent, but it does seem wrong as your example shows.

2. +++ b/core/modules/system/tests/src/Kernel/Token/TokenReplaceKernelTest.php
   @@ -104,7 +104,7 @@ public function testSystemSiteTokenReplacement() {
        $tests['[site:url-brief]'] = preg_replace(['!^https?://!', '!/$!'], '', Url::fromRoute('<front>', [], $url_options)->toString());
   -    $tests['[site:origin-url]'] = \Drupal::request()->getSchemeAndHttpHost();
   +    $tests['[site:base-url]'] = \Drupal::request()->getSchemeAndHttpHost() . \Drupal::request()->getBaseUrl();
        $tests['[site:login-url]'] = Url::fromRoute('user.page', [], $url_options)->toString();
   

   This is a kernel test, so we should be able to hardcode what we expect exactly, afaik it's always going to be http://localhost. We could also simulate a base path by changing the request.

Addressed #42.2.

Added assertion for the cacheable metadata too.

This looks good to me. The one remaining problem now is the getBaseUrl() vs getBasePath() thing, which is I think incorrectly implemented for Url::fromUri('base:') too. I'm not sure if we should add the likely wrong but consistent implementation here or use the correct one and open a follow-up to only fix for base:some/path.

There actually were bugs about base:, for example #2881999: Path to statistics.php is not correct when the path start with index.php, the "fix" there was to stop using base:, but maybe we should have fixed base: instead?

I think we should prioritise what’s right. If base: is broken let’s fix it (in another issue). So let's make this work how a user would expect rather than being consistent with something that is a little bit borken.

Discussed with @alexpott. Lets implement it here without index.php in the path (lets also test that explicitly if possible), and open a follow-up to fix Url::fromUrl('base'), as part of that we could revert the statistics.php fix and we should have some test coverage already.

I created a follow-up to fix URLs with base prefix #3099926: Fix base prefix when generating URLs if index.php is in the path and fixed the [site:base-url] token to exclude "index.php" if it is present in the path.

Additionally, I am uploading a test-only patch which adds test coverage for this case, created on top of #44.

It seems to me that there should be both [site:base-url] (using Request::getBaseUrl()) and [site:base-path](using Request::getBasePath()). This doesn't work with what getBaseUrl() actually does.

Attached is a patch which builds on #48 and has both [site:base-url] and [site:base-path].

Fix coding standards, see https://www.drupal.org/pift-ci-job/1620405

1. +++ b/core/modules/system/tests/src/Kernel/Token/TokenReplaceKernelTest.php
   @@ -7,6 +7,7 @@
     * Generates text using placeholders for dummy content to check token
   

   14 | ERROR | Doc comment short description must be on a single line, further text should be a separate paragraph (Drupal.Commenting.DocComment.ShortSingleLine)

2. +++ b/core/modules/system/tests/src/Kernel/Token/TokenReplaceKernelTest.php
   @@ -126,6 +129,28 @@ public function testSystemSiteTokenReplacement() {
   +    // Test [site:base-url] and [site:base-path] token with "index.php" in the path.
   

   148 | WARNING | Line exceeds 80 characters; contains 84 characters (Drupal.Files.LineLength.TooLong)

In fact, there are two more, but Drupal.org CI did not complain about it, so they are untouched.

Re-roll. In #52, item 1 is in the existing code, so this patch does not touch it.

Please let me know if a version of this patch is required for 9.0.x.

Just confirming that #53 has been working well for me since I applied it a couple weeks ago on a production site.

Reroll.

Re-roll.

Patch in in #58 working fine for me

@Anas_maw, feel free to mark this RTBC.

Working as expected

1. +++ b/core/modules/system/system.tokens.inc
   @@ -24,6 +24,7 @@ function system_token_info() {
    
   
   @@ -131,6 +144,16 @@ function system_tokens($type, $tokens, array $data, array $options, BubbleableMe
   +        case 'base-path':
   +          $bubbleable_metadata->addCacheContexts(['url.site']);
   +          $replacements[$original] = \Drupal::request()->getBasePath();
   +          break;
   
   +++ b/core/modules/system/tests/src/Kernel/Token/TokenReplaceKernelTest.php
   @@ -126,6 +129,29 @@ public function testSystemSiteTokenReplacement() {
   +    $this->assertEquals('http://localhost/subdir', $this->tokenService->replace('[site:base-url]', [], ['langcode' => $this->interfaceLanguage->getId()], $bubbleable_metadata));
   +    $this->assertEquals('/subdir', $this->tokenService->replace('[site:base-path]', [], ['langcode' => $this->interfaceLanguage->getId()], $bubbleable_metadata));
   +    $this->assertEquals((new BubbleableMetadata())->addCacheContexts(['url.site']), $bubbleable_metadata);
   

2. We have no test coverage to prove that base-path adds the correct cache. We only have coverage that both of them together add the cache context.

   +++ b/core/modules/system/system.tokens.inc
   @@ -37,9 +38,21 @@ function system_token_info() {
   +    'description' => t("The base URL of the site, currently: @scheme_and_http_post@base_path",
   +      [
   +        '@scheme_and_http_post' => \Drupal::request()->getSchemeAndHttpHost(),
   +        '@base_path' => $base_path,
   +      ]),
   

   I think we need to concatenate @scheme_and_http_post@base_path outside of the string. Ie.

     $site['base-url'] = [
       'name' => t("Base URL"),
       'description' => t("The base URL of the site, currently: @base_url",
         [
           '@base_url' => \Drupal::request()->getSchemeAndHttpHost() . $base_path,
         ]),
     ];
   

   That's because the current construction will make a replacement like this <em>scheme_and_http_post</e><em>base_path</em> - also scheme_and_http_post - post? :)

Addressing #62

Applied patch #63, Issues mentioned in #62 has been resolved
RTBC + 1

Patch in in #63 working fine for me

Patch applied to 8.9 and 9 and new token worked. I needed this for including urls in some emails.

Needs a re-roll.

Rerolled the patch in #63, thanks!

I have created an issue fork and merge request with the patch from #69.

The Patch #69 is getting applied cleanly, but I have a finding:
The method\Drupal::request()->getBasePath(); is actually not taking care of A scenario if /index.php is there in the url like http://localhost/web/index.php returns '/web' should return /web, but actually its truncating that and returning empty string , and because of that

  +    $request = Request::create('/index.php/');
  +    $request->server->add($server);
  +    $request_stack->push($request);   +    $this->assertEquals('http://localhost/subdir', $this->tokenService->replace('[site:base-url]'));

is failing tests.

I think Symphony Symfony\Component\HttpFoundation\Request has a missing condition.

if (empty($basename) && !strpos(rawurldecode($truncatedRequestUri).'/', '/'.$basename.'/')) {
                // no match whatsoever; set it blank
                return '';
            }

Please review !
Thanks

The Patch #69 applied successfully and the site base URL token available now.

Re-rolled for 9.3.x.

Good candidate for review pending discussion regarding scope of this core module vs contrib token module.

Note that we are recreating a similar thing for the Project Browser initiative, and I foresee this becoming more needed as we create more decoupled components.

https://www.drupal.org/project/project_browser/issues/3227738

I've read the comments and the current version of the code, everything seems to be squared away except for:

1. The fork needs to be rebased on 9.4.x
2. The change record needs to be updated to mention both the new tokens rather than just one.

I'd be happy to push it to RTBC if those are complete.

I've updated the change record.

Only the author of the MR can change the target branch, so @Liam Morland should do this.

Ok, looks good to me, test coverage was increased earlier and all the feedback has been addressed as far as I can see.

Setting to needs work to address the comment on the merge request.

D10 version needed
At this time we need a D10.1.x patch or MR for this issue.

Patch or MR doesn't apply anymore
The last patch or MR doesn't apply to the target branch, please reroll the code so that it can be reviewed by the automated testbot.

@Liam Morland, can you update the target branch to 10.1.x ?

#84 has been addressed, as has #88. I'm having difficulty comparing the current state of the MR to what it was last time I made this RTBC because of the rebase, but the code looks good and tests are passing so I'm gonna call this RTBC again.

Committed 84a67e9 and pushed to 10.1.x. Thanks!