Given

• a setup with languages 'en' and 'de', having a fallback 'de -> 'en'
• a node existing in 'en' that is changed in 'de'

Now the check for an existing node in createRedirectsForPublishedNode() will never find a $targetNode and return early.

✅ For a deletion this is fine (for now), as a node visible via fallback cannot be deleted.
❌ For a changed uriPathSegment a new node is created but no redirect is set up.
❌ For a moved node a new node is indeed created, but again, no redirect is set up.

Still figuring out the details but having this package in an installation reproducably leads to nodes being lost after moving subtrees. The result of this error will be that after publishing the subtree is back in it's old place while one leaf node is completely lost. Looking at the database reveals it was moved to the correct location but as parents are not in place it is no longer accessible.

At this moment I would advise to uninstall the package immediately until the issue is resolved.

General

In a multi site environment it would be very handy to be able to exclude nodes with a certain nodePath. This would give you the possibility to exclude entire sites from the redirect handler, what is perfectly fine somethings.

If you rename A to B, the redirection A -> B is created. Now rename B -> A ... the previous redirection is remove, but no redirection B -> A is created

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?

The other day I asked in the neos-slack: "Hey guys, I'm currently making a website multi-language with content dimensions. I'm also using neos/redirecthandler-ui (1.1.3). Do I need to explicitly change configuration if I want multilanguage and the rewritten urls (with the language specific path segments like /en/) to work with the redirect stuff?"

To answer this question https://neos-redirecthandler-adapter.readthedocs.io/en/stable/ should probably include a small remark about this.

Situation: We habe an instance with about 600 possible dimension combinations and deep page trees.

When publishing a page which is a root page of some deep page branch, the neos redirect service slot consumes a lot of time.

The bug seems to be that

 $newUriPath = $this->buildUriPathForNode($node);

and

$this->buildUriPathForNode($nodeInTargetWorkspace);

builds two different node paths. One beeing the live path and one the internal path:

Example:

/produkte/praxissoftware@user;country=deu&language=de !== /deu_de/produkte/praxissoftware.html

This leads to a recursive run through all children and creating pending Redirects for all child documents

When publishing nodes in a multisite environment with Neos 7.3 via CLI creates redirects with absolute source and target URLs, based on the primary domain of a site. This makes the redirect useless, as the redirect needs an relative URL for the source at least.

How to reproduce:

• Change uriPathSegment for a node in your workspace
• Run CLI command ./flow workspace:publish --workspace user-myusername
• Check generated redirects

For some reason the UriBuilder ignores the provided flag createAbsoluteUri = false. Not sure if this is an issue of this package or a Neos bug.

When publishing nodes within a dimension that has a fallback dimension, currently false redirects are generated which have the node from the fallback dimension as source URI and the current node as target URI.

