automattic / elasticpress

A fast and flexible search and query engine for WordPress.

ElasticPress

A fast and flexible search and query engine for WordPress.

• Check out the ElasticPress Docs

Please note: as of ElasticPress 4.0.0 trunk is the stable branch, built assets were removed from the develop branch, a ZIP with the plugin and its built assets are available on the GitHub Releases page, and will include a build script should you want to build assets from a branch. As such, please ensure you have updated any references you have from master to trunk or to GitHub releases depending on whether you require built assets or not.

Overview

ElasticPress, a fast and flexible search and query engine for WordPress, enables WordPress to find or “query” relevant content extremely fast through a variety of highly customizable features. WordPress out-of-the-box struggles to analyze content relevancy and can be very slow. ElasticPress supercharges your WordPress website making for happier users and administrators. The plugin even contains features for popular plugins.

Documentation

ElasticPress has an in depth documentation site. Visit the docs ☞

ElasticPress FAQs and tutorials can be found on our support site. Visit the support site ☞

Requirements and Compatibility

Requirements

ElasticPress requires these software with the following versions:

• Elasticsearch 5.2+ ElasticSearch max version supported: 7.10
• WordPress 5.6+
• PHP 7.0+

Compatibility

The WooCommerce feature is compatible with the last two major versions of the WooCommerce plugin.

Building Assets

Simply downloading the repository files is not enough to have the plugin working, as CSS and JavaScript files are built during the release process. If you want to use a development version of the plugin you will to run:

npm install && npm run build

Node.js (v14) and npm (v8) are required.

React Components

Interested in integrating ElasticPress in your headless WordPress website? Check out ElasticPress React.

Issues

If you identify any errors or have an idea for improving the plugin, please open an issue. We're excited to see what the community thinks of this project, and we would love your input!

Support Level

Active: 10up is actively working on this, and we expect to continue work for the foreseeable future including keeping tested up to the most recent version of WordPress. Bug reports, feature requests, questions, and pull requests are welcome.

Changelog

A complete listing of all notable changes to ElasticPress are documented in CHANGELOG.md.

Upgrade notices

3.5

Search Algorithm Upgrade Notice: Version 3.5 includes a revamp of the search algorithm. This is a backwards compatibility break. If you'd like to revert to the old search algorithm, you can use the following code: add_filter( 'ep_search_algorithm_version', function() { return '3.4'; } );. The new algorithm offers much more relevant search results and removes fuzziness which results in mostly unwanted results for most people. If you are hooking in and modifying the search query directly, it's possible this code might break and you might need to tweak it.

4.0.0

Note that ElasticPress 4.0.0 release removes built assets from the develop branch, replaced master with trunk, added a ZIP with the plugin and its built assets in the GitHub Releases page, and included a build script should you want to build assets from a branch. As such, please plan to update any references you have from master to trunk or to GitHub Releases depending on whether you require built assets or not.

Contributing

Please read CODE_OF_CONDUCT.md for details on our code of conduct, CONTRIBUTING.md for details on the process for submitting pull requests to us, and CREDITS.md for a listing of maintainers of, contributors to, and libraries used by ElasticPress.

Like what you see?

elasticpress's Issues

Returned posts from ep_integrate=true are missing guid

https://github.com/Automattic/ElasticPress/blob/develop/includes/classes/Indexable/Post/QueryIntegration.php#L359-L401

$normal_query = new WP_Query( [ 'p' => 7369046 ] );
$normal_query->posts[0]->guid;
=> ""https://example.com/?p=7369046"

