anotherdave

I did not experience the issue when looking at page you linked to – the widget images looked aligned nicely, and no scroll bar appears at bottom. So, I’m sure you probably thought of this already but just in case – any chance you have your browser zoom set to higher than 100% ? At 100% or lower it looks fine, but when I set my browser zoom to 110% , only then did the bottom scroll bar appear.

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!