WPSOLR search is quite versatile, and can be declined in two flavours: Ajax, or standard (WPSOLR PRO only).

The standard flavour is described in this document.

The WPSOLR search with Elasticsearch / Apache Solr

A common usage is for WooCommerce front-end search themes, which contain highly specific e-commerce features that should not need to be modified or replaced. Think of the “Add to basket” buttons, the choice of listed or tiled view results, the sort list, the navigation bar. In that mode, WPSOLR is able to replace the way search is performed, without disturbing at all any of those features.

Now, if we analyse the WPSOLR workflow with that standard mode, as you can see in the following cinematic, it’s pretty obvious that the theme’s search template is acting as usual to display search results.

Standard (non-Ajax) WPSOLR search workflow.

Compared to the standard WordPress search, the steps which differ are:

• WPSOLR is replacing the WP_Query object with it’s own subclass object WPSOLR_Query.
• WPSOLR_Query is extracting parameters from the url, from WPSOLR PRO extensions, or from your own filters code.
• WPSOLR builds an Elasticsearch / Solr query with the Elastica php library / Solarium php library.
• WPSOLR queries the Elasticsearch / Solr index to get the documents that fit the query.
• WPSOLR extracts the documents ids.
• WPSOLR, with a single SQL statement, retrieves the post types (post, page, product, or any post type) from the WordPress database.
• WPSOLR “enhances” the post types content: geolocation distance, highlighted keywords in the excerpt, …
• WPSOLR stores the post types results

When the theme’s search template is loaded, it behaves as usual, unaware that the post types it gets from the WordPress standard  loop came firstly from an Elasticsearch / Apache Solr query.

How is it faster then ?

You probably noticed that now, 2 queries are performed instead of one in the standard search: one to the Elasticsearch / Solr index, and one to retrieve post types from the document ids.

Yet it’s much faster, because as soon as you get a significant amount of post types in your database (a few thousands, to many thousands), the Elasticsearch / Solr query is incredibly faster than a WP_Query SQL full-text search.

And the second query to retrieve post types from the ids is very fast too, as it queries on table fields ids, which are indexed.

The difficult job, the full-text search, is performed by Elasticsearch / Apache Solr, which has been built just for that.