Summary:
Due to the following change in PHP8 - https://php.watch/versions/8.0/startup-errors-enabled
Moodle site administration (and probably other pages like quizzes) will fail on PHP8 with the default PHP settings, which are:

max_input_vars = 1000

display_startup_errors=On

The warning about the max_input_vars will be always displayed and breaks some pages. Our workaround does not help in this case.
The proposal is to add a requirement for the max_input_vars and remove the workaround, there have been other reports that workaround does not really work well anyway.

----- conversation log ------

Marina, [17.02.21 12:52]

^ this one is interesting. I "fixed" it in my local behat by changing the max_input_vars in php settings;
but it's a fix in moodle-docker, not in the code

Eloy Lafuente Plaza, [17.02.21 12:53]
And is it because of a change in php8? I mean, why doesn’t it show with php 7?

Marina, [17.02.21 12:53]
... but my fix broke the tests that actually test the max_input_vars workaround

as far as I can see in the release docs, the error reporting changed to E_ALL

https://php.watch/versions/8.0/error-display-E_ALL

maybe https://php.watch/versions/8.0/startup-errors-enabled too

Eloy Lafuente Plaza, [17.02.21 12:57]
but that’s a warning, it’s not strict or deprecated… uhm..

it’s like now we are passing more variables than with php7 or that the workaround we have has stopped to work?

just guessing. Maybe it’s more related with the fact that now @ doesn’t silences all the things?

Eloy Lafuente Plaza, [17.02.21 13:04]
ah ok, the error is in the session handler that tries its own init_set.

In any case, I’m not sure why php8 says the limit has been raised and php7 does not. I’ve here E_ALL | E_STRICT | E_DEPRECATED (that now is not needed) since ages ago and never have got that problem.

looking the default values in php.ini ...

heh, i’ve max_input_vars = 20000

default was the same in both 7.x and 8.x (1000)

Marina, [17.02.21 13:19]
It's just PHP now displays warning and then it breaks code that tries to do something before output

Because it's no longer before output

But there are tests that actually expect small value for max input vars

Eloy Lafuente Plaza, [17.02.21 13:21]
yeah, but then visiting those pages having > 1000 fail

because it’s detected too early

and now reported

Marina, [17.02.21 13:22]
Correct

Eloy Lafuente Plaza, [17.02.21 13:22]
and… if somebody can edit php.ini to set display_startup_errors, then for sure can also edit max_input_vars

problem is people not able to edit that

Marina, [17.02.21 13:24]
How can somebody hosting Moodle wouldn't be able to edit PHP settings?

Eloy Lafuente Plaza, [17.02.21 13:24]
well, don’t know… then… why do we have that workaround for max_input_vars ?

Marina, [17.02.21 13:25]
No clue

Eloy Lafuente Plaza, [17.02.21 13:25]
I always assumed it was because of ppl not having access to php.ini

Marina, [17.02.21 13:26]
Partners say they have to edit max input vars everywhere because otherwise quizzes fail

Eloy Lafuente Plaza, [17.02.21 13:26]
aha, the recommended php.ini-production comes with:

display_startup_errors = Off

so it’s the php.ini-development one

Marina, [17.02.21 13:27]
... so our workaround code doesn't really work... I think I saw some issues in tracker too

Eloy Lafuente Plaza, [17.02.21 13:27]
i’ve also max input vars set in all my prod sites.

maybe we could consider making it an environmental requirement.

it’s not the end of the world

Marina, [17.02.21 13:28]
Making what?

Eloy Lafuente Plaza, [17.02.21 13:28]
requiring "max input vars” > X

pretty clear for everybody

and then kill the workaround if possible and done.

Marina, [17.02.21 13:29]
Yeah good idea