When viewing an entity with an alias, the edit link sets the destination path using the system path, rather than the alias.

So after editing, the user is returned to the system path - e.g. node/1.

This is likely to be confusing and annoying for content editors.

For example, from a taxonomy term with the alias technologies/drupal, the edit link is taxonomy/term/11/edit?destination=taxonomy/term/11

Files: 
CommentFileSizeAuthor
#8 2639822-8.patch1.3 KBWim Leers

Comments

malcomio created an issue. See original summary.

swentel’s picture

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.

swentel’s picture

malcomio’s picture

Component: routing system » contextual.module

Having dug into this further, the problem here is specific to contextual links - if the "Tabs" block appears, the edit link doesn't explicitly set the destination of the edit form, but just takes you to node/123/edit.

In both D7 and D8, If you go to node/123/edit and save, you are sent to the aliased path as expected.

In D8, when you're viewing the node on its own page, the edit link that is provided by contextual links includes the unaliased path in the destination query string.

malcomio’s picture

Hmm, not so sure that contextual.module is the right component any more.

contextual.js gets the destination from drupalSettings.path.currentPath, which is set to the un-aliased path in system_js_settings_alter

$current_path = \Drupal::routeMatch()->getRouteName() ? Url::fromRouteMatch(\Drupal::routeMatch())->getInternalPath() : '';

Looks like currentPath is also used in toolbar and core/misc/active-link.js

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

Wim Leers’s picture

Title: Destination after editing entities does not use aliased paths » Contextual links destination uses internal paths, not path aliases
Priority: Minor » Normal
Status: Active » Needs review
Issue tags: +JavaScript, +Needs tests
Related issues: +#2136507: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links
FileSize
2.07 KB

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.

dawehner’s picture

Status: Needs review » Needs work
Issue tags: +Needs profiling

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.

Wim Leers’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests, -Needs profiling
FileSize
1.3 KB

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?

malcomio’s picture

Digging through the git history of contextual.js it seems like it's been using drupalSettings to get the current path since #914382: Contextual links incompatible with render cache.

I don't know the history of the render cache issue, but I can't think of a reason why we can't just get the current URL via Javascript.

dawehner’s picture

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.

Wim Leers’s picture

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

dawehner’s picture

I'm just guessing.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

grahl’s picture

Status: Needs review » Needs work

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.

droplet’s picture

#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

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

reekris’s picture

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?

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.