FEATURE: New link value object for new link editor (inspector)

[mhsdesign]

In the Neos Ui neos/neos-ui#3996 will introduce a new LinkEditor based on the Archaeopteryx.

With sitegeist/Sitegeist.Archaeopteryx#44 the Archaeopteryx allowed not only to use the inspector editor for simple string values but also to use the Sitegeist\Archaeopteryx\Link value object which allows to store additional data from the LinkEditor like title,rel target and further.

Adapted to Neos this would look like:

My.Content:
  properties:
    link:
      type: 'Neos\Neos\Domain\Link\Link'
      ui:
        inspector:
          editorOptions:
            anchor: true
            title: true
            targetBlank: true
            relNofollow: true
            download: true

The link value object can be queried as usual. An example rendering would look the following:

link = ${q(node).property("link")}
renderer = afx`
    <a href={props.link.href} title={props.link.title} target={props.link.target} rel={props.link.rel} rel.@if={props.link.rel != []}>
        My Text
    </a>
`

As the Archaeopteryx will now be part of the core we must discuss how or if we should also support this new feature in Neos 9.1 already.

The reason this discussion/PR is opened here in Neos.Neos is that the value object is part of the NodeType definition and thus existential part of the content repository and nodes. Writing an importer would require to use the value object as well and depending on the Neos Ui package - which has no PHP API - is not correct.

Discussion

This change is not finished. With Neos 9 we have the asset usage for example which inspects all node properties to keep track of assets. This code would also need to be extended to look into this new value object.

When we think of relations from a node to another node - which is at the current form a link via node:// protocol well also quickly realise that this is flawed as we have no simple way to validate that all outgoing links still work or cannot warn or notify when deleting a target node. This is true for the ckeditor blob but for links as a simple property it doesnt have to be this way. Neos 9 introduced references with properties on the edge. A node to node link with properties like title,rel or target can FULLY be implemented via a reference instead. And its way easier to work with real reference nodes instead of fiddling with plain node:// strings or node strings that are encapsulated in a shiny Link object but just magic strings at the end still. The link editor obviously shines in that it allows to either reference a node or an external website or asset. References cannot to external websites but might be able to learn assets at one point. The question is if we should introduce the concept of an apparent shiny link value object to the core when we already know it's not the holy grail?

As well probably continue to face the issue of inline links in ckeditor text blobs and cannot define that primary usecase away ^^ well have to find a solution for this already. On the Dresden sprint the idea was to possibly introduce on every node a reference blob which contains entries for all used node links on that node especially regarding text blobs. But that reference blog could also track the references used in the inspector link editor and this way we could continue and be happy with a stupid Link object? :)

Also for handling this new object and correctly serialising that for the Neos Ui we need to merge neos/neos-ui#3723

-> We discussed that the primary use case is that one wants to define a link to somewhere. That might be an external page or internal. Either way the fact that its an internal node is usually not relevant to the integration as the node schema will be converted to an actual http link during rendering via ConvertUris. One rarely wants to have a node instance at hand here and thus actual reference edges might not be important except for the tracking of content. And for tracking node ids an idea is outlined above or we introduce an indexer like the AssetUsage

Upgrade instructions

Review instructions

Checklist

• Code follows the PSR-2 coding style
• Tests have been created, run and adjusted as needed
• The PR is created against the lowest maintained branch
• Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• Reviewer - The first section explains the change briefly for change-logs
• Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[mhsdesign]

as this resides in Neos it can be an generic uri but also something specific like a Neos asset uri or node uri.

we could add the following methods to simplify handling all cases:

public function extractForScheme(string $scheme): string|null
{
    if ($this->href->getScheme() !== $scheme) {
        return null;
    }
    return $this->href->getPath();
}

public function extractNodeAggregateId(): ?NodeAggregateId
{
    $rawNodeId = $this->extractForScheme('node');
    return $rawNodeId ? NodeAggregateId::fromString($rawNodeId) : null;
}

public function extractAssetId(): ?string
{
    $assetId = $this->extractForScheme('asset');
    // todo introduce value object
    return $assetId;
}

[mhsdesign]

Implemented in #5683

[mficzel]

Fine by 👀

[nezaniel]

nicely done