WordPress: fix forms truncated by “Input variables exceeded”

Recognize values truncated during saving

You save a large settings form and some values return to their initial state or disappear. The log mentions “Input variables exceeded” with a number. PHP may have stopped reading some request variables before WordPress processed the form. A success message in the interface is insufficient to prove every value was retained.

The desired result is a complete submission received in the correct PHP context, then identical settings after reopening. This guide concerns settings forms and component interfaces sending many fields. Do not automatically attribute every incomplete menu or editor error to this limit.

On a self-hosted site, administrator permissions allow recording and comparisons; changing PHP requires corresponding hosting access. On a managed platform, parameters may be enforced. In multisite, assess the scope of shared settings before touching a form or shared configuration.

Preserve settings before clicking again

Stop repeated saves as soon as loss appears. A form reopened with missing values may subsequently save them as though intentional. Preserve still-visible information, a private screenshot of useful structure and any component-provided settings export. Keep the date of these records.

Prepare an appropriate data backup and test copy. A WordPress content export does not necessarily retain every setting of the affected module. If the procedure also changes a PHP configuration file, preserve it separately outside the public directory. These two protections do not replace one another.

Choose a test value without commercial effects, such as a test label on the copy. Avoid settings triggering synchronization, sending or price changes. Record open panels and approximate item count: some components add fields only after an area opens. The same apparent form can therefore produce two different requests.

Separate variable count from other limits

max_input_vars limits input variables accepted by PHP, separately for GET, POST and cookies. Documentation specifies a warning and truncation beyond the ceiling. The documented default is 1,000, but hosting may apply another value. Counting only visible screen items does not reveal the actual transmitted field count.

Other limits concern different things. post_max_size concerns POST body size; max_input_nesting_level concerns parameter-array depth. A multipart request may also reach a part-count ceiling with a different message. Increasing memory does not automatically raise these limits.

Record the exact named directive and stated number. If the server returns 403 or 413 without a variable warning, examine that rejection separately. If the application receives JSON and decodes it itself, JSON property count does not automatically equal variables PHP populates in POST. The actual request determines diagnosis.

Observe the request sent by the form

On the copy, open Chrome developer tools, then Network before saving. Select Preserve log if navigation follows and keep the All filter: a form may create a document request, not only Fetch/XHR. Make one test change and select its sending request. Under Headers, record Request Method and Content-Type; under Payload, inspect Form Data or Request Payload according to format. Publish neither security tokens nor private form values.

Check whether expected fields are already missing from the submission. If so, a server limit alone cannot explain disappearance: the interface or a script may have omitted preparing them. If they appear in the submission and a PHP warning matches the time, have both observations correlated.

Native classic menus in recent WordPress versions retain a JSON data copy in nav-menu-data for server-side reconstruction. Their entry count alone therefore does not prove loss from the old menu limit. Check that field is present and populated in the request before blaming the ceiling. A failing script, third-party form or truncated payload needs its own check. Do not disable this mechanism or copy its internal functions into a plugin to reproduce an old recipe.

Record the effective value in the domain context

Under Tools, Site Health, Info, open Server and record the PHP version and displayed maximum input variables. Keep this reading with the domain and time. The value loaded for the site may differ from another domain on the account or from the command line.

Consult the host’s private PHP log at the exact test time. A request-startup warning may occur before WordPress logging initializes. Its absence from a WordPress log therefore does not rule out truncation. Avoid creating a public phpinfo() page for more details.

If the panel already shows a value higher than the message’s number, have the loaded file and domain engine confirmed. Configuration saved in the wrong location has not corrected the relevant context. Keep one example for before-and-after comparison; simultaneous increases across several files would prevent knowing which applies.

Reduce submission size when the tool actually supports it

The first approach uses an editing mode sending fewer fields while preserving the result. It applies when the component documents batches, paginated settings or independent per-item saving. Record the initial state and work on the copy before changing important data.

