[wp-trac] [WordPress Trac] #56390: Updating WP_MEMORY_LIMIT

[WordPress Trac]

#56390: Updating WP_MEMORY_LIMIT
---------------------------+------------------------------
 Reporter:  JavierCasares  |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  performance
---------------------------+------------------------------

Comment (by dd32):

 Replying to [comment:9 JanR]:
 > That is correct. Or at least, in some circumstances. I've seen a lot of
 plugins and themes [https://www.saotn.org/increase-wordpress-memory-limit-
 wp-config-php/ "doing it wrong"] in the past.

 This entire post is exactly why I commented, this statement seems to be
 untrue to me:
 > in a situation where PHP memory_limit is set higher than a custom
 WP_MEMORY_LIMIT in wp-config.php, this may causes problems. **You are
 basically decreasing the amount of memory available to WordPress through
 WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT.**

 This quote is also totally wrong/not-required; Unless you're running a
 buggy theme/plugin that doesn't check correctly.. and even then..
 [https://github.com/WordPress/WordPress/blob/master/wp-includes/default-
 constants.php#L47-L48 this line you pointed out] takes care of that
 anyway..
 > After increasing PHP’s memory limit, you can now create a
 WP_MEMORY_LIMIT constant in your wp-config file. Use the following syntax
 to set it to your currently configured PHP limit.

 > lot of plugins and themes "doing it wrong"
 The example of the Jupiter theme there is a good example of a buggy theme,
 I don't think confusion from a theme author is reason to change this in
 WordPress though.

 The example of WPML seems unwarranted, they're listing both the php.ini
 value and the constant value, It's not clear how it's being used, but it
 looks like it's part of debugging information based on the contents of the
 array, in which case seems fine..

 > However, remember that  PHP `memory_limit` can/may be changed anywhere,
 so `wp_is_ini_value_changeable( 'memory_limit' )` returns always true.
 This makes [https://github.com/WordPress/WordPress/blob/master/wp-includes
 /default-constants.php#L47 this check] obsolete in my opinion.

 I would agree, that check seems obsolete at first, however, I believe
 using tools such as `suhosin` can disable the ability to modify some ini
 settings such as this. However, even being able to set it doesn't mean
 that such tools won't have prevented it (ie. Request 10G and it says
 "Nope, you get 2G max"). It's also possible to set the PHP memory limits
 higher than the system can provide, that's also not exactly WordPress'
 problem.

 > One can argue hosting companies should (must) set reasonable limits, but
 don't forget they're set for a reason. In my opinion, PHP memory_limit
 should be at least > 128 MB, preferably 256 MB but plugins that require
 more must be killed :)

 And that's the crux of this - Hosting companies should set reasonable
 limits, but all of this code in WordPress related to memory is
 specifically for hosts who do not, it's not at all about overriding what a
 host has done, it's about making WordPress work on a host who has re-used
 a php.ini from 2005 in 2022 with an abysmal memory_limit value.

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