Generally it’s not uncommon to me, that I would have to add the URI to the index in advance. For TYPO3 solr as example I write some TypoScript for the URI at point X and that’s all.
But when the SearchPlugin already delivers the neos_path, there must be another point of view.
Did really no one has a hint for this issue? I consider more options to handle that. But still don’t get it what to do with “neos_path” inside frontend (javascript; ajax). I have to assume, that I simply don’t understand a main point of it all (the neos_path? The routing? The search configuration?). I can’t explain it any other way, because it seems that I’m the only one with that problem.
Inside the ReadMe of Flowpack.SearchPlugin simply stands:
These can be used to provide autocompletion on the search input using a JS library of your choice.
I do. But the neos_path itself produce a 404. Beside the fact, that I don’t want to show internal node IDs inside the frontend.
There you see which fields are configured for the suggestions. You can add your own fields too, which you previously indexed. So to make the suggestions contain valid urls you need an indexing helper that generates and stores the required Uris with the indexed document.
I remember building all this with @daniellienert but I don’t remember anymore whether we put this helper into some package, or why we left it out.
It’s tricky to build an own URI Helper inside the backend context while indexing, because the UriBuilder always need a (controller) context. At first I got only backend-urls. But then I saw there is already a solution out there.
With the help of the OutOfBandRendering extension it’s possible to use some fusion code with a given node. The extension is adding the context by itself to get it work.