Hi there! We’ve longed talked about how to be able to link to content. Let’s make it happen!
Options:
provide advanced linking capability that would resolve links like node://content-node-identifier to links to the parent node and automatically append an anchor to it
store the links the way they are handled now, and just provide some UI on top: (i.e. node://document-node-identifier#anchor)
But the question is how to resolve anchor name from content node identifier. The obvious solution would be to make them the same, e.g. node://document-node-id#content-node-id. But such anchors would look ugly.
Alternative would be to create an extendable anchor link resolver, that would take a node and return the anchor.
Here is my take on this: It would be nice to have a way to do this. Ideally as it’s own package. Anchors are a fickle thing and people have many different wishes and requests around them, so whatever mechanism we build, some people will not like it also it inserts “magic” code to the frontend so I would like to have this enabled and happening automatically.
I also thought about if this is a feature that needs to go to the core not. I have some arguments, to put it into Neos.Neos or at least into a Package in the Neos Mono-Repo.
To provide a list of anchors we need a DataSource, that DataSource receives the target document node and returns a list of anchors of all content node children of that document node.
To make that possible we provide a NodeTypeMixin that provides the property with inspector config and serves as a marker interface for content that could be targeted as anchor.
Additionally we provide a Fusion prototype the can be used as a processor like the mentioned package provides.
Both, the Mixin and the processor should be part of the core IMHO to define the interface and best practice.
Then, we could either apply that to the Headline Node Type as an example or just document how to make Nodes anchor-linkable.
Until now, the anchor-id needs to be defined manually. But we clould provide a configurable way where this value is pre-filled on node creation. (like the possibility we have with node templates). This could be the “node-name” by default but configure to various use cases.
After a hangout with @christianm and @dimaip we come to the following conclusion:
We want to have linkable content nodes in favor of linking document nodes with an additional anchor (@dimaip’s Solution 1)
We would have configurable resolution strategy that would resolve anchors from content nodes and vice versa
By default anchor identifiers are stored in the content nodes like the uriPathSegment in the cdocument node
Anchorable content elements are identified by a NodeType Mixins. No content node type is marked as linkable by default, its up to the integrator to do that.
Rendering Anchor Links is done by a fusion processor, also up to the integrator to attach that to the content nodes that are marked as linkable.
In the linkeditor you can select document nodes and add a custom anchor via additional configuration or directly select linkable content nodes.
To Do’s:
Extend the URiBuilder to make it able to handle content nodes
I think that might be problematic. The UriBuilder is part of Flow and thus agnostic to nodes.
We could maybe adjust the infamous FrontendNodeRoutePartHandler but so far URI fragments (aka anchors) are not part of the routing cache - we would have to extend the UriConstraints for that, but I’m not 100% sure about the implications
OK. But we have to keep in mind that this service was never meant to be and should be simplified/removed with the reworked CR. The overhauled Routing with Context and Constraints was a preparation for that
