Make WordPress Core

Opened 6 years ago

Last modified 5 weeks ago

#51230 new defect (bug)

WP_DEBUG is flagged when using the development environment type

Reported by: desrosj Owned by:
Priority: normal Milestone: Awaiting Review
Component: Site Health Version: 5.5
Severity: normal Keywords: good-first-bug has-patch
Cc: Focuses:

Description

This was a request from the comments of the New `wp_get_environment_type() function in WordPress 5.5 post from @robertreiser:

Setting the environment to development also sets WP_DEBUG, which makes sense and I had WP_DEBUG enabled anyway on my development site.

But the site health tool still shows an error regarding the use of WP_DEBUG:

Your site is set to display errors to site visitors

In case if setting the environment to development, this should no longer be shown as an error in the site health tool.

Change History (13)

#1 @desrosj
6 years ago

Because there is no way to know how the constant is defined (manually in the wp-config.php file vs. set by WP Core after checking the environment type), I am of the opinion that this should still be flagged. However, I think the wording could be changed when the environment type is development, and it may be OK to change the type from critical to recommended.

This is the current text:

Debug mode is often enabled to gather more details about an error or site failure, but may contain sensitive information which should not be available on a publicly available website.

Something like the following could be added to indicate the development environment type is being used.

Because the site is currently using the `development` environment type, this should be OK. If these are being manually defined in the `wp-config.php` file, remember to turn this off before moving the website live.


Last edited 6 years ago by desrosj (previous) (diff)

#2 @anonymized_11582628
6 years ago

Thank you for the consideration of my comment on the WP Core blog and for turning it into a ticket, I really appreciate that. I just wanted to share some additional thoughts:

A WP user who modifies wp-config.php by either setting the WP_DEBUG flag or by setting the environment usually knows what they are doing and they do it on purpose. This is probably not the average WP user.

So I would argue that even if it is not exactly known how WP_DEBUG was set, it should not trigger either a warning or a recommendation in the site health tool when the environment is a development environment.

#3 @afragen
6 years ago

The site health error is about displaying errors to site visitors. The WP_DEBUG_DISPLAY constant is set to true as a default. Setting it to false removes this error.

I do realize that in a development environment we should be encouraging the visibility of these errors for testing. We should be able to understand what this error means and its context.

All that being said, giving the message some context with wp_set_environment_type() is probably a good thing.

#4 follow-up: @desrosj
2 years ago

  • Keywords good-first-bug needs-patch added

Adding good-first-bug to explore a few ways to add some additional context for development sites.

This ticket was mentioned in Slack in #core by desrosj. View the logs.


2 years ago

#6 in reply to: ↑ 4 ; follow-up: @xaymup
2 years ago

Replying to desrosj:

Adding good-first-bug to explore a few ways to add some additional context for development sites.

I believe this issue has been resolved. After examining the source code in class-wp-site-health.php, I noticed a condition that sets the status to 'recommended' rather than 'critical' in development environments:

				// On development environments, set the status to recommended.
				if ( $this->is_development_environment() ) {
					$result['status'] = 'recommended';
				}
Version 0, edited 2 years ago by xaymup (next)

This ticket was mentioned in PR #7178 on WordPress/wordpress-develop by @xaymup.


2 years ago
#7

  • Keywords has-patch added; needs-patch removed

#8 in reply to: ↑ 6 @SergeyBiryukov
2 years ago

Replying to xaymup:

This has been resolved in the latest version by using a function is_development_environment().

Related: [49237] / #47058.

#9 @martin.krcho
2 years ago

What is the plan with this ticket? Are we going to use a different message for dev environment?

The linked PR is for WP 5.5. Something like this is typically not backported to older version, is it?

#10 @westonruter
15 months ago

I just ran across this issue myself. Indeed it is unexpected for this test to fail in a local or development environment, but especially local. I've used this plugin code in the mean time to suppress:

<?php
add_filter(
        'site_status_tests',
        static function ( array $tests ): array {
                if ( in_array( wp_get_environment_type(), array( 'local', 'development' ), true ) ) {
                        // Debug mode is expected on local and development environments.
                        unset( $tests['direct']['debug_enabled'] );
                }
                return $tests;
        }
);

#11 follow-up: @Clorith
5 weeks ago

  • Keywords has-patch removed

It seems like it would probably be an acceptable approach to have a check to say if ( 'production' !== wp_get_environment_type() ) then accept that this value is expected?

This would negate the need for a helper function mixed in as well, because dev and local are essentially the same for this purpose.

#12 in reply to: ↑ 11 @westonruter
5 weeks ago

@Clorith What about staging too? Since staging should generally be a mirror of production, I think it makes sense to flag use of WP_DEBUG there too.

This ticket was mentioned in PR #12439 on WordPress/wordpress-develop by @jorgelopezrepiso.


5 weeks ago
#13

  • Keywords has-patch added

This PR updates the get_test_is_in_debug_mode Site Health test by modifying both the label and the description; the updated text now explicitly specifies that displaying errors is the expected behavior when working in a development environment.
Trac ticket:
https://core.trac.wordpress.org/ticket/51230
## Use of AI Tools

Note: See TracTickets for help on using tickets.