I see you have had queries in the past about this error - without being able to provide a cause or solution.

I have now come across it for the first time - trying to add a second user produces this error.

I have another zenphoto database and app installed in the same web site - it has no problem with adding more users, so the message is not one appropriate to the error, whatever that might be.

Your help would be appreciated.

Thank you,
Richard

Zenphoto version 1.5.8b (Official build)
Current locale setting: en_US.UTF8
Current gallery theme: zpBase
Server software: Apache
PHP version: 7.4.13
MySQLi version: 5.7.32

This is caused when the volume of items in a POST exceeds the size limits placed by PHP. IN this case there are too many fields (for the configuration) when you add the user. If you really are going from one user to two users you must have a very small limit.

Please see https://www.a2hosting.com/kb/developer-corner/php/using-php.ini-directives/php-maximum-upload-file-size#:~:text=By%20default%2C%20the%20maximum%20upload,the%20upload_max_filesize%20and%20post_max_size%20directives.
for how to change this limit.

the php settings you mention above are
post_max_size 32M
upload_max_filesize 20M

As explained (but perhaps not too clearly) I have two Zenphoto installations on the same web site:
https://eggsa.org/postcards/
and
https://www.eggsa.org/bibles/
both sites use the same php.ini file which is set further up.

With the postcards site I can, and have, created several users without any problem.

On the bibles site, however, I get the above error when trying to create a second user.

To me this appears to rule out any problem with the php.ini settings that you mention.

Thank you,
Richard

If this is really the same server (not "website", each install is a website, just to define some terms to avoid confusion) and the same Zenphoto version with the same configuration, I really have no idea why it would any different behaviour. 32M should really be enough for two users.
A plain user account does not submit that much data. Do you perhaps have some managed albums selected unnecessarily or perhaps a lot of these? That is the only thing that comes to mind that could increase the POST data submitted.

Forgot there is also another value that might be involved triggering submission issues: `max_input_vars`. Although I don't thinks two users exceed any "normal" configuration. I mean I primarily install ZP on various standard shared servers and never saw this.

If one user works I suggest to change the option to only show one user per page.

This was solved by increasing
memory_limit to 80M
post_max_size to 70M
upload_max_filesize to 50M
max_input_vars to 2000

don't know whether it was just one of those or the combo - don't have the time to experiment!!

Thanks,
Richard

I would guess it was a combination of several of them. Still not understanding why this exceeded on your install with just two users…

>>Still not understanding why this exceeded on your install with just two users

The number of post variables increases not just based on users, but also on the number of albums. If you've got a ton of albums (160 or so), then adding a 2nd user can push you above the default limit.

Indeed, if a user has that many albums assigned as managed albums that might add up. But not if no albums are assigned as unchecked checkboxes should not add up on posting. But that info was not mentioned above, the problem was adding a user account.

It has been a while since I looked at it, but as I recall the "managed state" for every album was included in the transmitted vars, regardless of whether it was checked or not. Perhaps to force unsets, and avoid making assumptions about items not included. When I ran into this issue I did not have any albums checked as managed, so I don't think it is limited by the checkboxes. (I'm on v1.5.6)

Anyway, from a different thread you mentioned an improved solution coming in the next big version, so in the meantime my solution has been to remove the transmission of managed album states altogether, since I don't use them. It sounds like the OP has his solution for now as well.

Unchecked checkboxes are actually not submitted which is actually a default behaviour. Unless I missed any change here or some browser prefers to do things differently… You can actually check that by looking at the $_GET/$_POST globals that only checked ones are included.

We would need an actual example how the user account looks like and best a dump of the $_GET/$_POST exceeding.

The managed album parts so far was not meant to be changed (there are lots of other things on the list first) but we'll consider it. Moving it to a separate page may help.