bbPress deviates from WordPress's search functionality just a bit, so it's worth making a dedicated issue for it here.

Thankfully, bbPress topics and replies are just post types, so it's easy enough to grok. Providing fast and reliable relevancy-based results in a forum dramatically improves user experience, and the effectiveness of searching what can oftentimes be hundreds of thousands of posts.

Moderators could even have a control panel allowing them to weight certain terms in certain forums or categories, knowing that words and phrases are likely to be reused often in certain sections of the forums more than others.

Cron schedule not setup properly. This is completely breaking cron syncs.

http://d.pr/i/3gmR/n95jKgwY

A thorough code review is necessary before we can launch 1.0. Making an issue here so we can assign it to someone, track progress, and mark it resolved when 1.0 launches.

Use assoc args.

Possible things to think about are how to enable network wide setting pushes

For example use --network-wide

"ep_hidden" taxonomy is not necessary. Let's pull out it.

A dashboard widget with some statistical information would really help tie the room together:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-stats.html

Things like index name, meta fields to index, etc

This was intended to return a sub site's unique host and index_name values, however if they are not present it does return anything - which is not what we want.

This should fall back to the host site's information.

This new plugin is missing the functionality required to make autosuggest work, let's make sure to bring it over.

"search_author" should behave similarly to "search_tax" and "search_meta". Given a search string, it should search posts by author based on that string.

Currently only syncing on publish of post, but this should be done any time a post has been updated as new content may have been added to the post_content taxonomies or post meta data.

Title says it all. We really need unit tests to test more edge cases related to ES_Query and running searches against the Elasticsearch instance.

I'm still not sold that we need to be doing a DB insert for every post we sync. I'm not clear of what the benefits are over the increased cost of a full index.

I think a stress test to measure the performance between updating the last synced post meta and removing that bit entirely would be a good step in understanding just how much effect it truly has.

In addition, it should be remembered that the Elasticsearch data store should be considered somewhat volatile as opposed to the WP/MySQL data store which does all it can to never lose data. If Elasticsearch's data store gets wiped or needs a re-index, the post meta for determining the last sync time becomes irrelevant.

Elastic search is currently only used for improving the visitor experience. Is it possible to improve the accuracy of searches within wp-admin? Accuracy and performance of searching through posts, users, comments, etc... could likely be vastly improved.

Rather than submit posts for indexing one at a time, it would be better to use the Elasticsearch bulk index functionality.

We will have to consider error handling when using the bulk api because it's possible that some posts don't get indexed and others do. Elasticsearch will tell us what happened but we will have to resubmit those posts for indexing.

Additionally, we'll need to be aware of the max post size on the server and the max amount of data elasticsearch/java can receive.

Clicking labels of post types should check/uncheck the associated checkbox.

Can pull from previous plugin - very nice to determine current status of Elasticsearch with your install

This should probably be called "search_meta" since we have "search_tax" for taxonomies.

Let's not perpetuate grammatical mistakes from core into our plugins. If there's a REAL reason we're doing this, I'm open to hearing it. http://www.englishforums.com/English/TheProperPluralFormStatusStati-StatiiStatuses/jwvp/post.htm

Via server side - but still an important thing to figure out is how we're limiting and controlling access to the Elasticsearch server. Currently we are proxy pass limiting access to POST - this does not prevent users from maliciously indexing data

Currently all requests fail silently without offering an explanation as to the cause. Instead we should aim to allow for easier debugging by offering an explanation to what went wrong.

Discussion as to how we'd offer debugging (straight error log for regular use / print to console for WP CLI) should be thought through before approaching this item.

From @ericmann's review:

Translated output is not escaped. The plugin should escape everything (including the output of core functions) and compatibility statements should be updated to reflect the requirement of necessary escaping functions.

BuddyPress components would hugely benefit from indexing of their content:

• Extended Member Profile fields
• Activity streams
• Username @ mentions
• Individual Groups and Members
• Private messages

