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.