I know this feature was only just implemented (and I’m grateful for it), but I already have a change request 
I feel this reindexing process should be automatically triggered by any item edit that would require it.
Why? because clients who edit items aren’t going to know or expect to have to reindex (and they shouldn’t have to).
I can’t think of any reason why you wouldn’t reindex after a change to an item and surely if there was a reason that would be the exception rather than the rule?
To avoid excess reindexing requests (if that’s an issue), perhaps some sort of throttling implemented so a new reindex request will only be made after X minutes of a previous request.
OR
Similar to BC, site reindexing occurs on a rolling basis every X hours - but only if there are items changed.
4 Likes
Agree completely Adam.
When I first noticed the issue it was intermittent. It was masked somewhat by a Liquid error that stopped some Pages ever appearing in Search Results.
Treepl worked on both problems and resolved the Liquid error. Site Search looked like it was fixed too for a while. When it reappeared it was happening every time.
I was advised there was no index process. When a Page or an Item was saved the index was supposed to update automatically. Server-Side Caching was thought to be the problem.
The Rebuild Index link was a work around.
There is no indicator to show that the Rebuild Index has been clicked. If you click it several times the becomes almost unresponsive (frontend and back end). There is an indicator that shows briefly to say the Index has been rebuilt.
I would much prefer an immediate Rebuild on Save. The Rebuild Index does work around the problem. I can work with that.
At the very least the Rebuild Index link should be made Inactive until the Rebuild index process is complete.
1 Like
Hey @Adam.Wilson
Noted - I will add it with the next “batch” of requests