RFC: Improving & customizing uri path segment handling

Using Neos & Flow Frontend & Integration
1

After a client had the requirement to remove nodes from the path segments on url generation I had a discussion on Slack with Aske an Christian M. about how to improve the FrontendNodeRoutePartHandler to make it easier to do these things.

I implemented a simple working example for the customer where the editors can flag nodes and the url path segment of these flagged nodes will be ignored when generating urls or requesting their children. I call it hideSegmentInUriPath for now.
You can see the gist here: https://gist.github.com/Sebobo/4bd90b64573c2098fc5b
This modified handler is now already in use and seems to do it’s job.
I disabled the behavior in the backend so the editors can’t break anything and not to affect js.

But the discussion also showed that the getRelativeNodePathByUriPathSegmentProperties method of the handler could be improved in general.
Currently the function iterates from the site node by path segment into the children until it found all the nodes which are part of the route.
To make it work with leaving out nodes in the path I had to make it recursive and to go into all nodes which have the flag set as their children could contain the node I’m actually looking for.

This poses two problems:
On the one hand two nodes could now have the same url now if they have different parents, each with the flag set.
On the other hand the route part handling could become a performance problem with a lot of nodes where several first level nodes have the flag set.

A possible solution I want to discuss which could make things easier:

  • Not start with the site node but instead look in the node repository for a node matching the last url path segment.
  • This may return several nodes in different parts of the tree but that should be rare.
  • For each node go up through the parents and ignore the ones with the flag hideSegmentInUriPath set.
  • If it matches then we’re fine, if not check the next on in the list or return false.

This behavior should be relatively independent of the number of nodes and behaves linear in comparison to the recursiveness in my proof of concept.
And in there we could also provide a hook where developers can attach their own checks similar to my flag hideSegmentInUriPath. This leads to the next idea.

Make it easier to customize

It currently requires more code than necessary to customize the route part handling.

Possible use cases:

  • Leave out nodes in the path (as I already explained)
  • Set absolute paths (f.e. landing pages)
  • Set redirect urls for nodes (f.e. after a relaunch)

This could all be done in the handler if we provide some hooks in the right places.
But I’m not sure if these possibilities should become part of the core as it also allows
editors to create undesired behavior which could be hard to debug.

1 Like
2

One thing you didn’t mention is that there’s currently not a good way to find a node by it’s uriPathSegment property since it’s stored in a json array. This is the reason for the current implementation. There’s a change in review to improve that though https://github.com/neos/neos-development-collection/pull/1, which would make it possible.

However there is a potential performance issue with the other approach. If you have lots of document nodes in the database it can take quite some time to search through them to find those matching the path with a LIKE statement. In some cases it could be more performant to use the current implementation. Of course this can be solved with optimized with the proposed changes in Discussions - Neos Sprint 2015 - Frankfurt

3

I agree that we need to improve the core search API to implement this kind of feature with performance problem.