---

This section details on the original issue you should resolve

<issue_title>Respect WP_DEBUG instead of overriding</issue_title>
<issue_description>Currently the value of display_errors is overridden by \Utils\wp_debug_mode(), but I would expect WP_CLI to respect the value set by WP_DEBUG and \wp_debug_mode() instead.

It sounds like there may have once been a reason for overriding it, but it's not known anymore.

In my experience, having it overridden is a hassle, because when I'm writing commands I don't have notice/warning/error messages easily available. In many cases, it might not even be obvious that an error occurred at all. So I have to manually check log files or use a fragile workaround to restore the original settings.

I'd be happy to work on a PR if it's decided that this behavior should be removed.

Background information:

php/utils-wp.php#L26
cb57cc0
#786
</issue_description>

Comments on the Issue (you are @copilot in this section)

@danielbachhuber > Currently the value of display_errors is overridden by `\Utils\wp_debug_mode()`, but I would expect WP_CLI to respect the value set by `WP_DEBUG` and `\wp_debug_mode()` instead.

Sorry if I'm being a bit dense, but I'm still not sure what the problem is. Can you provide a more detailed example of how this is a problem, what the current behavior is, and what you'd expect the behavior to be?

@danielbachhuber What would you think about this? 1. If `WP_DEBUG=true`, then WP-CLI defaults to displaying errors when `--debug` is and isn't included. If `--no-debug` is passed, then WP-CLI silences errors. 2. If `WP_DEBUG=false` or isn't set, the WP-CLI defaults to not displaying errors. `--debug` would enable displaying errors.

It does seem somewhat erroneous for WP-CLI to quietly silence errors when WP_DEBUG is defined in wp-config.php.

@danielbachhuber > Yeah, that makes sense to me. I'll work on a PR :)

👍

It'd be good to have explicit test coverage for each of the scenarios, where we don't already.

@danielbachhuber > Yeah, that makes sense to me. I'll work on a PR :)

@iandunn Do you have a timeframe you're willing to commit to for this? Otherwise, I think this issue should be free for the first person to submit a PR.

@danielbachhuber @iandunn I added a testcase in #3372 for the behavior you described in https://github.com//issues/3220#issuecomment-236649813. The testcase passes, which isn't what I'd expect if the behavior was broken like you initially described.

Can you re-verify the original issue, and confirm there isn't additional code in your environment that might be affecting error reporting?

@danielbachhuber > Oh well, I guess I'll just consider this resolved unless I run into it again in the future. Sorry for the trouble.

No worries! Happy to look into it again if you can track down more steps to reproduce.

@swissspidy Reopening due to the comment above and the open PR. @danielbachhuber Flagging this for `contributor-day`. It seems like a couple or few people should solve it together.

I think we should solve this by:

1. Creating documentation that captures what the expected behavior should be.
2. Write tests for the expected behavior.
3. Make the necessary changes to the framework.</comment_new>