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.
- 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.