World-class WordPress search is no more reserved to Fortune 500 companies with WPSOLR

Is your search breaking your WordPress site?

Probably, if your site contains more than a few hundred posts or products, or if your visitors need find results with accuracy.

WordPress Search with MySQL

Image wpsolr-wordpress-search.png of Why WPSOLR?

To understand how WPSOLR can integrate Apache Solr and the WordPress search, let’s first dive a little bit in the hidden world of WordPress core features. If you spend a few moments understanding the following documentation, you will be much more well armed to setup WPSOLR. So, let’s go !

Here are the (simplified) standard WordPress search workflow steps, also represented in the cinematic above:

  • A page is loaded, for instance by a user clicking on a link on your website.
  • The WordPress core extracts the page url, with all it’s parameters. For instance: /?s=red+shoes&post_type=product for a WooCommerce search.
  • The url parameters are used to build a WP_Query object, a high level WordPress api to build SQL queries.
  • WordPress produces a SQL statement out of the WP_Query, and calls the database with the right SQL dialect (MySQL, PostgreSQL, …). This SQL is often complex, and merges results from several SQL tables (like products and attributes to retrieve the colour and sizes of shoes).
  • The WordPress database executes the SQL statement, and returns results, which are stored in the WP_Query object. Notice that sometimes only the results Ids are returned, which will lead to more SQL executed to get other results details.
  • WordPress will now load a php file, named a template. The template is stored on the current active theme directory. Which template is loaded depends on the standard template hierarchy (a way to link urls and template file names), or on the theme’s or plugin’s filters/actions. Notice that there are all sorts of search templates, from search.php, to categories lists, tags lists, and many others.
  • The template will now loop on the results of the global WP_Query object (the Loop), and use whatever it needs to present them (css, javascript, html, ….).

vs

WordPress search with WPSOLR

Image wpsolr-wpsolr-search-non-ajax-principles-1.png of Why WPSOLR?

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 WPSOLR 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.

MySQL is lacking pure full-text search

MySQL can retrieve the third cabinet of the second row. But it cannot retrieve efficiently the cabinet that contains a file with title "MySQL is not so good with texts".

MySQL is not the right tool

WordPress is entirely built on MySQL. Both for building pages and retrieving information in text.

But MySQL is a Relational Database:  it is built with the sole purpose of retrieving data from an identifier. 
For instance, retrieve the post with ID ‘345678’, and all its related image IDs.

Retrieving data from its text content is called “full-text” search. While MySQL comes with a full-text search extension, it was never built for that purpose.
Therefore, search in MySQL (and WordPress) is slow and inaccurate.
Image wpsolr-header-solr-elasticsearch-4.png of Why WPSOLR?
Image wpsolr-header-solr-elasticsearch-3.png of Why WPSOLR?

Solr and Elasticsearch, free open-source full-text software, leaders of the search.
Connected to WordPress with WPSOLR, they can make miracles.

Solr or Elasticsearch - full-text champions

When it comes to extraordinary search nowadays, two champions rise above the others: Apache Solr and Elasticsearch.

Both share the same engine, “Lucene”. 

Both are built for speed and search accuracy.

Both are free and open-source: you can install them on your server for free.

Both can be tuned with thousands of parameters: linguistic in 50 languages, facets, synonyms, dictionaries, NLP. And so on.

But, more importantly, bot are seamlessly integrated to WordPress, thanks to WPSOLR plugin. 

No other plugin does it: you can search with Elasticsearch in French, while searching in Japanese with Solr.

 

Why you cannot use a pure plugin

Pure plugins can improve your search speed and accuracy, up to a certain level only.
We can mention, amont others:
– Relevanssi
– FacetWP
– SearchWP
– AJAX Search Pro

The reason is that they still use MySQL to power your search. And as we mentioned, search is not the best asset of MySQL. It will break as soon as too much data is searched, or too many visitors are on your site. Which is bad, because you want more visitors, no?

But also, they simply cannot compete in terms of features and speed with Elasticsearch or Solr. Those 2 are beasts, built of 500K of lines of code, by hundreds of developers. And just for one purpose: providing the best search tool in the World.

So, instead of reinventing the wheel, WPSOLR chose to use Elasticsearch and Solr.

You get the best of the best, but with an easy touch. No need to be an expert in search.

And remember, we are there to configure your search with your trial. For free!

Image dave-NGea7mBq8Ak-unsplash-scaled.jpg of Why WPSOLR?

WPSOLR chose to integrate with the best of the best search technology. Rather than re-inventing the wheel.

Stronger and cheaper than you might expect

It’s pretty easy to be fast, on a very expensive server with only a few documents or a few concurrent visitors

But what if you have thousands, or hundred of thousands of documents or WooCommerce products like some of our customers?



And what if on Black Friday you suddenly get hundreds of concurrent visitors, but your search breaks your server down?



And what if you do not have yet the business to spend thousands each month on expensive dedicated hardware, or hosted services?

With WPSOLR, no worries!

  • Some customers live happily with hundreds of thousands of products, or posts, or topics.
  • Some customers have hundreds of visitors every day, without slowing down a bit.
  • WPSOLR requires cheap hardware, and not costly on-demand subscription.
Image damir-spanic-22L7do1cOho-unsplash-scaled.jpg of Why WPSOLR?

WPSOLR can search in huge quantity of documents, with large number of visitors, on a cheap hardware, for a small fixed subscription. What's best?

en English
X