url() should return / when asked for the URL of the frontpage

Just postponed 🐛 Unable to save '/' root path alias Postponed on this one so triaging it some.

Cleanup the issue summary would help. Started with the template.

Will also need tests.

Thanks @smustgrave. So @yogeshmpawar could you perhaps reroll this as MR and try to fix the remaining tests?

I created an issue fork on 11.x and applied patch "1255092-41.patch" by @yogeshmpawar.

Hm, Jenkins seems to be configured differently for 11.x? At least 1 PHPStan error, doesn't really make sense.

Changing to 10.1.x-dev

@Grevil: I think we should still target 10.1.x - if needed, we can switch later.

Alright, no chance to run the tests remotely on neither 10.1.x nor 11.x. I'll test it locally...

The patch had a breaking change in the constructor parameters, which of course isn't allowed, at least if it's not consistently changed.

So for now I reverted that change, but kept the class property:

  public function __construct(AliasManagerInterface $alias_manager) {
    $this->aliasManager = $alias_manager;
    $this->config = \Drupal::service('config.factory');
  }

Unsure what's the DI strategy here in core for this case, perhaps someone else could have a look?

I guess the tests should run now.

Believe should be targeting 11.x as that’s the latest development branch. And changes can be backported

@Grevil did you read #56?

Any good reasons why you broke it again later in https://git.drupalcode.org/project/drupal/-/merge_requests/4030/diffs?co...?

I don't think it's a good idea here to provide the generic config as 2nd parameter in __construct() in this class where there's no DI.
Of course I might be wrong, but please leave a comment here then to explain the reasons.

Since we are adding dependencies to an existing interface, I guess we need a change record as this is a breaking change.

@Anybody, the class you manually implemented the "\Drupal::service" call does indeed not implement the "ContainerInjectionInterface". But that's because it is a service itself and the dependency injection happens through the service.yml (see "core/modules/path_alias/path_alias.services.yml" -> "path_alias.path_processor").

Grevil → closed merge request !4031

From the MR by @Anybody:

Are we sure the $path is passed as /<front> indeed?
I didn't check that, but in the UI you typically use <front> without leading slash, so this should be double-checked!
Perhaps write a test for this to be 100% sure, if not yet existing.

This is definitely important as "/" is quite untypical!

I don't have much time the next couple of weeks, so if anyone could add a test for this and do some general clean-up, go for it!

Did not test

Issue summary needs updating
Change record
Release notes

Change record drafted: https://www.drupal.org/node/3362769 →
Release note added to the issue summary.

Still needs work for the CCF.

Will leave it ad needs work for the tests and issue summary updates.

I think this should not be in the path_alias module, which is now technically optional although most people are using it. It should be a separate event subscriber in core.

Solution:

1. Install and enable the "Metatag" module.
2. Configure the Metatag module by navigating to admin/config/search/metatag.
3. Define a custom token for the canonical URL by clicking on "Add custom token" in the Metatag configuration.
4. Set the custom token as [node:url:absolute] for the canonical URL on the front page.
5. Save the configuration and clear the Drupal caches.

By following these steps, the Metatag module will allow you to define a custom token for the canonical URL. You can set this custom token as [node:URL: absolute] for the canonical URL on the front page. Saving the configuration and clearing the Drupal caches will ensure that the updated canonical URL settings take effect.

@DSushmita thanks for the workaround, but at least for the cases discussed here, #67 isn't a real solution. Still, it might help some folks.

What's everyone's opinion on @berdir's comment in #66? What would be a good place for this Event Subscriber, if we would move the implementation to core?

Another related one: 📌 Determine whether not only "/" but also "" should be valid input for the Link widget Active

Looks like duplicate but not really 🐛 setting path alias to `/` causes PHP8.1/str_starts_with/null error Needs work

manuel.adan → made their first commit to this issue’s fork.

Another approach made to this in branch 1255092-front_page_outbound_url_path_processor, based as well in URL processor but outside of URL alias as suggested by Berdir at #66 🐛 url() should return / when asked for the URL of the frontpage Needs work . I added outbound URL processing to the existing front page path processor.

It may fail in case of a front page path with query parameters were set, but it is also not well managed by other core parts like PathMatcher, see 🐛 Front page path with query parameters makes front path condition to fail Active . Added as related issue since support for query parameters should be added.

Will need test coverage and issue summary update.

Left some comments.

I'm asking myself if this could be fixed in contrib until it's solved in core one day.

Perhaps using OutboundPathProcessorInterface ( https://www.drupal.org/node/2238759 → )?
Any ideas? What do you think?

Sorry, three core tests are failing, and despite spending some time investigating, I haven’t been able to resolve it.

• Drupal\Tests\system\Functional\System\ThemeTest::testThemeSettingsRenderCacheClear
• Drupal\Tests\big_pipe\Functional\BigPipeTest::testNoJsDetection
• Drupal\Tests\path_alias\Functional\UrlAlterFunctionalTest::testUrlAlter