Re: max_input_vars silently truncates input without an error message
To give you a little more context - I have to support 3 or 4 different
versions of PHP, with various differing levels of features being
mid-deprecation or emitting warnings. I also have 260 composer
dependencies that I am not in direct control of, which might or might
not emit their own warnings/errors/etc. If I had warnings emitting, I
wouldn't have ever caught it over the noise of everything else that's
constantly making noise.
I absolutely _did_ used to develop with warnings on, and then run in
production without them on, when I was working on software that had
one single deployment, and running on one specific version of PHP.
But, unfortunately, that's not my situation anymore. (Our software is
open-source, and it needs to run on the widest range of PHP versions
we can possibly support).
And even if we _did_ run with those warnings enabled, I don't think I
would've caught it. Because you need to have over ~1000 users in your
database to trigger the issue, and I don't have that on my development
workstation. We, alas, discovered the issue in _production_, on real
customer data - and the production environment does not emit
deprecation notices nor warnings nor the like, as you might expect.
-B.
On Thu, Nov 20, 2025 at 6:17 PM Julian Somesan <julian@rospace.com> wrote:
>
>
>
> On Thu, Nov 20, 2025 at 5:10 PM Lynn <kjarli@gmail.com> wrote:
>>
>>
>>
>> On Thu, Nov 20, 2025 at 3:04 PM Andrey Andreev <narf@devilix.net> wrote:
>>>
>>> Hi Brady,
>>>
>>> I agree that E_WARNING is a poor way to handle this limit, and IMO a fatal error should
>>> be triggered instead. The ability to suppress and ignore is the root cause of why your situation is
>>> possible at all, and Laravel's behavior in this instance also did you a massive disservice.
>>>
>>> That being said however, this is also an extreme and self-inflicted edge case. 1k is an
>>> absurd number, even 100 input vars should be a sign of poor code logic. I urge you to redesign your
>>> solution entirely instead of looking for a quick workaround.
>>>
>>> Cheers,
>>> Andrey.
>>
>>
>> Unfortunately I'm no stranger to max input vars. We have increased the limit to 10k
>> because we will frequently hit over 1k. PHP is used for more than just websites. One example is
>> having a range of 20+ shoe sizes with 100+ stores in a single form where you can enter a number per
>> size per store. These forms are not rare in the application my company develops and there's not
>> really another way to deal with this. There's no performance issue here and it works just fine,
>> other than being bitten by an invisible issue that causes data loss.
>>
>> Having a fatal error would certainly help a lot to at least prevent partial data from being
>> processed and potentially causing data corruption.
>
>
>
>
> Honestly I really do not understand why you call that an " invisible issue".
> It is emitting a warning all the time, it is your job as a professional developer to catch all
> warnings at least in the development phase.
Thread (7 messages)