Contextual links destination uses internal paths, not path aliases

Hmm, I think this is the same behavior as in D7.

Another way to see it is that a redirect should try to redirect to the aliased version of it, instead of putting it in the destination.
I'm guessing that's why there are modules like redirect/global redirect.

Confirmed. Great catch.

Maybe it's better for contextual.js to get the destination from the browser rather than Drupal settings?

#2136507: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links introduced that behavior (to use currentPath from drupalSettings). The subtle difference is that that means that we now use:

$current_path = $route_match->getRouteName() ? Url::fromRouteMatch($route_match)->getInternalPath() : '';

whereas we used to use:

$this->destination = $this->urlGenerator->generateFromRoute('<current>', [], ['query' => UrlHelper::buildQuery(UrlHelper::filterQueryParameters($query->all()))]);

Therefore, I think we want to add something like currentPathProcessed. Rough patch attached.

So we have code executed on a lot of page requests, right? Let's see how much additional cost this needs.
Can we maybe move this to contextual module only? I could totally imagine that people turn off contextual module on production.

A single additional URL being generated needs profiling? Also note that this is merely reintroducing code that used to run anyway.

Also: I wonder what @nod_ thinks about using window.location.pathname. I currently can't think of a reason not to use that. That'd make all this much simpler :) Thoughts? I feel like I'm forgetting about some crucial reason to not use this?

I guess a reason why it was there is that people wanted to link to the path alias, even if you are on a non path alias page, which is, well, probably really helpful SEO optimization.

#10: contextual links are only for authenticated users. So I don't see how this can be related to SEO?

I'm just guessing.

I came to this issue in search of a problem with missing language path prefixes (e.g. '/fr/') since my editors were getting sent to '/node/123' instead of '/fr/node/123', which I reported here: https://www.drupal.org/node/2707879

In my opinion using aliased path is not an option for the contextual module here primarily because the aliased path can change. I verified that with patch 8 and trying to rename a node with an automatic alias which afterwards resulted in a 404. If the aliased path should be returned this would have to be done during the processing of the submission, the destination parameter has to be kept as an internal path.

#10, #11, #12,

A bit helpful for SEO. Because SEO also including sharing links. (But really a little only.) Also UX problems.

#14,
Yes, that's a case

Related, #2687453: drupalSettings.path.currentPath refers to the route's URL even when page is accessed through an URL alias

I just wanted to chime in that I solved this problem for a current Drupal 8 project using the Redirect module. After activating "Normalize aliases" in the Redirect settings the module redirects me to the aliased url after editing a node. It will also solve the problem mentioned in #14 so that if the alias gets changed by the edits I make to the node, I will still be redirected to the new alias.

So maybe this should not be a responsibility of the core functionality but of third party modules, as mentioned in #2?

I do not like to use the (aliased) pathname from the browser, I think something like en/node/XYZ is much cleaner.

The solution proposed by jherencia at 2707879#10 worked for me, patch in #12

For 8.5.6...

This is also an issue when configuring blocks from the frontend. If the block is assigned to /some-page and then you configure it from /some-page, after saving the block it redirects you to /node/123 (or whatever node ID /some-page has). And the block then does not show, unless it is assigned to both /some-page and /node/123. That's more than just annoying... it is bewildering to site editors..

For 8.6.12

Re-roll for 9.1x+

I have tested patch #34 manually and it reflects the changes in contextual links aliases instead using internal path of any node.
I have created a taxonomy with url alias and before patch, it was appearing taxonomy/1/edit but after patch, it is now showing url alias in destination of link.
Adding after patch screenshot for reference.

#14 sounds like this doesn't work with language prefixes

#18 points out that there's a contrib way to solve this - are we sure we still want to pursue this?

We need this change in the .es6 version, with the .js version generated from running yarn build

Patch for 9.5.2

Applies patch for core 9.5.2

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

This is tagged for needing tests which still need to happen.

Patch for 10.1.x as in the previous test the patch failed to apply.

It seems this has been fixed in 9.5.4+ and 10.0.4+ versions. Can we close this issue?

Closing as a duplicate of #2738547: Contextual Links do not respect parameters in the destination