The above list is loosely in priority order as I see it. Users ask for multifaceted member profile search constantly, and there just isn't a real solution out there.

Title says it all.

Like the title says - this would be a relatively straightforward process of finding relevant posts and spinning it into a 'related posts module'.

Currently the sync is set for posts that are transitioning INTO the publish status, however this doesn't address items that WERE published but are being moved to a draft or private status (or anything other than publish). These items should be removed from the index as they are no longer available for searching.

From @ericmann's review:

Certain locations of the code (like EP_Sync_Manager::action_sync_on_transition()) are using type coercion for checking things like post status. Strict equality (=== and !==) should be used wherever possible and type coercion only when necessary (and documented).

These values never get stored and thus in the get_option function they will always return blank.

If cross-site setting is saved on multisite, network deactivated and then re-activated on a sub-site, cross-site is still enabled and the settings page only shows on the network settings page and not the sub-site.

This should behave in a more expected manner and if activated by a sub-site, not automatically re-enable cross site search, and should show itself on the sub-site admin panel.

We need a nice README.md as well as readme.txt.

I would really like to get back to having the plugin automatically fall back to WordPress's default search when possible. If the only reason we're creating an ES_Query is for multisite we allow it but don't make it the required route.

Currently remote requests check to ensure that a WP_Error is not present, but do not check the HTTP response code to ensure an ok response was received.

This should be handled to ensure that we receive proper responses from the Elasticsearch server.

From @ericmann's review:

I notice that, while the plugin declares 3.7.1 compatibility (Travis.yml), it also declares a PHP 5.4 requirement. General plugin distribution should be PHP 5.2 to match WordPress requirements. If this is just for tests, that’s fine, but when developing against PHP 5.4 and supporting 5.2, it’s easy to let newer code syntaxes slip through that will brick an installation.

Right now all terms of all taxonomies of a post are indexed. Only public taxonomies terms should be indexed.

The function ep_full_sync actually calls do_scheduled_syncs. Unfortunately this forces us to first schedule a sync event which in cases where we call from wp-cli, we would not want to do.

The logic behind actually doing a full index/sync should be abstracted out from the do_scheduled_syncs and placed into a function that does a full index that can be called independently and directly.

For reference: https://github.com/10up/ElasticPress/blob/master/classes/class-ep-sync-manager.php#L133

Record how visitors interact with ES: What they're searching for, what was returned, perhaps what they clicked on as a result.

Submitted by @tddewey.

Great idea - would love to see this reported in a cool dashboard widget even.

Due to an unknown reason, the sync button does not work on my local install. Not only does it not work, but it says it's been syncing for the last two weeks.

We should detect if we're not going to be able to sync for some reason (i.e. wp-cron isn't working or whatever the issue) if possible and prevent syncing from happening or find some other approach.

Additionally - there should be some sort of status check to cancel a sync if it has gone over an abnormal amount of time and if there has been no progress.

Port from EWP

From @ericmann's review:

No textdomain is set up (though some strings use elasticpress) and not all strings are localized. Even though cron descriptions are an internal tool, strings in places like EP_Cron::filter_cron_schedules() should be localized.

Indexing a post type, then deselecting that post type to be indexed could leave incorrect post types in the ES index if a full sync is not performed.

Double check that search is being performed only on current post types (pretty sure this is the case, just want to double check) and should look run a full post type delete from index on save of new post types.

Will have to be careful with this one, as general terms should still return a list of results, however - in some cases it would be helpful and effective to skip the results page and go directly to an individual post.

I'm thinking if they select an autosuggested post title, or if the relevancy score is high enough, then bypass result page and head to post. (Could possibly even provide a helpful link to the results page)

Having to query each site every time causes a noticeably slow user experience on the admin page. Would be good to cache this in settings and inject/remove post types once the query has been performed (possibly also cache this for a small period of time and invalidate on permalink/rewrite flush).

@AaronHolbrook were you planning on doing this?