Limitations of Enterprise Search

Enterprise Search can improve the performance of search results for a WordPress site and is highly customizable, however there are some limitations and default behaviors that cannot be overridden.

• VIP does not provide a public endpoint for running searches. Enterprise Search relies on a secure API to provide a powerful set of capabilities. Therefore, Elasticsearch results are rather raw, and VIP does not recommend attempting to proxy the search results.
• Currently, the ElasticPress features Autosuggest, Comments, Documents, and Instant Results cannot be enabled for Enterprise Search.
• If a search query attempts to retrieve more than 10,000 documents (search results) from an Elasticsearch index, the query will instead fall back to a regular MySQL database query. Use of pagination for search results will not avoid this limitation and fallback behavior. This is a standard limitation in place to protect the performance and memory usage of an Elasticsearch instance.
• The arguments post__in, post_name__in, post_parent__in, or parent are unsupported for orderby. Use of these arguments will prevent a query from being offloaded to Elasticsearch, and it will fall back to a regular MySQL database query instead.
• A default character length limit of 510 is applied to users with an edit_posts capability and 80 for users without. The vip_search_char_length() filter can be used to modify these limitations to a character limit between 0-510.
• Data sync only syncs the SQL database of a production environment to a non-production environment. It does not create, affect, or modify any Elasticsearch indexes in the target non-production environment. The target environment’s Elasticsearch indexes must be created or versioned following the data sync.
• VIP applies rate limiting to protect the search services from instability caused by spikes in requests.
• To query for and obtain post data (i.e. search results) in JSON format directly from a browser or other client via an AJAX request, a custom, cacheable, API adapter route should be built to limit the types of queries that can be made, and use only the post IDs from the raw Elasticsearch results. Any other details from Elasticsearch should not be used for constructing a user interface. To obtain any additional post or comment details from WordPress (e.g. post title, URL, etc.), use WordPress’s built-in data access functions.
• _doing_it_wrong() calls are used throughout the Enterprise Search code to throw configuration warnings.