Try a small change with unnecessary panels closed, then reopen content to verify retention. Closing a panel does not guarantee its fields stop being sent: confirm the difference in Network. If the tool offers a reduced batch, retain its scope and also check unprocessed items.

Do not delete half a public menu to test a hypothesis or arbitrarily split exported data. If a version with few fields works and the large one fails with the same warning, you have a useful clue, not a universal permitted item count. Restore initial test settings afterward and move to the component or configuration when reduction does not meet the actual need.

Compare a component that adds fields

If a component adds settings to the form, compare its effect on a recent copy. Under Plugins, Installed Plugins, record the sole suspect’s state and deactivate it if the tested operation still makes sense without it. Save the same small case, check the result and reactivate before comparing another component.

Troubleshooting is an optional aid for comparing components within your session. The official listing consulted on November 13, 2026 for version 1.0.2 by Marius L. J. states minimum WordPress 6.4 and PHP 7.2, tested through WordPress 7.1.4; this does not recommend an old PHP branch. Under Plugins, Add New Plugin, verify the product, then install and activate if permitted. Open Tools, Site Health, Troubleshooting, then Enable Troubleshooting Mode. The Dashboard widget and administration-bar menu then let you reactivate useful components individually and finish with Disable Troubleshooting Mode.

This mode raises no PHP limit and does not isolate data in a separate database. A settings form still writes data: use the copy. Must Use plugins remain active and cache may distort comparison. If the field-adding component is confirmed, examine its version and official fix instead of keeping it disabled and losing a necessary function.

Change the directive in the correct domain’s panel

1. The second approach fits a legitimate need exceeding the effective limit when hosting permits a proportionate increase. In cPanel, open Software, then MultiPHP INI Editor. Select the exact domain; Home Directory may extend the effect across the account. Preserve managed values and files before changing them.
2. In Basic Mode, select the domain under Configure PHP INI basic settings. If max_input_vars is offered, change only that setting and click Apply. If the host requires Editor Mode, select the domain again under Edit PHP INI settings and verify Path. Change the existing line or add it once, then Save. An empty editor means no file was loaded there: have context confirmed before creating one. Choose a value based on the observed submission and resources, not a number assumed suitable for every site.
3. The panel may propagate this setting into several compatible files, including php.ini, .user.ini and .htaccess. Avoid competing manual changes to the same parameters afterward. Return to Site Health to verify the loaded value, then test the same form on the copy. A value saved in the panel but unchanged on the site calls for a context check. To undo testing, restore the previous value on the same screen and check its effect without resetting all PHP configuration.

Use .user.ini only in a confirmed environment

1. If the provider confirms PHP runs through CGI or FastCGI and uses .user.ini, SFTP or file-manager access may allow a per-directory setting. PHP searches directories from the requested script’s directory to the web root. For a request handled in wp-admin, a file placed only in wp-content therefore does not apply. Have the relevant shared directory and expected filename confirmed: the host may disable this search. Preserve existing content privately before editing without replacing the entire file.
2. Change the existing max_input_vars definition or add one line if absent and authorized. The example uses 3,000 as an illustrative value to adapt. This file uses INI syntax without a PHP opening or php_value. Keep access allowing restoration independently of the dashboard.
3. Rereading .user.ini may be delayed; the documented standard delay is five minutes but configurable. Wait the confirmed interval, then record the effective value before testing again. If nothing changes, investigate the loaded file or enforced ceiling instead of multiplying copies. To undo, restore the initial value or remove only the added line. Delete a newly created file only if it contains no other necessary setting.

max_input_vars = 3000

Handle a multipart part ceiling separately

A “Multipart body parts limit exceeded” message concerns the number of parts in a multipart submission, not just simple variables. Keep its text and value with the first warning. Increasing max_input_vars may therefore be insufficient if another explicit limit stays lower.

When max_multipart_body_parts exists in the PHP version used, have the same administrator examine its effective value. In the verified PHP 8.3 code, default -1 triggers calculation from max_input_vars plus max_file_uploads. An explicit value may therefore continue limiting the request after increasing max_input_vars. Do not copy a second number into every file or change max_file_uploads without an established need for additional files.

