The Link Editor is one of the most crucial editor in a CMS.
Ours is currently very straightforward but IMO it lacks some important features.
In general there are some UX issues with the current implementation in my opinion:



"Dear editor, this is how we internally store page links. Deal with it" :)
Lastly, it's currently not a trivial task at all to extend the current Link Editor.
It has been done by @dimaip for example but there is no API.
I would suggest to make "link types" an explicit (and extensible) concept.
This would allow us to provide (or reuse) a dedicated editor for each type:


Also folks could extend/limit the allowed link types to be used, for example to provide an easy way to link to product pages.
BTW: It's probably still useful to have a "search bar" immediately available for the "power users" and maybe that can be extended to provide support for special syntaxes like the search bar in Slack for example
Your scribble is basically the good old TYPO3 linkeditor ;)

But I agree, it would help make things clearer.
I think the biggest gain would be to "translate" the linkurl and suggestions to something human readable and give more space. Because that would also help in the inspector etc.
I'm not super into the tabs somehow.
Your scribble is basically the good old TYPO3 linkeditor ;)
Yep, that's what I had in the back of my head :)
Though the TYPO3 link editor is a little too low-levely IMO (CSS-Class, Link Parameters) and the "link type" API inofficial IIRC.
I'm not super into the tabs somehow
Yep, that's why I just created a mockup. I don't even want to _try_ to come up with a good UI for this. But it should be a different editor per link type IMO
Maybe you meant this Discuss post: https://discuss.neos.io/t/initiative-improve-search-results-in-reference-editor/4622/2
Maybe you meant this Discuss post
Yes, I think that was it. Thanks for linking!
I like the concept but not the tabs. They also could lead to conceptually errors as tabs lie in the inspector usually allow to fill values on multiple tabs which is no valid usecase.
It makes sense to specify what to link first (with default to nodes) and then show optimized controls. That would probably mean a select box or radios buttons for the protocol (http://, node://, mailto://, resource:).
On the long run the protocol list could be made extensible but for that the linkingService would have to be extended first.
I like the concept but not the tabs
I agree. In the mockups above the tabs should just represent multiple exclusive contexts
It makes sense to specify what to link first
Yes, that's true. Tabs didn't really communicate that. It's probably more like a 2-step wizard (if more than one link type is allowed)
I think the most pressing issue is the inability to link nodes form another site (without using absolute links). That is a big issue for every site that uses neos in a multi domain context. Basically this is currently not really possible without cluttering the database with static links.
It can be configured for all inspector editors like this, but not for the CKEditor Link Editor:
Neos:
Neos:
userInterface:
inspector:
editors:
Neos.Neos/Inspector/Editors/ReferenceEditor:
editorOptions:
startingPoint: '/sites'
And a big +1 for the extensible concept of link types. It would be great if we could keep the configuration options relatively in sync (as far as possible) with the options of the Reference Editor
It can be configured for all inspector editors like this, but not for the CKEditor Link Editor
@bweinzierl: Actually I think that this is not the case. You can set the startingPoint for links in the CKEditor in the NodeType definition like this:
'Vendor.Package:NodeType':
properties:
text:
ui:
inline:
editorOptions:
linking:
startingPoint: '/sites'
However, it is not (yet) possible to use ClientEval there, I already opened an issue for that.
FYI: https://github.com/sitegeist/Sitegeist.Archaeopteryx implements a great deal of features in a separate package
Wow, that's absolutely great!