Debug with Search Dev Tools

Logged in administrative users can debug individual queries with the Enterprise Search Dev Tools.

Enabling Search Dev Tools

To enable the tools, please enable Enterprise Search per the documentation. The Search Dev Tools will be enabled by default on your site. This tool will be available in the admin bar.

Because of the need to display JSON, it’s not implemented as a Debug Bar panel. It operates independently from Debug Bar or Query Monitor.

General details

To use the tool, click the text. A large panel will cover the remainder of the page. It can be closed by clicking the x in the top right corner.

Search status area

The top area summarizes some search status information for the current site:

• Whether search is currently being rate limited (more info: https://docs.wpvip.com/how-tos/vip-search/rate-limiting/)
• Which post types are being indexed (more info: https://docs.wpvip.com/how-tos/vip-search/post-types/)
• Which post statuses are indexable (defaults to Publish)
• Which meta keys are being indexed (more info: https://docs.wpvip.com/how-tos/vip-search/post-meta/)

If the list of items is extensive, a click on each item reveals the details (example is based on this website):

Queries

Each separate Elasticsearch query that was run on the current page can be inspected in detail by clicking the + icon

You can see the request payload that was sent to Elasticsearch, and the response payload that it sent back.

When there are search results, that will be indicated and the response hits will contain those matches. In the example above, there were 48 results matching the import keyword.

Query context details

Often, in addition to seeing the query request data, it’s useful to see the WP_Query object attributes and the stack trace.

These can be inspected by clicking the headings at the top of the section:

WP_Query will present the details of the WP_Query object just before the Elasticsearch request.

Trace will provide a stack trace up to the point of the request, which should reveal which functions were involved in constructing the query, and which functions invoked the search.

Editing requests and testing changes

If you’re familiar with Elasticsearch 7.x request formats, you can edit the request and test how changes to a request affect the search results.

For example, in this result that brought back 48 matches, the sort order has been changed to “asc” from the default “desc”

Once the request has been edited, the run and reset buttons will appear.

When you click run, the Result area is updated with the new result. The hits array that contained 48 entries still contains all, but they are in the reverse order; the least relevant match is first.

This will not actually change the rendered page, but provides a way to validate a possible query change before going into the PHP code and modifying the WP_Query arguments, or a pre_get_posts filter, or another more advanced Elasticsearch filter.

You can change any portion of the request this way. Reset will restore the original JSON request and response.

Is Search using Enterprise Search?

To check if your site is properly offloading its search functionality to Enterprise Search:

1) On the front-end, search for a word present in one of the posts (e.g. “example”):

2) Click on Search Dev Tools and expand on the query itself:

If you see the search term as part of the “Request”, it is confirmed that your search is being offloaded to Enterprise Search!

3) If you do not, you should expect to see the below query in Query Monitor > Queries:

If you don’t see the above query, it might be cached in object cache and may need to be flushed:

wp cache flush