Hash link does not work

[jonnitto]

If you have an link with an hash (e.g. #newsletter) the editor returns following error:

Could not find an editor suitable for "#newsletter"

And if I try to click + Create Link I got the error:

TypeError
can't access property "useResolvedModel", linkType is null

[mficzel]

@jonnitto We cannot reproduce this. Can you provide more informations

[jonnitto]

First, it is not possible the set hashed links:

Second, if you set a default value in the yaml file, you'll get this error

[mficzel]

Ahh now i got it ... you can workaround that by linking the current document with an anchor. Not exactly the same but close enough for now i assume.

[jonnitto]

For me yes, for a customer not…

[Benjamin-K]

We have the same issue here. We have some urls to pdf documents prepended with a hash. For example sth. like this:
/_Resources/Persistent/2/8/3/4/28345d78a243cfe0b9e6c89709e996d3e2e3dad5/Bericht-xyz.pdf#page=7. These links come from the "old" link editor. As there is no anchor option for media files, this can also not be solved without additional workarounds (for example by adding an additional shortcut to the linked pdf).
As the backend has an other domain than used later by frontend users, we can't prepend that uri with the domain and add the anchor there.

[Benjamin-K]

For the issue pointed out by @jonnitto, i think this can simply be prevented by adding some checks before allowing the customer to save the link:

• weblink must not start with a hash
• weblink must start with a domain (some regex like ^([a-z0-9][a-z0-9-_]{0,61}[a-z0-9]?\.)+[a-z]{2,})

[mhsdesign]

As there is no anchor option for media files

but this is a matter of definition:

Sitegeist.Archaeopteryx/Neos.Ui/core/src/application/LinkTypes/Asset/Asset.tsx

Line 17 in a003751

supportedLinkOptions: ['title', 'targetBlank', 'relNofollow'],

we could allow anchors on assets.

But this is rather a super edgecasy thing ...

About johns problem: Currently its not anticipated that the host is empty but the anchor is set. Instead of treating the href (protocol + host + path + anchor) as one unit, we allow the anchor to be specified as additional options. But this requires the protocol and host to be present.

[Benjamin-K]

But this is rather a super edgecasy thing ...

It maybe is, but it is not disallowed to use anchors in assets and as you see above, there are valid cases where you might need them.

Example link: TransnetBW Nachhaltigkeitsbericht (Seite 6)

And as it might brake the editor if you switch from the "old" editor, i'd rather prefer adding it then having a bad editor experience, where a developer is needed to fix the link.

[lorenzulrich]

Could this be solved using a custom link? #27

[Benjamin-K]

The problem in our case is, that the Backend-Domain is different from the Frontend-Domain. Therefore we can't simply set a custom link, as we need to set the domain there and on the live-domain that target may not exist yet.

And: When switching from the "old" editor, i'd expect such links to still work and not show an error.

To solve the problem @jonnitto has, an editor should at least be able to add relative links. Then it should be possible to create links like /link/to/page or #newsletter or whatever is needed. I think in @jonnitto's case, all links that have the hash newsletter will open some subscription form or sth. That's a rare but still valid case...

[lorenzulrich]

@Benjamin-K I see, now I get it. In the core LinkEditor, it is possible to add a hash to the node://abcd value.

This also means that the package wouldn't work with https://github.com/flownative/neos-anchorlinks.

To me, the most beautiful solution would be the ability to select any content node inside a selected page as link target. However, since Neos doesn't define the frontend output, this would only work if the id="foo" attribute is added to the container of each content node type - which is why this might not be such a good idea. Furthermore, I assume #newsletter in @jonnitto's case is a div that's not a content element, but somewhere in the footer.

So maybe a configurable (disabled by default) separate "anchor" field (or "link parameter") would be a good solution?

[lorenzulrich]

Example:

[Benjamin-K]

@lorenzulrich Sry, you were right. The CustomLink will work for us, but it is a little complicated to enter the correct link. So i would still prefer adding a field Anchor for links that are set from the sidebar. In our case, some old links are currently broken in the backend (unable to edit them), because they were links like asset://<identifier>#hash, see screenshot:

[lorenzulrich]

@Benjamin-K I agree that this should be addressed if this package should go into the core - especially if it will work as drop-in replacement. But I think @mficzel would need to agree with a solution to the problem since it is Sitegeist's package.

[mficzel]

I think the custom link as defined here #27 is a good solution. Having yet another extra tab "Anchor" or similar will confuse as many editors as it will help.

[Benjamin-K]

@mficzel I totally agree, that we should not add another new link editor to this package. The CustomLink solves the original issue described here. But the edge cases mentioned by @mhsdesign are still valid and will break the backend for some users in some places, of they use node or asset links with a hash in the sidebar. So yes, no new tab please! But this editor should keep links working that worked in the old editor.
Shall we create a separate issue for this?

[lorenzulrich]

@mficzel As you can see in my screenshot, it would not be an extra tab, but an extra property in the existing tag. This is just a suggestion. But maybe @Benjamin-K and we should open a new issue for this.

[jonnitto]

There is also a new package in the wild: https://github.com/PaesslerAG/Paessler.Anchorlink

I think it would be nice to make Archaeopteryx extendable with own packages…

[rolandschuetz]

@lorenzulrich @mficzel I have created a new issue #59 for the sub-problem mentioned here about existing links and a breaking editor, and a fix #60

[Benjamin-K]

@mficzel Could the linked PR #60 be merged?