Mismatched “post_max_size” and “upload_max_filesize” values.

I have no idea to be honest. I just know what I did and I no longer have that error. Why it works and how it works I’m not as interested in knowing. If trying what I did doesn’t work for you just call your host.

If you don’t have a host that you can call, Bluehost is money well spent. From dialing the number to hanging up the phone after taking the survey was literally 9 minutes. I can call at 3AM Christmas Eve or New Years and get a knowledgeable American on the phone. Their are no cutting corners with excellence. yes i preach bluehost, no i don’t work their or offer affiliate link.

@maxvelio The fact that you still have the warning most likely means you didn’t effectively set the same value for both. For example if you set the values in your .htaccess or php.ini file, there’s a chance these settings are overruled by whatever value is configured via your server’s control panel.

But like I posted earlier, you shouldn’t set the same values for post_max_size and upload_max_filesize. Instead you should configure the values properly and ignore WordPress’ incorrectly displayed error message. So memory_limit > post_max_size > upload_max_filesize, as specified on https://www.php.net/manual/en/ini.core.php#ini.post-max-size. For example 256M, 64M, 32M would be a valid configuration.

As an extra bit of info, post_max_size has nothing to do with WordPress posts, it refers to a HTTP POST request used for example to upload an image to your media library. Since this request also has some overhead, setting it and upload_max_filesize to the same value makes no sense, since you’ll never be able to upload a 1M file if the POST request containing that file is also limited to 1M. Not to mention it’s also possible to upload multiple files using a single POST request, which is why you’d want post_max_size to be larger than upload_max_filesize.

@mnatseah624 Several PHP directives (such as the ones discussed here) accept shorthand byte values: K for Kilobytes, M for Megabytes, G for gigabytes. See also https://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes.

Many thanks @spartelfant

Thank you @spartelfant for the explanation. I am afraid I need some extra help, sorry.

I have not direct access to my php.ini file but I have in my server an option in the control panel to change the values of several variables and those three are among them.

In my case, while memory_limit is now set to 256M, both post_max_size and upload_max_filesize are set to 25M, so that’s why I assumed both have the same value. In fact, I cannot write anything but choose among values 128M, 256M and 512M for memory_limit and among 12M, 25M, 50M, 100M, 175M, 250M and 300M for the other two.

Said all the previous, I have several doubts about everything.

– Should I change the values according the number I have to choose from? Could you please suggest me the best option you consider?
– I have two sites in the same server (in two different languages and urls) and I have discovered some images are missed when I try to upload a group of images in both sites at the same time. Can it be related to those parameters?

Thanks again for your help. While I am trying to get out that warning in the health report, I am also concerned about the best performance of my websites.

While we are talking about the PHP Ini settings, I note that my max_execution_time is set to 30000, while it says the default setting is 90. I’ve no idea who put in these settings.
Will this huge max_execution_time setting make any difference to the site’s functioning?

The same thing happened to me, but I solved in the cpanel, editing the php.ini and .htaccess file, matching

.htaccess
<IfModule php7_module>
php_value max_execution_time 30
php_value max_input_time 60
php_value max_input_vars 1000
php_value memory_limit 128M
php_value post_max_size 64M
php_value session.gc_maxlifetime 1440
php_value upload_max_filesize 64M
</IfModule>
<IfModule lsapi_module>
php_value max_execution_time 30
php_value max_input_time 60
php_value max_input_vars 1000
php_value memory_limit 128M
php_value post_max_size 64M
php_value session.gc_maxlifetime 1440
php_value upload_max_filesize 64M
</IfModule>

php.ini
max_input_vars = 1000
límite de memoria = 128M
post_max_size = 64M
session.gc_maxlifetime = 1440
session.save_path = “/ tmp”
upload_max_filesize = 64M

I insert this 2 line in end of .htaccess file:

php_value upload_max_filesize 100M
php_value post_max_size 100M

in my case was solve the same issue about that situation.

@gorgeouskitty

Well, I am still with the same issue. I followed @spartelfant suggestions and I put the values:

memory_limit 256M
post_max_size 100M
upload_max_filesize 50M

I am not sure if I did the correct thing as I cannot change php.ini and the value are predefined (128-256-512 for memory_limit and 12-25-50-100-175-250-300M for the other two variables).

Still getting the warning.

Not sure if I have done the right thing.

Thanks

Trye to Put same value for:

post_max_size 100M
upload_max_filesize 100M
@maxvelio

Limit memory i put on wp-config.php file after script define( ‘WP_DEBUG’, false );

/**
Increase PHP Memory Limit in WordPress
**/
define( ‘WP_MEMORY_LIMIT’, ‘128M’ );
@maxvelio

Thank you @capembajeremias but before making that changes, I already had the same value in both and got the warning. @spartelfant suggested to use one bigger than the other and I did that….

Not sure if I am making something that can become an issue later…

Hi, I recently updated php version.
Then i wordpress started showing
“post_max_size” and “upload_max_filesize” values. ERROR

solution

Step 01
Go to cpanel

Step 02
Go to MultiPHP INI Editor

Step 03
Configure PHP INI basic settings will open
Now in search bar CHOOSE the website

