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.
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.
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.
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.
I can’t think of every single possible combination in development, this is all based on tenants and their setup. That said, a ton of this is also code that was written way before I started working here (20 years+), and we’re talking a million+ lines of code. This warning disappears between millions of log lines in production. I would rather have a customer call us with an error than the issue silently dodging detection. I’m not looking for your approval or anything, just explaining that this can pose a real issue no matter how hard you try to do it the right way.
On Thu, Nov 20, 2025 at 2:00 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.
In our case, we had a multi-select (<select> with the 'multiple'
attribute) that listed a few thousand users. You can select them all,
and each selected value counts towards the 1000 fields being
submitted. You could argue that it's poor design, and, maybe, it could
be. But it's still a valid use-case IMHO.
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.