Site Health incorrectly reports low disk space available for updates when disk_free_space function disabled

[sdowney2002]

Beginning in 6.3.1, specifically with the change introduced in ticket #59116, Site Health incorrectly reports that "disk space is critically low" when the disk_free_space function is disabled by the web host.

Previously, in 6.3, Site Health correctly reported that it "could not determine available disk space" when the disk_free_space function was disabled.

[ironprogrammer]

Welcome to Trac, @sdowney2002, and thanks for the report!

Would you please share more information on the environment/configuration where this occurs? I was unable to reproduce the issue.

[ironprogrammer]

Reproduction Report

Steps to Test

Starting from WordPress 6.3:

1. In php.ini, disable disk_free_space() by adding the line: disable_functions = disk_free_space.
2. Restart the web server.
3. Navigate to Site Health, and expand the disk space security notice. Observe the message.
4. Upgrade to WordPress 6.3.1, then repeat Step 3.

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 13.5.1
• Server: nginx/1.25.2
• PHP: 8.2.9
• WordPress: 6.3, 6.3.1, and 6.3.2-alpha-56487

Actual Results

• ❌ Before and after the 6.3->6.3.1 upgrade the notice indicates: "Could not determine available disk space for updates." Unable to reproduce.

Supplemental Artifacts

Figure 1: Disk space notice and after upgrade to 6.3.1.

[waterfire]

This seems to be an issue related to WPEngine having disabled disk_free_space

I'm also getting the same "Available disk space is critically low, less than 20 MB available. Proceed with caution, updates may fail." error as reported by @sdowney2002 in WordPress 6.4.

This is the environment:

• WordPress 6.4
• Server: Linux 5.4.0-1107-gcp x86_64
• PHP: 8.2.11 (Supports 64bit values)

​https://snipboard.io/Fbh30r.jpg

[dasbuilder]

I'm also chiming in on the issue where WordPress Site Health is saying there is a disk space issue, when I'm only using 6.5GB and have 92GB free.

• Linux 5.15.109+ x86_64
• PHP 8.2.12 (Supports 64bit values)
• WordPress 6.4.2

[ironprogrammer]

Thank you for adding to this report, @waterfire and @dasbuilder! Out of curiosity, in your respective environments, have you been able to confirm (via code) the result of calling disk_free_space?

If you have a chance, ​here's a test gist of a mu-plugin that outputs an admin notice that includes: path, symlink status, whether the function exists, and the final value of $available_space used to determine the message shown in Site Health.

[Website Rob]

Adding disable_functions = disk_free_space to php.ini did not solve the problem.

A method I tested and works is to create a new directory: /wp-includes/upgrade/

The above was used on a new default install as it would appear that an 'upgrade' directory is not created by default but is required by Site Health. As previous WordPress installs and for whatever reason or method, seem to already have the 'upload' dir., the error message and problem does not occur.

[ironprogrammer]

Hi, @website-rob -- Disabling disk_free_space is an example step to help find a way to consistently reproduce the issue, but is not an attempt to solve the problem. Thank you for noting the missing upgrade directory context, since that is, indeed, another instance that could cause this check to report an issue.

FWIW, I've re-tested after deleting the directory (in my environment, /wp-content/upgrade/), but received the expected, "Could not determine available disk space for updates." I could only trigger the critical warning message when overriding disk_free_space to return < 20 MB.

I've updated the test gist in comment:6 to include a check whether upgrade exists, and if disk_free_space has been overridden (not the internal function). It's hard to track down issues in specific hosting setups, so any test results feedback from those who reported seeing this issue would be appreciated 🙏🏻