WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 5 months ago

Last modified 3 months ago

#46726 closed defect (bug) (fixed)

Site health: the site data is gathered twice on non-English locales

Reported by: azaozz Owned by: azaozz
Milestone: 5.2 Priority: normal
Severity: normal Version: 5.2
Component: Site Health Keywords: site-health needs-testing 2nd-opinion
Focuses: Cc:

Description

Follow-up from https://core.trac.wordpress.org/ticket/46645#comment:27.

WP_Debug_Data::check_for_updates();

$info         = WP_Debug_Data::debug_data();
$english_info = '';
if ( 0 !== strpos( get_locale(), 'en' ) ) {
	$english_info = WP_Debug_Data::debug_data( 'en_US' );
}

WP_Debug_Data::debug_data() is quite slow, shouldn't be run twice. As far as I see the only difference in the data are the translated strings. Ideally we can separate the actual data from the "presentation" (the array used to output the HTML later on). Then can reuse the data as needed.

Attachments (3)

46726.diff (47.6 KB) - added by azaozz 5 months ago.
46726.1.diff (52.3 KB) - added by azaozz 5 months ago.
46726.2.diff (54.0 KB) - added by xkon 5 months ago.
cs fixes

Download all attachments as: .zip

Change History (16)

#1 @azaozz
6 months ago

Seems a simple/easy way to fix this would be to create both arrays at the same time: one in en_US the other in the user's locale. Then there's no need to translate the en_US strings, can be hard-coded.

Another option would be to gather the data first in a more "readable" form, with hard-coded strings/explanations. Then translate that to user facing language. What I mean is to have associative arrays where the keys would be meaningful enough so they can be used instead of having an extra "full-text" en_US version.

#2 @azaozz
6 months ago

  • Keywords needs-patch site-health added

Related: #46694.

#3 @Clorith
6 months ago

I think the first approach is both the simpler, and less resource dependent one, especially if we're adding in the potential for extra information added by plugins or themes via filters.

@azaozz
5 months ago

#4 @azaozz
5 months ago

  • Keywords needs-testing 2nd-opinion added; needs-patch removed

In 46726.diff:

  • In WP_Debug_Data::debug_data() format the site data in two sets: "text", intended for general use, and "debug" intended (mostly) for support personal and developers. The "text" strings are translated, the "debug" are more concise and in English.
  • Fix few nested ternaries.
  • Make all sub-arrays associative.

@Clorith could you test please :) Now the multi-dimensional array returned by WP_Debug_Data::debug_data() contains both English and translated strings. Left both "copy to clipboard..." buttons but wondering if we should leave only the one that copies the "debug" formatted data. Also remover/reused the $type param. Think it was there to eventually export the array in another format, perhaps JSON, but was unused?


#5 @Clorith
5 months ago

The $type array was unused for core, it was put in for formatting when running through WP-CLI on the plugin, I'm fine with re-using it this way though.

It does need a default value for $size_directories[ $size ]['debug'], as it throws undefined notices right now, I do like the idea of the array and the separation of user-facing VS support facing values, that's a great move.

@azaozz
5 months ago

#6 @azaozz
5 months ago

In 46726.1.diff:

  • Fixed notices caused by missing $size_directories[ $size ]['debug'].
  • Fixed/improved few strings.
  • Added more docs describing the $info array.
  • Removed the "Copy site info..." button that was copying the same (verbose) info as shown on the screen.
  • IMHO the "Copy site debug data..." button is okay to be styled as "secondary". It's not the main action here.

Thinking this is ready. @Clorith @afercia anything else left?

#7 @xkon
5 months ago

46726.1.diff looks ok on my end and I do agree that splitting the copied version out is way better!

#8 @afercia
5 months ago

@azaozz lots of improvements! I'd consider just a couple things:

The button text:
"Copy site debug data to clipboard"
I'd suggest to simplify: while technically correct, users are not supposed to know what "debug data" means. The rest of the text in the page (title, intro paragraphs) refers to "Site info" and "Information". Also, "debug" is a bit difficult to translate. I'd suggest something simpler like the previous text "Copy site info to clipboard".

PHPCS:
I'm afraid the build will fail :) I see the patch changes many alignments. I'm not saying I actually like the new PHPCS alignment rules, and probably I would have used the same alignments you used in this patch :) However, running phpcs --standard=phpcs.xml.dist src/wp-admin/includes/class-wp-debug-data.php reports now 114 "violations", mostly related to alignments.

@xkon
5 months ago

cs fixes

#9 @xkon
5 months ago

I'm just uploading this patch since I already had it from when I was testing the previous one and simply added the button change as well. I'm not really sure about the future of CS etc but for now I agree that it will just throw warnings so it's better to get this in-line I suppose.

46726.2.diff fixes all CS violations and changes the button text to Copy site info to clipboard.

#10 @azaozz
5 months ago

Thanks @xkon! I was also looking at fixing the phpcs, however took a slightly different approach.

The current rules in phpcs doesn't fully abide by the WP coding standards, and by recent changes. Most of these "violations" can be fixed in core's phpcs.xml.dist, opened #46869 to try to fix them :)

#11 @azaozz
5 months ago

Actually lets get this in as-is. We can always reformat later if needed. PHPCS details shouldn't cause delays :)

#12 @azaozz
5 months ago

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

In 45156:

Site health: Fix gathering the site data twice on non-English locales. Introduces two sets of data:

  • More verbose set used to generate the admin page.
  • More concise set that is copied when clicking the "Copy the site info" button intended mostly for support and developers.

Props xkon, azaozz.
Fixes #46726.

#13 @spacedmonkey
3 months ago

  • Component changed from Administration to Site Health
Note: See TracTickets for help on using tickets.