readthedocs.org
readthedocs.org copied to clipboard
Dashboard & Backend: Search configuration
Currently we have Search as an Addon that you can enable/disable. However, we should likely bring "Search" to a top-level setting in the project dashboard admin, and allow people to enable or disable it there for the whole project.
This would allow us to remove the files from the search index when the user disables search, and also remove it from site search, search API, and other places where we're exposing the search results.
I'm not sure if this is super related to https://github.com/readthedocs/ext-theme/issues/293, but since @agjohnson were asking about new potential settings, I'm pinging you here.
For purging search specifically, I would surface this in the version listing menu:
Or project listing menu if we can only manage a project level purge.
I do see how having a more top level project admin for some of the addons could make sense for some cases though, but I'd still probably keep addons specific configuration under the Addons admin panel either way. It would be confusing to split up addon settings like described here if we don't also have a top-level Flyout settings too -- that is, some addons configuration is top-level, some is under Addons.
Perhaps the Addons admin panel should be called something more user facing, like Documentation features -- this might help make our current admin structure more obvious.
I think we originally created this issue because we were creating a bunch of search indexes that nobody was ever querying. If we treat turning off search in Addons as disabling search indexing completely, this could work well. I think there are also some other search configuration options, like whether to include subprojects by default, but that is also mostly about the Addons UX.
If we treat turning off search in Addons as disabling search indexing completely, this could work well.
If go this direction, we need to consider that enabling/re-enabling search will need to trigger a search re-index for all the active versions of that project. Maybe not an issue, but something to consider.
Also, search is enabled by default --which seems to be a good default to me. I don't think we will save too much by doing it opt-out.
Yea, reindexing is definitely something we'd need to build if we made it able to turn off. I think that's probably good though. There's a bunch of people not using our search, so it would be good to save the resources of indexing if we can, but perhaps outside of the scope here? 🤷
Today we mentioned a similar scenario for File Tree Diff ignored files where people can define some files in the WebUI so they are ignored when rendering the UI element via addons. Note that even if those files are ignored, we still keep calculating the hash for them. This allows users to see the changes immediately without requiring re-building the documentation.
Things we can explore here:
- decouple search indexing from build process
- decouple file tree diff hash calculation from build process
- allow people to enable/disable search/file tree diff and trigger a task to re-index/re-hash all the active versions
This will help users to get immediate feedback about the feature they are enabling/disabling without having to re-build the documentation for all the active versions.
Edit: there is some related conversation here as well.