Opened 7 years ago
Last modified 13 months ago
#25939 reviewing defect (bug)
add_options_page(..., 'options.php') and 1000 vars limit
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | has-patch 2nd-opinion |
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.
Attachments (1)
Change History (5)
Note: See
TracTickets for help on using
tickets.
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.