Filter error suppression for individual DB query errors

[bpayton]

Sometimes it is useful to suppress certain DB errors while logging others.

For example, we have a set of standalone, core-like sites on WordPress.com where users can install arbitrary plugins and themes, and sometimes there are situations where query errors from third-party plugins flood a site's error logs. In some of those cases, the source of the error is not straightforward to address, and we would like to silence or throttle the errors so the site can continue using a given plugin without consuming its available disk space.

Targeted suppression would be possible if WordPress supported a suppress_query_error filter that receives:

• the current error suppression setting, defaulting to $wpdb->suppress_errors
• the raw error string
• the DB query associated with the error

The result of filtering would determine whether $wpdb->print_error() returns early or logs the error, like $wpdb->suppress_errors does today.

I have a patch for this and plan to submit a PR shortly after creating this ticket.

This PR adds a suppress_query_error filter that can be used to selectively suppress or un-suppress logging of a specific query error. The motivation for adding this filter is to allow logging of most query errors while completely suppressing (or maybe just throttling) specific query errors due to third-party plugins and themes that are not easily fixed or changed. But the flexibility offered by this filter will likely be useful for other purposes as well.

This PR also adds a log_query_error action for the purposes of testing the filter, but this also could be useful to customize how query errors are logged or relayed.

Trac ticket: https://core.trac.wordpress.org/ticket/55414

[bpayton]

Created a PR here:
​https://github.com/WordPress/wordpress-develop/pull/2426

This is the first time I've posted a PR instead of a patch. The PR seems easier to iterate on, but if you as maintainers prefer patches in Trac, please let me know. I'm happy to switch back to patches.

[peterwilsoncc]

Replying to bpayton:

This is the first time I've posted a PR instead of a patch. The PR seems easier to iterate on, but if you as maintainers prefer patches in Trac, please let me know. I'm happy to switch back to patches.

A PR is perfect, many of the maintainers and committers use GitHub rather than patches for the same reason.

[azaozz]

The patch/PR looks good here. Thinking that being able to filter or redirect DB errors will be pretty useful in some cases, especially on bigger/busier sites. Can also be used by a plugin designed to categorize errors and send them to appropriate places, trigger alerts/warnings about specific errors, etc. all from whitin WP.

[audrasjb]

AS per today's bug scrub: the PR was reviewed and approved, so let's mark this for commit.

[audrasjb]

Removing commit keyword for now, as there is a conflict to resolve in the above pull request.

The wp-db.php file was renamed in https://core.trac.wordpress.org/changeset/53749/ to class-wpdb.php. You should be able to just move these changes to that file.

[desrosj]

Added some inline suggestions to the PR as well.

[desrosj]

This one is real close, but beta 1 is incoming. Let's work on wrapping this one up for 6.2.

@desrosj and @dream-encode, thank you for your review. I pushed some changes to address your feedback and added a temporary redirection of error logging to avoid messages being printed in the middle of PHPUNIT output. How does this look?

[mukesh27]

This ticket was discussed in the recent bug scrub.

Thanks @bpayton for the ticket.

Looks like the review feedback have addressed and the PR just needs another look.

Props to @costdev

[costdev]

This ticket was discussed during the bug scrub. It looks like ​PR 2426 just needs a re-review.

@davidbaumwald @desrosj Do you have time to take another look?

[costdev]

This ticket was discussed during the bug scrub. As the PR still needs reviews, I'll move this to Future Release. If this is reviewed and is ready prior to the 6.2 Beta 1 release party later today, feel free to move it back into the milestone for commit.

Additional props: @mukesh27

Thanks for the updates @brandonpayton! LGTM! +1

Thanks for your thoughtful guidance and example! This PR is much better now.

@desrosj @dream-encode would you be up for re-reviewing this? I believe it is ready.

There is some test automation failure, but it appears unrelated as it is "Gutenberg running from build / MacOS" and ​failing on the Install Core Dependencies step.