WordPress.org

Make WordPress Core

Opened 3 months ago

Closed 4 weeks ago

#51153 closed defect (bug) (wontfix)

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

Reported by: SergeyBiryukov Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Site Health Keywords: needs-patch close
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 (6)

#1 @ayeshrajans
3 months 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.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


7 weeks ago

#3 @Clorith
7 weeks ago

  • Keywords close added

I'm with @ayeshrajans here that getting the initially set value is nice, but it's likely to be overridden further down the line.

As noted r47762 adds in a distinction between the stored value, and the one available in WP-Admin, and I don't think there's any reasonable distinctions beyond this that need to be made, if a plugin or theme feels they need even more granular data than this, it feels more like a special consideration for them, and they can add that check them selves, especially as core fetches the first value _it_ knows of and displays now.

#4 @whyisjake
5 weeks ago

  • Milestone changed from 5.5.2 to 5.5.3

👋
Given the 5.5.2 release tomorrow, going to punt this to 5.5.3 as we don't have a patch for this issue.

#5 @JeffPaul
5 weeks ago

  • Milestone changed from 5.5.3 to 5.6

We're working on a short cycle 5.5.3 release in the very near future and have no further minor releases planned so I'm punting this to 5.6 in hopes it'll have a patch ready for that major release.

#6 @noisysocks
4 weeks ago

  • Milestone 5.6 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing per comment:1 and comment:3.

Note: See TracTickets for help on using tickets.