WordPress.org

Make WordPress Core

Opened 16 months ago

Last modified 4 weeks ago

#25939 new defect (bug)

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

Reported by: tivnet Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: Cc:

Description

(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.

Change History (2)

comment:1 @kovshenin16 months ago

  • Cc kovshenin added

comment:2 @dd324 weeks ago

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.

Note: See TracTickets for help on using tickets.