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.
