WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 3 weeks ago

#51153 new defect (bug)

Use ini_get_all() to determine 'memory_limit' value in Site Health

Reported by: SergeyBiryukov Owned by:
Milestone: 5.5.2 Priority: normal
Severity: normal Version:
Component: Site Health Keywords: needs-patch
Focuses: Cc:

Description

Background: #49329

[47762] introduced displaying the original PHP memory limit on Site Health Info screen.

Per some further discussion starting with comment:17:ticket:49329, ini_get( 'memory_limit' ) reports incorrect values in some environments, and $ini_all['memory_limit']['global_value'] should be used instead.

Change History (1)

#1 @ayeshrajans
3 weeks ago

Reading the former ticket, it looks like there is a confusion/disagreement on what site health should show: The memory_limit INI setting, vs the semantic meaning of the memory limit, which might be constrained by several factors including the physical RAM, the VM's maximum allocated RAM, per-process RAM limitations, etc. Even if we had all the POSIX tools, I don't think we can reliably measure this value.

Debian/Ubuntu and CentOS/RHEL packages come with a default php.ini file that has memory_limit=128M. This value is reported as the global_value. A user/SAPI-specific value will be reported as the local_value, in which case the global_value is not considered and is _not_ the upper limit.

I think using the global_value is not the correct approach, because it will return the root PHP.ini configuration, which almost always gets overridden under specific users and SAPIs, if not per-directory or script. The global_value is merely what the root PHP.ini file says; it has nothing to do with available memory, and I doubt many shared host providers even bother to change it because it gets different values in a configuration down stream anyway.

Note: See TracTickets for help on using tickets.