Site Health Tool - Directory sizes stuck in loading state in WordPress v6.6 RC3

[kowsar89]

In the WordPress Site Health tool, directory sizes are no longer displayed and remain in a Loading… state. Screenshot: ​https://prnt.sc/psKV31FudpPa

This issue was not present in WordPress v6.5.5 but has appeared in v6.6 RC3.

[Clorith]

This was introduced with [58299], although technically it could have happened before as well if the circumstances were correct, this is due to a logical flaw in when to send an error state back at ​wp-admin/includes/class-wp-debug-data.php#L1723-L1737

The newly introduced filesize check for the fonts directory looks for a wp-content/uploads/fonts folder, if this does not exist (which it does not by default), it will return an error state of not available, and with it being the last entry to be checked, it sets $size_total as null; This is also the variable used to determine the overall error state of the size function.

Using the $size_total variable for validation later down in the function was probably a bad idea, but since WordPress would always generate the directories being checked, it never showed up as an issue before the fonts directory (which is conditionally generated) was added to the list of places to check.

This should probably be changed to look for a failure of *all* checks, and not just the last to be ran.

[Clorith]

After some discussions, we've concluded that as the impact is limited (in that this does not affect site visitors, or other areas of the WordPress admin interface), and the problem is resolved whenever the Fonts API is used, along with how close the next release is, that this will be resolved in a minor update after release.

Moving this to the 6.6.1 milestone for tracking, and thank you for testing and discovering this!

[hellofromTonya]

Tentatively earmarked a 6.6.1 RC for late tomorrow (July 18th).

As a patch isn't ready yet and, as previously noted, the "impact is limited", moving this to 6.6.2.

This introduces an additional check to verify a directory exists before trying to iterate over its sizes.

Although recurse_dirsize will return a false if is_dir() returns a falsey value, it is mixed with other scenarios as well (such as permission checks and similar), by checking this against is_dir before relying on the WordPress core function, the user can be given a clear indication of why a directory has not been included in the calculation, instead of a generic one about permissions which may not be relevant for their setup.

Open to input on potential better wording for the message returned whe na directory does not exist, alternatively if we do not wish to introduce a new string at this time, the first failure scenario text could be reused, although is not 100% accurate

__( 'The size cannot be calculated. The directory is not accessible. Usually caused by invalid permissions.' );

A new ticket should also be created to handle the scenario where a WP_Error is returned by the REST endpoint used to return filesizes, as the JavaScript does not currently know to handle this properly. I'd like to keep the two issues separate, to allow us to fix the directory existence issue as the current cause for this failing fairly consistently, and is a regression, while the lack of proper handling of errors form the endpoint has been around for a few releases now.

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

[ironprogrammer]

Thank you for the ticket, @kowsar89, and @Clorith for the patch! This fix resolves the issue in my environment, but I've added needs-testing to see if we can get some more variety in environments.

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/7056

Steps to Reproduce or Test

1. ​Override the font storage location using the `font_dir` filter, setting it to a non-existent location (​example mu plugin).
2. In Site Health navigate to the Info tab and expand the "Directories and Sizes" accordion.
3. Observe the directory size results.

Expected Results

When reproducing the bug:

• ❌ The size results display "Loading..." for all directories.

When testing a patch to validate it works as expected:

• ✅ Size results are displayed for valid directories, with a "does not exist" message for those that are inaccessible.

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 14.5
• Browser: Safari 17.5
• Server: nginx/1.27.0
• PHP: 8.3.9
• MySQL: 8.0.27
• WordPress: 6.7-alpha-58576-src
• Theme: twentytwentyfour v1.2
• Active Plugins:
  • change-fonts-dir-location (​mu plugin that sets fonts dir to /wp-content/fonts-not-exist)

Actual Results

Before patch:

• ❌ Size results for all directories showed "Loading..."

After patch:

• ✅ All directories except for fonts displayed valid sizes, and the fonts directory showed "The directory does not exist."

Supplemental Artifacts

Before patch:

After patch:

[shailu25]

Test Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/7056

Environment:

WordPress - 6.6
PHP - 8.2.12
Browser: Firefox 128.0
OS: Windows 10/11
Theme: Twenty Twenty-Four 1.2
MU Plugins: None activated
Plugins: None activated

Steps to Reproduce:

• In Site Health navigate to the Info tab and expand the Directories and Sizes.
• The size results display "Loading..." for all directories.🐞

Actual Results:

• Directories Size results are displayed with a "The directory does not exist." message for those that are inaccessible.✅

Supplemental Artifacts:

• Added Attachments.

[shailu25]

Before Patch

[shailu25]

After Patch

[swissspidy]

#61736 was marked as a duplicate.

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

Before Applying Patch:

After Applying Patch:

[leedxw]

#61745 was marked as a duplicate.

[sabernhardt]

#61791 was marked as a duplicate.

[markussss]

I am not sure if this is directly related and sorry, I couldn't read the entire thread yet. But the data that is shown in the "Directories and Sizes" in "Site Health" is also not acurate or up to date. This was already before WordPress 6.6 though. That means, from my experience to get updated data you must delete the transient "dirsize_cache".

I am usually not commenting on trac, so I don't know the rules in here.

This tests well and resolves the issue of being stuck in a loading state.

To test I simply deleted the uploads directory and noticed that it was created along with the year and month directories when loading the site health screen, eg uploads/20204/08 was created. This is due to the use of wp_upload_dir() rather than wp_get_upload_dir().

Now that the use case of a non-existent directory is handled, it might be worth adding a follow up ticket to avoid creating the directory when it's not needed.