10up / debug-bar-elasticpress

Extends the Debug Bar plugin for usage with ElasticPress

ElasticPress Debugging Add-On

Adds an ElasticPress panel to Debug Bar and/or Query Monitor plugins. Allows you to examine every ElasticPress query running on any given request.

Requirements

• ElasticPress 4.4.0+
• Debug Bar 1.0+
• PHP 7.0+

Usage

After installing and activating, click the Debug button in the admin toolbar. Within the Debug Bar Panel, click the ElasticPress panel.

Issues

If you identify any errors or have an idea for improving the plugin, please open an issue.

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 Debug Bar ElasticPress are documented in CHANGELOG.md.

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 Debug Bar ElasticPress.

Like what you see?

debug-bar-elasticpress's Issues

No option in Query Monitor Panel when Jetpack is activated.

Describe the bug

When the Jetpack is activated, ElasticPress option doesn't rendered in the Query Monitor Bar.

Steps to Reproduce

1. Activate the Jetpack
2. Go to Frontend and search any term
3. There is no option ElasticPress option in the Query Monitor panel

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

The plugin hasn't been tested with the latest version of WordPress

There is a new WordPress version that the plugin hasn't been tested with. Please test it and then change the "Tested up to" field in the plugin readme.

Tested up to: 6.3
Latest version: 6.4

This issue will be closed automatically when the versions match.

Copy and paste the full query panel info

Is your enhancement related to a problem? Please describe.

Currently, there is a "Copy" link per query to send to the clipboard the cURL request. It would be great if we could have a "copy" button that would copy everything: all queries and their args, body, and results. That would make things easier to share.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Incorrect spelling on class attribute.

Describe the bug

There is a typo in the class="" attribute which handles .ep-query-headers

Steps to Reproduce

1. Located in classes/class-ep-debug-bar-elasticpress.php
2. Line 124, 131, 138, 158

Expected behavior

The class attribute should be spelt correctly.

Screenshots

Environment information

• Device: Macbook Pro 16"
• OS: Mac OS X
• Browser and version: Chrome 89
• WordPress version: 5.7

• Plugins and version:
• Theme and version:

• Site Health Info:

Additional context

Use <xmp> for displaying JSON results instead of <pre>

Ah the long forgotten <xmp> element. It would be much better to use in the case for showing JSON responses from Elasticsearch because it treats markup as literal text. From the sitepoint reference: http://reference.sitepoint.com/html/xmp

Unlike pre, xmp element treats markup characters as literal text. This makes xmp useful for development - e.g.for testing output from PHP that may contain markup, where you want to see the markup as code.

I'm working on a site with some cruddy markup in the post_content so looking at the query result comes out like this https://cloudup.com/ctgszL4-2Nc

Provide an easy way to see how a document is indexed

Is your enhancement related to a problem? Please describe.

ElasticPress 4.7.0 has a new WP-CLI command (wp elasticpress get post <id>) that makes it easier to check how a document is indexed in Elasticsearch. It would be great if we could provide something like that in Debug Bar EP as well, so people don't need access to WP-CLI to check it.

Designs

No response

Describe alternatives you've considered

We could add a new button to trigger that. We already have "hidden" parameters like explain that, if added to the query string, makes ES explain the query. Nobody uses that because it is not documented anywhere obvious and also, we don't expose that in any way on the screen. Perhaps a new section with buttons like Explain queries and Query document from ES.

Code of Conduct

• I agree to follow this project's Code of Conduct

Packagist? Why not?

Why is this package not registered in Packagist so that it is easy to add it via composer inside a WordPress composer setup?

Bump Versions

Is your enhancement related to a problem? Please describe.

Let's bump the minimum versions to:

• PHP 7.0+
• EP 4.4.0
• Debug Bar 1.0+ (this remains the same)

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Test against WordPress 5.8

Is your enhancement related to a problem? Please describe.
Once WordPress 5.8 is released, we'll want to test Debug Bar ElasticPress to see if any incompatibility issues arise.

Describe the solution you'd like

• test Debug Bar ElasticPress on WordPress 5.8
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: #25, #30.

PHP Notice

Browsing around the wp-admin, the following PHP notice pops up in error logs:

PHP Notice: Undefined index: body in /classes/class-ep-debug-bar-elasticpress.php on line 102

Release 2.1.1

