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.

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.

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.