Custom backends
Algolia, Meilisearch and Local are all implementations of one PHP interface, Tangible\SearchSync\Backend\Backend_Interface. To connect another search engine, implement it and register your class.
The interface
| Method | Returns |
|---|---|
id() | A unique id, such as my-engine |
label() | A display name |
capabilities() | Which features it supports: facets, typo_tolerance, server_side_search, secured_keys |
save_objects( $index, $objects ) | Saves records |
delete_object( $index, $object_id ) | Deletes one record |
clear_index( $index ) | Deletes every record in an index |
list_indices() | The indexes that exist |
push_index_settings( $index, $settings ) | Applies searchable, facet and sort settings |
get_facet_attributes( $index ) | The attributes that can be filtered on |
get_facet_values( $index, $attribute ) | The values of one attribute |
get_sample_hit( $index ) | One record, for editor previews |
client_config() | The settings the browser needs to search |
Backends that can create per-user search keys or tokens can also implement Secured_Search_Interface.
Register it
use Tangible\SearchSync\Backend\Backend_Registry;
add_action( 'plugins_loaded', function () {
Backend_Registry::register( new My_Engine_Backend() );
} );
add_filter( 'tangible_searchsync_register_backend', fn () => 'my-engine', 10 );
A custom backend can't be chosen from the Connection Setup screen; the filter is the only way to activate it. SearchSync's own callback only supplies the saved choice when no earlier callback has returned an id.
Reads should fail softly
Admin screens reach your backend's read methods through an internal catalogue that catches errors and shows a notice, so a backend that's down can't lock anyone out of the settings they need to fix it. Write methods should still throw on failure, so lost data is never hidden.