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 <[email protected]> wrote: > > > > On Thu, Nov 20, 2025 at 5:10 PM Lynn <[email protected]> wrote: >> >> >> >> On Thu, Nov 20, 2025 at 3:04 PM Andrey Andreev <[email protected]> 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.
