Opened 16 months ago
Last modified 7 months ago
#59251 new defect (bug)
Site Health incorrectly reports low disk space available for updates when disk_free_space function disabled
Reported by: | sdowney2002 | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 6.3.1 |
Component: | Site Health | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description (last modified by )
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.
Change History (8)
#2
@
15 months ago
Reproduction Report
Steps to Test
Starting from WordPress 6.3:
- In
php.ini
, disabledisk_free_space()
by adding the line:disable_functions = disk_free_space
. - Restart the web server.
- Navigate to Site Health, and expand the disk space security notice. Observe the message.
- 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
#4
@
13 months ago
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)
#5
@
12 months ago
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
#6
@
12 months ago
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.
#7
@
8 months ago
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.
#8
@
7 months ago
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 🙏🏻
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.