Step 04
Look for values of

post_max_size

upload_max_filesize

Now
change both the values 250

Thank you

Before I chime-in too, it’s important for site owners to realize that the PHP “post_max_size” setting is NOT referring to your “Posts” in WordPress. It is referring to the maximum allowed size of anything being uploaded to the server through any give PHP session – regardless of whatever type of media (photos, plugins, themes, form data, etc…) is being uploaded to the server, and it is NOT WordPress specific. These settings in PHP dictate the limits and resources for any / all PHP scripts being run on the server no matter if you’re using WordPress or any other such PHP-driven content management system.

SO…

As a couple of others have mentioned in this thread (and perhaps taking it a bit further), and I can confirm as someone who has been working in tech support for shared hosting for a while, the WordPress site health check warning that says:

“Mismatched “post_max_size” and “upload_max_filesize” values.”

Is something that WordPress devs seriously need to address, because every server administrators knows that the “post_max_size” directive in PHP should always be set smaller than the “upload_max_filesize” , and NOT equal. (Especially in shared hosting environment).

It’s creating a false alarm and preventing site owners from seeing a perfect “Great Job” score, and as we can also see in this thread – has end-users adjusting things in manner they should not. For example some examples / reasons why:

– On many hosts using a modern server environment, the PHP values / limits / parameters are set “globally” for the whole server and users should not attempt to override them.

– Also, on many hosts using a modern server environment, paths related to PHP sessions and settings for PHP resource limits are handled within global settings at the root level of the server and via technologies such as PHP-FPM.

Therefore; attempts to override the global PHP settings that your host already has in place can result in a variety of unexpected results. If a user attempts to override these settings via .htaccess , there’s a strong chance that either the site will not function correctly or that the overrides are simply ignored. And in some cases your host might have security modules in place that will actually detect the override attempts as something “bad” and could end up triggering a security rule, which in turn could prevent important parts of your code from carrying-out their functions (and in some cases even make a site inoperable).

Bottom Line is this:

1. The “post_max_size” setting in PHP should always be at least a little higher than the “upload_max_filesize”

2. The “memory_limit” setting in PHP should always be larger than both of those. (Although this point doesn’t really come into play when speaking in regard to the “Mismatched “post_max_size” and “upload_max_filesize” values” warning, unless it is truly a “bug” within the new WP health check, since “memory_limit” is not part of the warning).

Here are a couple of common / correct examples of how those PHP settings / values should be, along with some further explanation:

On a good well-configured shared host you might see values like this:

post_max_size = 70M
upload_max_filesize = 64M
memory limit = 256M

In that example above, the server / PHP is basically saying “the PHP script is allowed sustained maximum use of 256 megabytes of server RAM, the largest single upload size allowed via the PHP script is 64 megabytes, and the largest chunk of data (for lack of a better way to word it) that can be inputted via the PHP script is 70 megabytes.

On a lower-end server you might see something like:

post_max_size = 50M
upload_max_filesize = 30M
memory limit = 128M

And on a server with original “default” configuration you might see something as limiting as this:

post_max_size = 8M
upload_max_filesize = 2M
memory limit = 64M

Obviously those last two examples are not optimal for WordPress, because by default WordPress wants 256M of RAM available to it, and many WordPress users are uploading files sized 25M or larger, within sessions that posting upwards of 30M of data at once.

So… (and based on a number of very busy / very content-rich WP sites that I help manage) out of the three examples above, this one would be optimal and typically work very well for most modern WP sites:

post_max_size = 70M
upload_max_filesize = 64M
memory_limit = 256M

(In some cases I’ve seen people set memory_limit to 512M , which is fine if you’re on high-end hosting or if you have your own dedicated server etc… , but is not necessary for normal WordPress function).

It is very well documented in places like the official PHP docs and the official cPanel docs, that “post_max_size” should be set higher than “upload_max_filesize” in the PHP config for correct operation. If the opposite were done, then users would run into timeouts and broken sessions, and it is widely assumed that if they were set “equal” that the same issue is likely to occur, since pushing the limit of an upload to use the same amount of memory as the full data session can also cause the session / operation to timeout and get “stuck”.

I truly hope that the great minds / developers at WordPress will “fix” this erroneous warning from the site health check feature, as it is alarming users (in many cases for absolutely no valid reason) and in the cases of WP sites that I help manage / host, is the ONLY thing that is prevent a perfect “Great Job!” thumbs-up result in the site health check.

I also truly hope that this post helped someone else!

Thank you @anotherdave for the careful explanation.

I have checked all your different suggestions for the good-configuration values and, unfortunately, due to my control panel restrictions (I have not access to the php files directly) I have only a few values available (128-256-512 for memory_limit and 12-25-50-100-175-250-300M for the other two variables).

My configuration now is:

memory_limit 256M
post_max_size 100M
upload_max_filesize 50M

I would say it is the nearer to your suggestion but I would feel much better if you could confirm if that’s the one you would use in case you would have only those values available.

I still have the same warning (I already had when both values were the same) and I still have issues when uploading at the same time images to my posts in the gallery in both wordpress websites (English and Spanish) I have in my site.

Thanks again for your help.