• 1. Branch: Starting from develop, cut a release branch named release/X.Y.Z for your changes.
• 2. Version bump: Bump the version number in debug-bar-elasticpress.php, package.json, readme.txt, README.md, and any other relevant files if it does not already reflect the version being released. In debug-bar-elasticpress.php update both the plugin "Version:" property and the plugin EP_DEBUG_VERSION constant.
• 3. Changelog: Add/update the changelog in CHANGELOG.md and readme.txt, ensuring to link the [X.Y.Z] release reference in the footer of CHANGELOG.md (e.g., X.Y.Z-1...X.Y.Z).
• 4. Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 5. Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• 6. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
• 7. Merge: Merge the release branch/PR into develop, then make a non-fast-forward merge from develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• 8. Test: While still on the trunk branch, test for functionality locally.
• 9. Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
• 10. Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the release changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone.
• 11. SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• 12. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/debug-bar-elasticpress/. This may take a few minutes.
• 13. Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
• 14. Punt incomplete items: If any open issues or PRs which were milestoned for X.Y.Z do not make it into the release, update their milestone to X.Y.Z+1, X.Y+1.0, X+1.0.0 or Future Release.

Add helper text to assist debugging no queries

Hi team!

I was debugging the absence of queries being listed the other day and @johnbillion prompted me to share my findings here. While I was debugging, it would have been awesome if there was a help/informational message on the ElasticPress Debug Bar tab noting two important reasons why queries might not be showing up:

• Debugging constants not being set
• ElasticPress is currently indexing

Our issue was a combination of the two: I discovered we hadn't set WP_DEBUG or WP_EP_DEBUG and indexing was currently paused in WP Admin, which short circuited the WP_Query integration. I added a debugging constant and unpaused indexing and all was well. It would have been really helpful if there were some help text in the ElasticPress Debug Bar panel checking these two events, something like:

WP_DEBUG or WP_EP_DEBUG must be enabled for queries to be logged. If queries still aren't showing up, click here to troubleshoot

It could have a page listing other reasons why queries might not be showing up, and/or status indicators saying

• ✅ WP_EP_DEBUG is defined
• ⚠️ Indexing is currently paused, so queries will not show up

Thank you for all your hard work!

Update npm dependencies

Is your enhancement related to a problem? Please describe.

It seems that by using more modern versions of 10up linting tools we can get rid of some of our devDependencies.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Release] 3.0.0

• 1. Branch: Starting from develop, cut a release branch named release/3.0.0 for your changes.
• 2. Version bump: Bump the version number in debug-bar-elasticpress.php, package.json, readme.txt, README.md, and any other relevant files if it does not already reflect the version being released. In debug-bar-elasticpress.php update both the plugin "Version:" property and the plugin EP_DEBUG_VERSION constant.
• 3. Changelog: Add/update the changelog in CHANGELOG.md and readme.txt, ensuring to link the [3.0.0] release reference in the footer of CHANGELOG.md (e.g., 2.1.1...3.0.0).
• 4. Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 5. Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• 6. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
• 7. POT file: Run wp i18n make-pot . lang/debug-bar-elasticpress.pot and commit the file.
• 8. Release date: Double check the release date in both changelog files.
• 9. Merge: Merge the release branch/PR into develop, then make a non-fast-forward merge from develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• 10. Test: While still on the trunk branch, test for functionality locally.
• 11. Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
• 12. Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the release changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone.
• 13. SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• 14. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/debug-bar-elasticpress/. This may take a few minutes.
• 15. Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
• 16. Punt incomplete items: If any open issues or PRs which were milestoned for 3.0.0 do not make it into the release, update their milestone to 3.0.1, 3.1.0, 4.0.0 or Future Release.

Query Titles

Is your enhancement related to a problem? Please describe.

Add a title to certain queries, to make them easier to identify. Examples: "Autosuggest Template", "Search", "Main Search", "Debug Document query", or "Elasticsearch check" (the nodes/_plugins call)

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Release] 3.1.0

• 1. Branch: Starting from develop, cut a release branch named release/3.1.0 for your changes.
• 2. Version bump: Bump the version number in debug-bar-elasticpress.php, package.json, readme.txt, and any other relevant files if it does not already reflect the version being released. In debug-bar-elasticpress.php update both the plugin "Version:" property and the plugin EP_DEBUG_VERSION constant.
• 3. Changelog: Add/update the changelog in CHANGELOG.md and readme.txt, ensuring to link the [3.1.0] release reference in the footer of CHANGELOG.md (e.g., 3.0.0...3.1.0).
• 4. Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 5. Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• 6. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
• 7. POT file: Run wp i18n make-pot . lang/debug-bar-elasticpress.pot and commit the file.
• 8. Release date: Double check the release date in both changelog files.
• 9. Merge: Merge the release branch/PR into develop, then make a non-fast-forward merge from develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• 10. Test: While still on the trunk branch, test for functionality locally.
• 11. Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
• 12. Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the release changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone.
• 13. SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• 14. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/debug-bar-elasticpress/. This may take a few minutes.
• 15. Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
• 16. Punt incomplete items: If any open issues or PRs which were milestoned for 3.1.0 do not make it into the release, update their milestone to 3.1.1, 3.2.0, 4.0.0 or Future Release.

