Patching Discourse's search

Development

AI-generated summary

Patching Discourse’s Search

snoopdouglas is developing a plugin that stores extra user data and wants to make this data searchable. pmusaraj suggests extending the search functionality by adding an advanced filter, providing an example of how to do this. snoopdouglas asks if this approach will also include results in general searches, and pmusaraj confirms that it will.

sam notes that the if Search.respond_to? :advanced_filter protection is no longer necessary, as this API has been in place for a long time. snoopdouglas expresses concerns about the scalability of using PluginStore for storing extra user data, and sam advises against using PluginStore, recommending the creation of a 1-1 table for the extra user data instead.

1

I’m writing a plugin which stores some extra data against each user (similar to discourse-user-notes, but not staff-only), and would like to be able to search against this.

Presumably this involves patching something in lib/search.rb. I’m aware the Algolia search plugin overrides what appears in the search box popup, but ideally, I’d like this to affect the actual results page too.

Does anyone have any suggestions on where to start?

2

You can extend search from your plugin, for example you could add an advanced filter like this:

  require_dependency 'search'
  if Search.respond_to? :advanced_filter
    Search.advanced_filter(/with:video/) do |posts|
      posts.where("posts.cooked LIKE '%<video %'")
    end
  end

The above will only display posts containing videos when the search box includes the with:video keyword. See also the badge advanced filter for an example of a search query that takes user data into account.

3

Nice. Does adding an advanced filter mean that these results will also appear in a general (non-advanced-filter) search?

4

Yes, you can use an advanced keyword in the search popup as well as the full page search.

5

We don’t really need to carry this protection anymore, that api has been in place for a real long time.

6

On the subject, will PluginStore scale well here? I imagine this’ll lead to a lot of full scans (in the absence of a LIKE-friendly index on keys), so would it be better to create a 1-1 table for the extra user data?

7

PluginStore is to be avoided, roll out tables for your plugin.