The sentence before that is
> The MAX_FILE_SIZE hidden field (measured in bytes) must precede the file input
> field, and its value is the maximum filesize accepted by PHP.

If you have a repro script that has this field appearing before the file input and the value is still ignored, please share it so the problem can be fixed.

The value isn't ignored, but it's checked AFTER the entire file was uploaded.

As far as I can tell the intention of MAX_FILE_SIZE was to abort the upload, so the fact that files continue to be uploaded (which I've confirmed happens with PHP 5.5 + Apache 2.4 + mod_php) seems to be a bug. Perhaps rather than getting rid of something deemed useless, it can be fixed to work as expected.

Indeed, this is quite certainly not a doc bug, see
<https://github.com/php/php-src/blob/php-7.0.8/main/rfc1867.c#L1049-L1053>.

Confirming this bug also here. The MAX_FILE_SIZE post data value check is never reached since the upload_max_file size ini directive is always set (no matter if you comment it out of php.ini it will be by default 2MB). This hidden value will only work if you set upload_max_filesize to 0 or -1 (like unsetting it). On top of that, edge case is vulnerable to changing the value on the user side (it is a hidden field after all and not a setting in the code).

Considering that it has been used in only an extreme edge case for the past several PHP versions and frameworks don't use it anymore it might be a good idea to remove it or better yet refactor it in the core code to something that works. Because with current PHP versions the only check that is done is the upload_max_filesize ini directive on the php side. And, preferably, also a manual check inside the code on the server side comparing a manual configuration value to a file size of the uploaded file.

Correcting my explanation above: When using MAX_FILE_SIZE, it will be used in two cases. One, if you unset the upload_max_filesize (to 0 or -1) (bad idea anyway, or two, if you set upload_max_filesize to be bigger than MAX_FILE_SIZE.

Actually, the MAX_FILE_SIZE option is useful after all because some app might set the ini directive upload_max_filesize to some setting for all files in the app, and additionally manually set different MAX_FILE_SIZE for multiple upload forms in the same app (let's say one for images and one for videos).

And it does stop the upload, but differently than reader might expect on the first glance. Uploading will be stopped when the MAX_FILE_SIZE is reached on the server (not at the beginning of the upload process). With extremely large files, for example hundreds of MB or GBs, this still is relevant today actually. However, for better user experience all decent forms might want to think about adding form client side validation as well (even file size can be determined at the time of this writing by the browser and JavaScript).

So, I was wrong a bit here and too hasty with previous comment conclusions. However, relying on this feature is not something that is secure since it can be spoofed on the client (browser) side easily.

Probably this would be better fixed with a better explanation in the documentation instead.