A large WordPress menu may appear to save normally while items near the bottom disappear. If the submitted request exceeds max_input_vars, PHP truncates the input before WordPress can validate the complete form, and another click saves the same incomplete structure.
Prove truncation in the affected web runtime, count the required variables and request only a modest supported increase.
What it means
max_input_varslimits the number of input variables PHP parses for a request. It helps constrain resource use, but complex menus, option panels and nested forms can exceed it.
The limit counts parsed variables rather than the number of fields a user sees. It is separate from request-size, nesting, JavaScript, permissions and application-validation limits.
A realistic WordPress example
An administrator adds several menu sections, but the last items vanish after Save. Browser tools show that the full form was submitted, while PHP logs indicate the input-variable limit was reached.
The team counts the real request, backs up the menu and raises the effective value slightly above that requirement. Sentinel items at the beginning, middle and end all persist on the next test.
Why it matters and when to use it
Correcting proven truncation prevents silent loss in large administrative forms. The change is justified when a legitimate bounded form consistently exceeds the active value and the server can accept a safe increase.
If the form grows without bound, redesign or batching is safer than continually expanding a global parser limit.
A straightforward route for beginners
- Export or otherwise back up the menu or settings being edited.
- Capture the request and compare expected fields with the stored result.
- Check PHP logs for an input-variable warning.
- Read the effective
max_input_varsin the same web context. - Request a value just above the measured requirement and verify that it took effect.
- Submit the protected test again and check early, middle and final items.
The advanced route
Count nested arrays as PHP parses them and use sentinel values around the threshold to locate truncation. Compare the browser payload, PHP input and stored WordPress structure to isolate the boundary.
Check pool-specific configuration and hosting ceilings. Do not change post_max_size, nesting depth or unrelated limits merely because they appear near the same configuration directive.
Risks, common mistakes, backup, and rollback
A very high value permits larger parsing workloads on every applicable request and may conceal an impractical form design. Editing an already truncated configuration can permanently discard the missing tail.
Keep the prior requested value and the content backup. Roll back if resource use rises, unrelated forms regress or another layer still truncates the request.
How AIOWS helps:
AIOWS PHP Limits
AIOWS PHP Limits can show active PHP limits, attempt changes supported by the server environment and help confirm the effective result. Check max_input_varsfrom the same WordPress admin context that submits the failing form.
Use the measured request to choose a modest value, record both requested and effective settings, and repeat the protected form test. The final stored items are stronger evidence than a changed number alone.
The host may reject an override, and AIOWS cannot repair an unbounded form or a different request limit. Use the hosting method or redesign the workload when the effective value or behavior does not change.
Related AIOWS articles
- post_max_size vs upload_max_filesize in WordPress
- How to Create a Safe PHP Limits Report for WordPress Support
- Allowed Memory Size Exhausted in WordPress: Complete Fix Guide
Conclusion and recommended route
Confirm PHP input truncation before raising the limit, protect the current data and choose a value slightly above the real form requirement. Verify the complete stored structure in the same admin workflow.
