No redirect is created for shrotcuts

[gjwnc]

When you move a shortcut no redirect is created for the URL the shortcut was reachable before the move.

The reason is, that NodeRedirectService::createRedirectFrom compares the URI of the old and new destination. This URl is created via NodeRedirectService::buildUriPathForNode which uses the UriBuilder which in turn uses FrontendNodeRoutePartHandler::resolveShortcutNode to get the target URI. Now if you compare the target URI of a moved shortcut it does not change and no redirect is created.

I've fixed this in a project using an aspect for NodeRedirectService::buildUriPathForNode and using FrontendNodeRoutePartHandler::resolveRoutePathForNode(NodeInterface $node) via a new class inheriting from FrontendNodeRoutePartHandler to make the protected method resolveRoutePathForNode public via an intermediate method, like this:

class FrontendNodeRoutePartHandlerRedirectHelper extends FrontendNodeRoutePartHandler {
    public function publicResolveRoutePathForNode(NodeInterface $node){
        return $this->resolveRoutePathForNode($node);
    }
}

Shall I provide a PR for this case, by also using the FrontendNodeRoutePartHandlerRedirectHelper to get direct access of a node's path without using the uriBuilder in case of a shortcut? Tbh, I don't like my solution, but currently, afaik, there is no way to retrieve the URL of a shortcut itself. The uriBuilder always resolves the shortcut because of the FrontendNodeRoutePartHandler.
But I could provide a PR for Neos < 9 if requested. But I'm not sure how to create the PR, because branch 4.0 already contains changes related to Neos 9.
From reading the new Neos 9 FrontendNodeRoutePartHandler, the shortcut will also be resolve to it's final target, thus Neos 9 doesn't seem to fix this.
Any ideas on how to proceed?

[dlubitz]

@gjwnc Thanks for your issue. I've fixed the 4.0 branch, which had indeed commits of the 5.0 version, due to a wrong merge.

Regarding your proposal, i think it's not a viable solution to extend the FrontendNodeRoutePartHandler. But ATM I don't know a working solution to render the "real" URI of a shortcut node, as it is to deep in the routing. Moreover from my POV it's rather a bug, that you are able to call (resolve) the "real" shortcut node URI, than a feature.

[gjwnc]

Moreover from my POV it's rather a bug, that you are able to call (resolve) the "real" shortcut node URI, than a feature.

What do you mean? FrontendNodeRoutePartHandler::resolveRoutePathForNode($node) should be private?

[dlubitz]

No sorry, i mixed it up.
ATM you can match a given uri to a short cut node, so you get a Node from a uri, but you can't create that URI for a given short cut node.
Now you tried to solve that inconsitency by enabling the FrontendNodeRoutePartHandler to create that URI. But from my POV, we should rather disallow the matching of the uri. This wouldn't help you at all, but would be the better way in general.