add_options_page(..., 'options.php') and 1000 vars limit

[tivnet]

(Related to the discussion in #14134)

There is a "common knowledge" in the wilderness, suggesting having this for seeing all options at once, and I guess many admins have that enabled:

add_options_page('All Settings', 'All Settings', 'administrator', 'options.php');

At some point, the list grows to more than 1,000 variables, and:

PHP Warning: Unknown: Input variables exceeded 1000.
To increase the limit change max_input_vars in php.ini.
in Unknown on line 0

The option table is corrupted then. In the best scenario, the tail of the table is occupied with transients. The worst - real settings.

(having a separate table for transients sounds like a good idea to me, BTW)

Now, to the point: the "All Settings" panel should NOT have the [Save] button. It must be read-only.

Alternatively - AJAX save, similar to phpMyAdmin - for each option separately.

[dd32]

In the best scenario, the tail of the table is occupied with transients.

This angle is mostly mitigated by the fact that the fields which are marked as disabled/readonly (as fields with serialised data in them are) are not submitted to a server in a POST request.

Since the all-options page is mostly a hidden power-tool, an option may be to simply disable the submit process when the number of active fields exceeds that of max_input_vars.
Another option would be to simply use JS to only send changed fields to the server.

[bordoni]

I've worked on this as a possible solution using a JavaScript to only send the value of the field in case it was changed.

It was the first patch I changed that much.

[ramon fincken]

Ok so I found this ticket in search of something that appears quite similar.

To be precise =>
In the current setup op options.php

A) It is possible to modify the DOM for serialized data. The POST server check is non-present upon processing of a POST request

B) It is possible that you modify a single value whilst the site has updated another option due to normal site ( or plugin ) behavior.
Note that the patch provided here would fix this.

C) In the current setup the POST server will update ALL options it is presented by the form. Why not check what is changed in the form ? Yes it is a minor performance improvement and yes only on the admin option pages, but I like this.
Note that the patch provided here would fix this.

D) It might be worth commenting in code that the nonce is actually verified using check_admin_referer

So, now what? @SergeyBiryukov , @bordoni (thanks for your patch!)

[hellofromTonya]

Removing trunk as the Version as trunk is currently 6.2.0 at the time of this comment.