How to reproduce:
For example we have DE and EN as language dimension (EN is the fallback dimension for DE) and a we are on test.html. We publish /de/test.html to the live workspace and now the following (incorrect) redirect will be created /en/test.html -> /de/test.html. The same will happen for all document child nodes. No correct redirects will be created for DE though (see #6).

So this won't cause too much damage, as long as en/test.html leads to the correct node in the englisch dimension no redirect will be called.

In the next scenario we get to the point where this bug is causing havoc on your existing redirects:
Imagine the scenario above, but in this case we have a redirect from our old website already in place:
/some-important-page -> /en/test.html

Now replay the scenario from above
/en/test.html -> /de/test.html

Since the redirecthandler-databasestorage will not store redirect chains (which is a good thing) the important redirect from the old website will now actually point to the node in the wrong dimension: /some-important-page -> /de/test.html. This will sooner or later (silently) happen to many redirects, since they are overwritten every time a node is published within the DE language dimension.

This bug will be fixed with:
#7

and is also covered in this test scenarios:
#8

The creating of 410-Gone status does not work anymore. I am not sure when and how this happened. I can confirm this problem exists back to Neos 3.2 up to 4.2. It is possible that the new-ui is somehow involved but i have no setups any more without the new UI to verify this.

I can confirm that the problem lies in the neosadapter and not the redirecthandler since existing redirects with 410-status are still rendererd.

The NodeRedirectService currently tries to render URLs for all to-be-published nodes as soon as the publish button is clicked.
If the node URL resolution fails (for example because it's a shortcut node without a valid target, see neos/neos-development-collection#3256) an exception is thrown and the publishing is prevented.

Instead the redirect creation should probably be cancelled in this case (and the exception logged potentially)

Publishing on CLI uses a http request

Call to undefined method Neos\Flow\Cli\CommandRequestHandler::getHttpRequest()
Type: Error
File: Data/Temporary/Development/Cache/Code/Flow_Object_Classes/Neos_RedirectHand
ler_NeosAdapter_Service_NodeRedirectService.php
Line: 492
neos/neos: 4.3.5
neos/redirecthandler-neosadapter: 4.0.3

I've tried to exclude these nodes of the redirect workflow but the exclusion only happens during the "createPendingRedirects" workflow. The above Error happens before in the "collectPossibleRedirects" workflow.

This is a multi domain and dimensions setup, not sure if this also important. Our usecase is an automatic importer for nodes given by external api. It would be also acceptable if the redirect management ignores the imported nodes.

The old nodeTypeConfiguration was replaced by the key restrictByNodeType.

I just ran into an issue which I file to not forget... Didn't really dig into it.

The issue is in the following lines:

The error:

Call to undefined method Neos\Flow\Cli\CommandRequestHandler::getHttpRequest()

Happens when nodes are (re)moved in an import I run on the CLI which is using the CommandRequestHandler which has no http request

It would be cool for the redirecthandler to be able to handle priorities - so that you can practically can handle advanced scenarios.
Example:
Website-Domain is example.com
A subdomain old.example.com should be redirected to the new website.
Therefore you need a bunch of redirects from subpages and after those one should redirect the subdomain itself (best case: with a catchall) to the new domain.

Steps to reproduce

1.) hide a document node
2.) add a redirect for that uri/path
3.) on request you still get the 404 response

Are there any reasons for that or is it a bug?

Tested with 4.0.3

Given you import a Node "Test A" programmatically to a Workspace "import".
And you publish this nodes in your CommandController or via command-line flow workspace:publish import.
Then you import to the same Node again, but with the Title "Test Aa" and again you publish from your CommandController or via command-line.

Expected behaviour:
A Redirect from en/test-a to en/test-aa is recorded.

Actual behaviour, at least in Neos 3.3:
A Redirect from ./index.php/en/test-a to ./index.php/en/test-aa is recorded using flow server:run.
A Redirect from /var/www/neos/en/test-a to /var/www/neos/en/test-aa is recorded in production.

Test CommandController (flow redirect:test --site-path-segment-name neosdemo):
https://gist.github.com/sbruggmann/e0b106fc8b148d7cedb8e84a74748ab5

When changing URLs linked between two sites in a multi-site setup, the redirecthandler creates wrong redirects.

How to reproduce

1. Use a multi-site Setup with at least two websites and configured URLs
2. Create a ShortCut node in Site A (site-a.com) with a Link to a some Url on Site B (site-b.com) (e.g https://site-b.com/link.html)
3. Publish
4. Change the Link of the shortcut node in Site A to some different URL on Site B (e.g https://site-b.com/new-link.html)
5. Publish

What is the behavior

The redirecthandler creates a redirect entry for the Domain of Site A, but the Path of Site-B.
Moreover it tries to create multiple redirect entries, which lead to a "Duplicate entry" Exception on publish.

What is expected behavior

IMHO there shouldn't be redirects created at all, if the target of a shortcut has changed.

Solution

Maybe it is already a solution to exclude ShortCut-Nodes by default. But I'm afraid to miss a case where it might be useful.