CSS loaded in all requests

Describe the bug

The Debug Bar ElasticPress CSS file should only be loaded for admin users and not be loaded by all users.

Steps to Reproduce

Check HTML source code for the CSS file.

Expected behavior

Screenshots

Environment information

• Device:
• OS:
• Browser and version:
• WordPress version:

• Plugins and version:
• Theme and version:

• Site Health Info:

Additional context

Better error messaging for failed requests

Is your enhancement related to a problem? Please describe.

Describe the solution you'd like

We need to interpret log files for failed requests and instruct the user what meta data needs to be added to the index.

Designs

Describe alternatives you've considered

Additional context

Test against WordPress 5.7

Is your enhancement related to a problem? Please describe.
Once WordPress 5.7 is released, we'll want to test Debug Bar ElasticPress to see if any incompatibility issues arise.

Describe the solution you'd like

• test Debug Bar ElasticPress on WordPress 5.7
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: #25

readme updates

• add support level section and badge
• add release version badge
• add WP tested up to badge
• add license file and badge

Query log is empty

Hi, I'm currently using WP 4.7.2, EP 2.1.2, ES 5.2, EP Debug Bar 1.1.1., WP DEBUG set to true in wp-config.php

After the execution of a query, I can't see the results on Debug Bar panel and the call to this function

$queries = ep_get_query_log();

returns an empty array.

Better spacing when used with Query Monitor

Is your enhancement related to a problem? Please describe.

Although this plugin is meant to be used with Debug Bar, it is also compatible with Query Monitor, with the only downside of some weird spacing in its panel.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Test against WordPress 5.9

Is your enhancement related to a problem? Please describe.
Once WordPress 5.9 is released, we'll want to test Debug Bar ElasticPress to see if any incompatibility issues arise.

Describe the solution you'd like

• test Debug Bar ElasticPress on WordPress 5.9
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: #25, #30, #39.

Show EP version in debug panel

Add Static Analysis tool PHPStan

Is your enhancement related to a problem? Please describe.

Static Analysis tool focuses on finding errors in the code without actually running it. It catches whole classes of bugs even before you write tests for the code.

https://github.com/phpstan/phpstan#phpstan---php-static-analysis-tool

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Strict Standards warning

When used with strict error reporting this generates a warning that can be easily fixed by making the factory() method static (or by changing the method call):

Strict Standards: Non-static method EP_Debug_Bar_ElasticPress::factory() should not be called statically in /path/to/plugin/debug-bar-elasticpress/debug-bar-elasticpress.php on line 19

Base Panel class is now an abstract. DB-EP is missing init() functions.

New development for the Debug Bar plugin happens in:
http://github.com/dd32/debug-bar

A commit was made on August 29th, 2017 that changed the Panel class to be an abstract and also labeled the init and render methods as abstract as well.

As a result, the EP_Debug_Bar_ElasticPress class now throws a fatal error because it does not have an init method.

Add "bulk_index" as an allowed log type

Is your enhancement related to a problem? Please describe.

Currently, we have bulk_index_posts as an allowed log type but the ElasticPress plugin doesn't use that string.

Describe the solution you'd like

In order to keep retro compatibility, we should add bulk_index, as used here.

Log query by context, status, and fixed time

Is your enhancement related to a problem? Please describe.

Currently, we only allow to enable or disable query logging, and that logs only failed queries in all contexts. We can change the Query Log screen to give people the ability to:

1. Log by context: list of checkboxes with REST API, AJAX, Admin, and Public
2. Log for a specific time: field to only log queries in the next 5 minutes or so
3. Log by status: log only failed queries or everything

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

I don't see Debug button in the admin bar.

I don't see Debug button in the admin bar.
Please add more details on usability side and how can i see elastic search data while accessing page using this plugin.

Plugin is active and i am logged in as admin.

Thanks

Display failed query results

The plugin doesn't display query results if request fails. Elasticsearch sends very useful insights in a response to such requests. So we need to display response body even if request fails.

Add number of EP Queries infront of the ElasticPress

Is your enhancement related to a problem? Please describe.

Add the number of EP Queries in front of ElasticPress, similar to how HTTP API Calls and Script have in the Query Monitor plugin

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Test against WordPress 5.6

Is your enhancement related to a problem? Please describe.
Once WordPress 5.6 is released, we'll want to test Debug Bar ElasticPress to see if any incompatibility issues arise.

Describe the solution you'd like

• test Debug Bar ElasticPress on WordPress 5.6
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
none