[wp-trac] [WordPress Trac] #51153: Use ini_get_all() to determine 'memory_limit' value in Site Health

[WordPress Trac]

#51153: Use ini_get_all() to determine 'memory_limit' value in Site Health
----------------------------+---------------------
 Reporter:  SergeyBiryukov  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  5.5.2
Component:  Site Health     |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:
----------------------------+---------------------

Comment (by ayeshrajans):

 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51153#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform