Initiative: Improve search results in reference editor

The reference(s) editor has quite some limitations in bigger website projects. Currently it fetches all Node and Asset data as JSON and does some filtering in the frontend. If you have a lot of assets or nodes with similar names, you might not even reach the search result you need.

After a discussion on Slack, @christianm, @dimaip, @gerhard_boden and me had a video call during the Neos Sprint in Vienna. We came to the following conclusions:

  • For smaller websites with only a few pages and assets, the current state is ok.
  • For complex websites, an extended “search” interface as secondary editor should be developed.
  • @christianm already developed a custom solution for a client. This solution looks like the current reference editor, but opens as secondary editor in full width and the possibility to properly scroll inside lots of results. This very pragmatic approach is a good first step.
  • A solid solution for the problem would require an implementation using a search engine, e.g. Elasticsearch. This would be an additional requirement, but we think that websites affected (having lots of nodes and/or assets) will use Elasticsearch anyway.
  • It will be a challenge to do a search over both Nodes and Assets. Nodes are stored in the Content Repository, while Assets are stored in the database. (There are plans to store Asset Metadata in the Content Repository, but those are no short-term plans.) Elasticsearch allows having queries over multiple indexes, but still we would have to solve how to deal with the different schemas of Node and Asset.
  • Besides a search, it would be desirable to have Faceting (only showing Nodes, only Assets, only Nodes of a certain type, e.g. News).

We decided on doing some research about Link Editors and meet again for a second meeting as soon as possible. @lorenzulrich will check how other CMS integrate reference editors and post the findings here (similar to how @sebobo did it with the Redirect Handler UI).

People interested in the topic are very welcome to join the discussion and/or further video calls.



  • :white_check_mark: Distinguish different link types (Page, File, External URL, E-mail)
  • :white_check_mark: Allows adding different link handlers to any database item (e.g. News, Events)
  • :white_check_mark: Anchor linking possible (yet a bit hidden)
  • :x: No search (apart from the Suggest Wizard)
  • :x: Linking to other language only with additional extension


Not tested myself, but seen documentation at

  • :white_check_mark: Distinguish different link types (Page, File, External URL)
  • :white_check_mark: Has a search function


The extended reference editor looks like this:


  • :white_check_mark: Has a search function
  • :x: No way to link to an e-mail address apart from writing mailto: yourself.

Drupal 8

If the demo I used is correct, Drupal 8 offers no interface for internal linking without an additional plugin. You can however use a module such as Linkit:

  • :white_check_mark: Has a search function
  • :white_check_mark: Grouping by data type by default

Adobe Experience Manager

I have no access to an installation, but I found this screenshot. It seems to be a link plugin for the Touch UI:


In Joomla, the link editor does not seem to be able to link to internal pages. However, the Text Editor has buttons for different content types, such as articles, that generate a link to a selected article:

  • :white_check_mark: Has a search function
  • :white_check_mark: Extended search
  • :white_check_mark: Allows linking of pages in a specific language

Craft CMS

The type of content is selected before the link editor is opened:


“Link to entry” editor:

  • :white_check_mark: Distinguish different link types (Page, File, External URL, E-mail)
  • :white_check_mark: Search is available
  • :white_check_mark: Grouped by different content types (Entries, News, Services etc.)

This is a work in progress. Of the CMS listed here, I’m only familiar with TYPO3 CMS. If you have more insights into CMS mentioned here or have additions, please reply to the post and I will incorporate your findings. Thank you!

1 Like

Not completly related because it will not change the UI. But it brings more speed.
But then you need elasticsearch of course.

We have this issue in a current projet. We have a big content block collection and we need a way to help the editor create document with those content blocks.

  • Facet filtering
  • More contextual information about the search result
  • Speed

Hard to do :wink:

@christianm Did you have an exemple of the “full inspector” UI style ? I have the same idea, as we need more space to have facetting and search result in the same area.

You can use a custom secondary inspector for that like for media IMO.

Would be cool to have better readability of the results. I often add a custom field for editors so they can give special easily findable names for elements they often search to reference etc.

It’s a bit overkill in my opinion, using the full height of the inspector should be enough to have way more UI flexibility. If needed we can offer and full screen version, but I’m sure, the intermediate solution can solve lots of UX challenges.

I think the secondary inspector is actually the easier solution, as it could be optionally toggled.

The main UX problem I see is the width of the inspector and the length of text of the results. That cannot be solved by additional height.

oke I will try to make a batter for the search results
,best regards