$es_query = new WP_Query( [ 'p' => 7369046, 'ep_integrate' => true ] );
$es_query->posts[0]->guid;
=> "" :(

Need to make sure no other fields are missing as well, so logging here for now.

Side note: Really prefer the way es-wp-query just takes that IDs from the es results and then fetches accurate objects from SQL afterwards. Ensures things being returned are up to date, in case of index falling out of sync on an item. Especially in cases where not all meta/terms are indexed on purpose, but still might need to be fetched alongside the object being returned.

Sticky Posts logic is pretty broken

Here, EP attempts to add a weight to sticky posts if on doing the homepage query: https://github.com/Automattic/ElasticPress/blob/develop/includes/classes/Indexable/Post/Post.php#L1188-L1217

This is how the core WP Query does it: https://github.com/WordPress/WordPress/blob/6b7ba33d6851fea58bc3214c2b9e4316aa918fa5/wp-includes/class-wp-query.php#L3131-L3133

I believe the checks in EP are not sufficient / errorsome, and should be more along these lines:

$sticky_posts  = get_option( 'sticky_posts' );
$on_first_page = ! isset( $args['paged'] ) || $args['paged'] <= 1;
$ignore_sticky = isset( $q['ignore_sticky_posts'] ) && $q['ignore_sticky_posts'];

// Check first if there's sticky posts and show them only in the front page.
if ( is_array( $sticky_posts ) && ! empty( $sticky_posts ) && is_home() && $on_first_page && ! $ignore_sticky ) {

Furthermore, these tests are broken / not actually testing anything: https://github.com/Automattic/ElasticPress/blob/develop/tests/php/indexables/TestPost.php#L4102-L4142. The second testStickyPostsExcludedOnNotHome test also falls into the same issue as #63 - it will sometimes fails if based on if the posts share a timestamp or not.

The tests are really meant to be testing the prioritization of sticky posts, but first need to of course send that test home query to ES. Something like this:

public function testStickyPostsPrioritizedOnHome() {
	// Setup three posts, with the sticky post chronologically in the middle.
	Functions\create_and_sync_post( array( 'post_title' => 'Post 1', 'post_date' => '2020-08-25 12:30:00' ) );
	$sticky_id = Functions\create_and_sync_post( array( 'post_title' => 'Post 2: Sticky', 'post_date' => '2020-08-25 12:31:00' ) );
	stick_post( $sticky_id );
	Functions\create_and_sync_post( array( 'post_title' => 'Post 3', 'post_date' => '2020-08-25 12:32:00' ) );
	ElasticPress\Elasticsearch::factory()->refresh_indices();

	add_filter( 'pre_get_posts', [ $this, 'send_home_query_to_es' ] );

	$this->go_to( '/' );
	$q = $GLOBALS['wp_query'];
	$this->assertEquals( 'Post 2: Sticky', $q->posts[0]->post_title );

	remove_filter( 'pre_get_posts', [ $this, 'send_home_query_to_es' ] );
}

Just making this an issue for now, as it's turned into a bit more of a timesink than intended. If anybody else wants to work on this, be sure to make sure the tests can actually fail if the special sticky posts logic is removed, rather than just relying on WP_Query core logic to carry the burden.

Update EP_ES_VERSION_MAX ?

Currently this constant is set to version 7.5: https://github.com/Automattic/ElasticPress/blob/develop/elasticpress.php#L73-L74

If you run tests with ./phpunit-docker.sh then it spins up an ES containers running version 7.5.2: https://github.com/Automattic/ElasticPress/blob/develop/bin/phpunit-docker.sh#L20

Our mu-plugins lando environment sets up version 7.8.0 at the moment though: https://github.com/Automattic/vip-go-mu-dev/blob/master/.lando.yml#L45

As a result, there are some failing tests in the latter environment related to admin notices and whatnot.

Set ep_sync_terms_allow_hierarchy to false by default

https://github.com/Automattic/ElasticPress/blob/develop/includes/classes/Indexable/Post/Post.php#L519-L526

This feels like behavior that should be opt-in rather than opt-out. It changes functionality of queries rather significantly, as before offloading to ES you would only be receiving posts actually attached to a term. But with this enabled - you can get a much more wide range of posts with no way to filter it down since all terms are treated the same in the index.