If confirmed, the provider adapts this directive to the need within the same authorized context, retaining its initial value. Then repeat the small case and representative volume, checking all data. A file no longer transferred or missing final field remains a failure even if the first warning disappears. Restore only the tested setting if ineffective or outside approved scope.

Reject corrections that cannot act early enough

This limit applies while PHP inputs are prepared. Adding ini_set for max_input_vars in wp-config.php, the theme or a plugin snippet is not the correct mechanism. The directive is not classified as freely changeable at runtime. A plugin displaying a number does not guarantee it changed server processing.

Do not change WP_MEMORY_LIMIT, maximum execution time or upload size simply because their names suggest limits. They address other causes. Keep evidence identifying the reached ceiling instead of accumulating preventive increases.

Also do not insert a PHP directive into .htaccess assuming every server accepts it. The mechanism depends on execution mode, and unsupported syntax may cause another failure. Use the panel or file confirmed by the provider. On WordPress.com and plans enforcing PHP settings, a component fix or service intervention replaces local configuration changes.

Validate values, not only the save message

Record the new effective value after applying configuration. On the copy, open the same form with the same panels and make the test change. Record the time, then fully reopen the screen. Values at the beginning and end must persist along with items you did not intend to change.

Compare the same request’s log and check another ceiling has not taken over. If submission changed because a component was corrected, document that difference instead of attributing success solely to the PHP increase. A low-volume test does not yet validate the usual volume triggering the problem.

Then check a neighboring function and affected public rendering, such as a menu or configured entry. Local success is judged by data actually saved and usable. Cache purging may reveal an existing correction; it does not recreate values truncated before saving.

Restore lost values within a limited scope

Correcting the ceiling does not restore already overwritten data. Return to your record, settings export or available backup and identify exact affected values. For a small known set, restore them in the interface after validating complete submission, then reopen the form to verify persistence.

A full database restoration could replace newer posts, registrations or orders. Have targeted recovery prepared when important data cannot be confidently reentered. Do not import a configuration export into production without knowing its effects on other settings and item identifiers.

If the configuration test must be undone, return to the initial setting through the same method and check its effective value. Keep PHP configuration restoration separate from data recovery. Reverting the former does not restore the latter. Retain evidence until the form and uses dependent on its values are validated.

Prevent unnoticed form growth

Document the component owning the form, loaded limit and verified volume. When an update adds fields, a tab or a set of variations, recheck submission on the copy. Suitable headroom today does not permanently guarantee a continually growing form.

Prefer developer-provided batching or targeted editing over one screen accumulating every value. Improved processing may avoid escalating limits. The chosen number must remain justified and compatible with server resource policy; disappearance of a warning does not justify an indefinitely high value.

To request a correction, provide component version, screen path, request type, time and useful messages. Describe values retained and lost after reopening. Do not share a complete payload screenshot containing tokens or secrets. A reduced case reproduced on a copy allows investigation at the right level without repeatedly saving the same incomplete data.

Count transmitted parameters instead of visible fields

One menu setting may represent several variables: title, link, ID, parent, classes and plugin-added fields. Conversely, a large JSON object may be sent in one form parameter and decoded by the application. Visible row count is therefore not a reliable unit for choosing max_input_vars.

On the copy, retain a small form and usual form as controls. For each, record content type, names of expected final parameters and their presence in the payload. Hidden fields and repeated names may count; disabled or unnamed controls are not necessarily sent. Prefer recording the actual transmitted request over simply counting HTML elements.

Then have these parameters compared with those received by PHP processing in a private diagnosis limited to names and counts without logging values or tokens. If final parameters are already absent browser-side, correction belongs first in the form. If sent but truncated with the corresponding warning, the server limit becomes an evidence-supported cause.

After targeted correction, reopen settings and compare beginning, middle and end. A PHP increase does not reconstruct data lost during earlier tests. Retain the initial export or record for separate recovery; no “limit-increasing” plugin replaces this comparison.