Interface for search providers
These providers will be implemented in apps, so they can participate in the global search results of Nextcloud. If an app provides more than one type of resource, e.g. contacts and address books in Nextcloud Contacts, it should register one provider per group.
- getId() : string
- Get the unique ID of this search provider
- getName() : string
- Get the translated name of this search provider
- getOrder() : int|null
- Get the search provider order The lower the int, the higher it will be sorted (0 will be before 10) If null, the search provider will be hidden in the UI and the API not called
- search() : SearchResult
- Find matching search entries in an app
Get the unique ID of this search provider
public getId() : string
Ideally this should be the app name or an identifier identified with the app name, especially if the app registers more than one provider.
Example: 'mail', 'mail_recipients', 'files_sharing'
Get the translated name of this search provider
public getName() : string
Example: 'Mail', 'Contacts'...
Get the search provider order The lower the int, the higher it will be sorted (0 will be before 10) If null, the search provider will be hidden in the UI and the API not called
public getOrder(string $route, array<string|int, mixed> $routeParameters) : int|null
- $route : string
the route the user is currently at, e.g. files.view.index
- $routeParameters : array<string|int, mixed>
the parameters of the route the user is currently at, e.g. [fileId = 982, dir = "/"]
Can return null
Find matching search entries in an app
public search(IUser $user, ISearchQuery $query) : SearchResult
Search results can either be a complete list of all the matches the app can find, or ideally a paginated result set where more data can be fetched on demand. To be able to tell where the next offset starts the search uses "cursors" which are a property of the last result entry. E.g. search results that show most recent entries first can look for entries older than the last one of the first result set. This approach was chosen over a numeric limit/ offset approach as the offset moves as new data comes in. The cursor is resistant to these changes and will still show results without overlaps or gaps.
See https://dev.to/jackmarchant/offset-and-cursor-pagination-explained-b89 for the concept of cursors.
Implementations that return result pages have to adhere to the limit property of a search query.