WordPress.org

Make WordPress Core

Opened 6 weeks ago

Closed 5 weeks ago

#54340 closed defect (bug) (fixed)

WP_LOCAL_DEV shouldn't be included in Site Health Info

Reported by: johnbillion Owned by: Clorith
Milestone: 5.9 Priority: low
Severity: normal Version: 5.2
Component: Site Health Keywords: needs-patch good-first-bug
Focuses: Cc:

Description

On the Tools -> Site Health -> Info screen, the WP_LOCAL_DEV constant is included under the heading "WordPress Constants".

This is not a WordPress constant and isn't used by WordPress. Some popular libraries use this constant but it's not a core constant and is misleading to include it under this heading. A colleague had this constant set in the expectation that it affected the return value of wp_get_environment_type(), which it does not.

Attachments (2)

54340.diff (1.5 KB) - added by sabbirshouvo 5 weeks ago.
@Clorith I've added this patch for WP_LOCAL_DEV to WP_ENVIRONMENT_TYPE migration.
54340.2.diff (1.3 KB) - added by sabbirshouvo 5 weeks ago.
Adjusted spacing and improved the values

Download all attachments as: .zip

Change History (10)

#1 @Clorith
6 weeks ago

  • Milestone changed from Awaiting Review to 5.9

Good catch, this seems to be an artifact of the Health Check plugin, where it did make sense to look for it, but the core implementation should definitely only be checking core-related features.

Adding it to the milestone for the next release.

#2 @igorradovanov
5 weeks ago

I'd like to work on this one.

#3 follow-up: @sabbirshouvo
5 weeks ago

I want mention this ticket #33161

Last edited 5 weeks ago by SergeyBiryukov (previous) (diff)

#4 in reply to: ↑ 3 @bgoewert
5 weeks ago

What if we changed WP_LOCAL_DEV to WP_ENVIRONMENT_TYPE since that is the constant used in wp_get_environment_type()?

Even though this value is already displayed under the "WordPress" section on the Site Health Info screen. Does it not make sense to list it's constant under this section as well?

Last edited 5 weeks ago by bgoewert (previous) (diff)

#5 @Clorith
5 weeks ago

@bgoewert That sounds like a reasonable solution, yes. Since WP_ENVIRONMENT_TYPE is a core constant, it could safely be displayed, and since the fallback environment, if an invalid value is defined, this is a perfect and quick way to check that value.

@sabbirshouvo
5 weeks ago

@Clorith I've added this patch for WP_LOCAL_DEV to WP_ENVIRONMENT_TYPE migration.

#6 @Clorith
5 weeks ago

Thank you for the patch @sabbirshouvo.

Would you have time to make a small udpate here, as the output should be the actual value of the constant, and not true, false, Enabled, or Disabled (the Undefined message is OK to leave in though, if the value is not defined).

There's also a few too many spaces on line 321, the number of indents should match the other elements in the array (this isn't a major issue, and we can fix it before committing, but it's good to keep track of :) ), see the line that triggered that warning below (it only needs a single space to align with everything else in the section):

'WP_ENVIRONMENT_TYPE'        => array(

#7 @sabbirshouvo
5 weeks ago

@Clorith in addition to your comment, I think $wp_environment_type_debug is also unnecessary here.

@sabbirshouvo
5 weeks ago

Adjusted spacing and improved the values

#8 @Clorith
5 weeks ago

  • Owner set to Clorith
  • Resolution set to fixed
  • Status changed from new to closed

In 52021:

Site Health: Add the constant WP_ENVIRONMENT_TYPE for debug data.

As a legacy from the old Health Check plugin, the constant WP_LOCAL_DEV was included in the debug data under the "WordPress Constants" section. This was incorrect, and has never been a constant used by core.

Instead, that field is now replaced by WP_ENVIRONMENT_TYPE, which was introduced with WordPress 5.5, and is a much more appropriate value to provide in a debug scenario.

Props johnbillion, bgoewert, sabbirshouvo.
Fixes #54340.

Note: See TracTickets for help on using tickets.