During refactoring of the Neos.RedirectHandler.NeosAdapter package for Neos 9.0 I stumbled over the fact that the old package generates also redirect entries for changes on hidden nodes.
E.g.
Move a hidden node to another path
Rename uriPathSegement of hidden node
So I’d like to discuss, if this is a desired behavior.
Pros:
I can work on a hidden node (move, rename) and make it visible again with same behavior as for non-hidden nodes.
Cons:
What is the use case for that? Why should I hide a node, move it and make it visible again and expect users get redirected? This might generate more useless redirects as helpful ones as it also generated redirects for all child nodes.
As mentioned before, my main concern with the Redirect Package is the fact that we have to do a lot of guesswork.
E.g. when I create a page with subpages, publish it and immediately change it’s uriPathSegment, I might not want lots of redirects to be created at all.
Similar with this example:
What we sometimes call “hide” is actually a disable (and that’s how the event is called with Neos 9 and IMO we should reflect that in the UI as well).
I could even imagine, hiding (pun intended) disabled nodes from the document tree by default and adding some kind of “recycle bin” view… But I’m getting side-tracked: My point is that we simply can’t know whether the user…
a) …disables “campaign-22” to work on “campaign-23” and later wants the former to redirect to the latter
or
b) …copies a disabled node to start working on a completely new concept and an auto-created redirect would be totally unexpected
So my preference would be some kind of interaction, e.g. a dialog upon publishing You changed the URL of this document. Do you want to create X redirects from "/foo/bar/..." to "/foo/baz/..."?
Or, if that “workflow” feature is not feasible some dialog that pops up after publishing – or at least some button in the inspector that allows you to jump to the corresponding backend module with the form fields already filled out.
And if that’s all too complex, I would suggest not to automagically create redirects for disabled nodes.
I think it is fair to simply exclude hidden nodes from redirect creation and otherwise keep the current behavior.
Asking editors adds complexity for the UI but also to editors as they have to make a decision they may not expect or cannot answer right away. If we can avoid that i would like to keep it simple.
I also think that we can simply omit creating redirects for hidden nodes. But @bwaidelich made a good point:
Do we need to create redirects for recently published pages? Maybe we can add some setting for that. This could be a new setting or we use the enableAutomaticRedirects setting for that and extend the comment with sth. like “If this setting is set to a number, automatic redirects will be created, if the page(s) were published for more than the given amount of seconds.”
I would not suggest to make this even more clever and automated.
Also “recently” published gets blurry if you add intermediate workspaces to the mix etc.
A good option could be to have a configurable shelf-life for automatically created redirects. We can already specify the “active-until” field so we would only have to populate this field for automatic redirects.
Together with some cleanup cli command like remove inactive redirects this should help a lot to keep the redirect mess in check.
Redirects affect SEO and the content presentation so IMO an editor should be involved in all those decisions.
That “You just moved X pages, do you want to create Y redirects [yes] [no] [more details]” dialog after publishing seems like a sensible idea to me
I also think the user/editor shouldn’t care about redirects. Even if it creates a lot of maybe useless redirects, this is IMHO better than missing one important.
Also I found a “real” use case where handling redirects for hidden nodes might be needed (at least somehow). I see this a lot in some customers projects where nodes get moved into a “archive” for later reusage.
Consider following scenario where a node has been moved:
/some-parent/node-a → /some-other-parent/node-a
and afterwards I move it back: /some-other-parent/node-a → /some-parent/node-a
Node is visible all the time:
→ Redirect for first move was created
→ The first redirect get updated on second move
→ Node is accessable on /some-parent/node-a
→ Redirect from /some-other-parent/node-a to /some-parent/node-a exists
Node was set disabled before the first move, and set enabled before second move:
→ No redirect for first move
→ Redirect for second move was created
→ Node is accessable on /some-parent/node-a
→ Redirect from /some-other-parent/node-a to /some-parent/node-a exists
Node was set disabled before the first move, and set enabled after second move:
→ No redirect for first move
→ No redirect for second move
→ Node is accessable on /some-parent/node-a
→ No redirects exist
Node was set disabled after the first move, and set enabled before second move:
→ Redirect for first move was created
→ The first redirect get updated on second move
→ Node is accessable on /some-parent/node-a
→ Redirect from /some-other-parent/node-a to /some-parent/node-a exists
Node was set disabled after the first move, and set enabled after second move:
→ Redirect for first move was created
→ No redirect for second move
→ Redirect from /some-parent/node-a to /some-other-parent/node-a exists → Node is NOT accessable on /some-parent/node-a due to the outdated redirect
Beside the fact, that this can lead to unexpected errors, I think the outcome should be consistent anyway, independent of the visibility of a node. It’s hard to explain the user in which order they have to do hide and move operations - as it should not matter at all.
IMO you greatly underestimate editors
At least the editors I often work with are really concerned about which URLs lead to which content – it’s their bread and butter really.
Also, that dialog would only appear in the (hopefully rare) case that someone changes the uriPathSegment or moves document nodes.
Having said that, I totally agree that this should be configurable.
I think this is something we should address.
With the new CR we thought about ways to “stash” content (e.g. via a third option, publish, discard, stash all/selected changes).
I do like the idea of the dialog, as it makes the system obvious. The editor doesn’t have to know at first that redirects are created or needs to ask / test if this functionality is available, as the dialog will inform about the possible redirect.
Also as a technical person I would at first be sceptical if this automagically redirect thing works at all, but seeing the conformation in the Ui would ensure this to me.
An editor should be in charge of the content and has already control about where pages are accessible and how (uriPathSegment), also he can fully control this (by moving f.x.). I think it’s just a logical conclusion that he has to know about the complexity of redirects and control them. The tool is too powerful too be 100% perfect without human interaction.
It is not the editors we work a lot with that concern me. It is the ones that only work on the website from time to time.
Some are experts for something totally different and are tasked with updating the parts of the website that affect their main expertise.
Others are hired for specific tasks and may or may not have been briefed totally or be web experts.
I like the ease of use we can provide and that the main qualification for beeing an editor is writing skills and understanding of the visitors. Optimizing URLs and managing redirects imho is not a necessary skill for that.
Absolutely, I agree and you should have the choice (as discussed before).
My only point is: I don’t think that we can reliably and automatically do the “right” thing, especially when it comes to disabled nodes so I would suggest to add an optional confirmation step.
For that case to be “fixed”: Would it make sense to remove existing redirects (with confirmation) from the current node to some other URI if a node is enabled again and a redirect for the URI of that node exists?
