WordPress “max_input_vars”: Why Menus and Forms Break, and How to Fix It

What max_input_vars actually limits (and why WordPress hits it)

max_input_vars is a PHP configuration directive that caps the number of input variables accepted per request. Input variables are typically populated from:

• POST body fields (form submissions)
• GET query parameters
• Cookies (yes, those too)

In WordPress admin, the biggest offenders are giant nav menus, complex page builders, multi-language menu structures, product attribute editors, and custom field groups that render lots of repeated fields. Each nested array element counts as a variable.

So when WordPress builds a menu editor POST that includes hundreds of menu-item-* fields, PHP happily parses until it hits the ceiling—then it stops. WordPress receives a truncated dataset and dutifully “saves” the truncated reality. That’s why the UI can look like it succeeded while the data ends up missing.

Interesting facts and historical context (because this problem has a backstory)

1. PHP didn’t always have max_input_vars; it became common as a mitigation against hash-table collision and variable injection style abuse that could consume CPU and memory parsing huge requests.
2. The default value is often 1000 on many distros, but hosting panels and “hardened” builds frequently set it lower without telling you.
3. Before max_input_vars was widely known, people blamed WordPress for “randomly” dropping menu items—because the failure is silent unless you look at logs.
4. PHP counts nested inputs individually: acf[field_1][sub][0][name] is not “one thing”; it’s multiple variables by the time it’s flattened into the internal symbol table.
5. Browsers don’t enforce this limit. The client sends everything; the server discards the rest. That asymmetry is why it feels like a ghost bug.
6. Some older environments used Suhosin (a hardening patch/extension) which introduced its own limits like suhosin.post.max_vars; legacy hosts sometimes still carry those constraints forward.
7. WordPress menus can explode input counts because each menu item isn’t one field; it’s a bundle (title, URL, classes, target, XFN, position, parent, etc.).
8. Large cookie payloads (marketing, A/B testing, consent tooling) can burn input-var budget too, because cookies are parsed into variables as well.
9. HTTP/2 and modern stacks made big admin requests more reliable transport-wise, which ironically increases how often you hit server-side parsing limits instead of network timeouts.

Dry operational truth: limits like max_input_vars are not “bugs.” They’re circuit breakers. But if the circuit breaker is too small for your load, you get brownouts.

One quote, paraphrased idea: “Hope is not a strategy” (paraphrased idea often attributed in operations/reliability circles to engineers like Gene Kranz). In this case: don’t hope the menu saves. Measure the request size and configure accordingly.

What it looks like in the UI: real breakages, not theory

Here are the patterns I see in production WordPress fleets, where “the site looks fine” until an editor tries to change something.

Menus

• Symptom: You add menu items, click “Save Menu,” and some items vanish or revert.
• Why: WordPress posts a massive list of menu-item fields. PHP parses only the first N vars, and the tail never reaches WordPress.
• Tell: It’s worse when you reorder, add many items at once, or have mega-menus with many nested levels.

Page builders and custom fields

• Symptom: Elementor/ACF/WPBakery pages save, but some blocks reset, repeaters lose rows, or “random” subfields blank out.
• Why: Repeaters and nested structures explode into thousands of variables.
• Tell: Smaller edits save fine; big edits corrupt only part of the data.

Forms

• Symptom: Complex forms submit but arrive with missing fields, or validations fail on fields the user definitely filled.
• Why: PHP discards variables beyond the limit; the plugin sees missing keys and treats them as empty.
• Tell: It correlates with forms that have repeatable sections, multi-step wizards, or lots of hidden fields.

WooCommerce product edits

• Symptom: Product attributes, variations, or metadata “doesn’t stick.”
• Why: Variations can generate a truly absurd number of input vars per save.
• Tell: Simple products are fine; variable products are haunted.

Short joke #1: The form didn’t forget your data. PHP just decided it had seen enough for today.

Fast diagnosis playbook

This is the order that finds the bottleneck quickly without wandering around WordPress admin like a lost tourist.

First: confirm the symptom is request truncation, not permissions or caching

• Reproduce the save in a single browser, logged in as admin.
• Check server logs for a PHP warning about max_input_vars.
• Check whether only the “tail” of a large dataset is missing (classic truncation pattern).

Second: identify which PHP SAPI handles wp-admin

• Nginx with PHP-FPM? Apache with php-fpm? Apache with mod_php? Container with a custom ini?
• Don’t guess. Confirm using a command-line query or a controlled phpinfo output limited to admins only.

Third: verify the active configuration and who is overriding it

• Inspect php -i and the relevant FPM pool settings.
• Look for per-directory overrides (.user.ini, .htaccess), panel overrides, or conf.d fragments.
• Then make one change in one place and reload the correct service.

Fourth: assess adjacent limits

• post_max_size and upload_max_filesize (size limits)
• max_input_time (parsing time)
• FPM request termination (request_terminate_timeout)
• Nginx/Apache body limits (client_max_body_size, LimitRequestBody)

If you follow that order, you’ll usually have a root cause in 10–20 minutes. If you don’t, you’ll “fix” it by turning everything to 11 and then wonder why memory usage looks like a crypto miner moved in.

How PHP counts “input vars” (the part everyone gets wrong)

People read max_input_vars=1000 and think “my form has 200 fields, I’m safe.” Then they ship a repeater field and everything breaks.

PHP’s input parsing turns incoming parameters into key/value pairs inside superglobals like $_POST. When you send nested structures (common in WordPress), PHP expands them. Example:

• menu-item[123][title]=Home
• menu-item[123][url]=/
• menu-item[123][classes]=top

That’s three variables, not “one menu item.” Now multiply by hundreds of items and dozens of properties. You hit 1000 faster than anyone expects.

Also: cookies count. Lots of personalization and analytics tooling can add large cookies. Even if your admin POST is near the limit, a few cookies can tip it over. It’s not the most common cause, but when it happens it feels especially unfair.

Finally: truncation isn’t always “drop the last items you added.” It’s “drop whatever variables come after the threshold in parsing order.” The parsing order is roughly the order fields appear in the encoded request body. If your plugin changes field order, the “missing pieces” can look random.

Short joke #2: max_input_vars is like an office meeting limit: after 1000 inputs, nobody’s listening anyway.

Where to set it: Apache, Nginx+PHP-FPM, cPanel, containers

Golden rule: change the setting where the runtime reads it

There are many ways to “set” PHP values. Only some apply to your actual request path. If you run Nginx + PHP-FPM, editing Apache’s php.ini does nothing except give you false confidence.

Nginx + PHP-FPM (most common on modern VPS)

Typical places:

• /etc/php/8.x/fpm/php.ini
• /etc/php/8.x/fpm/conf.d/*.ini
• FPM pool file: /etc/php/8.x/fpm/pool.d/www.conf (can override via php_admin_value)

After changes: reload php8.x-fpm. Reloading Nginx alone won’t apply PHP ini changes.

Apache with PHP-FPM

Same PHP-FPM rules apply. Apache is just a reverse proxy to FPM. You still need to reload FPM. Apache reload is optional unless you changed proxy config.

Apache with mod_php (less common now)

Settings usually come from Apache’s loaded php.ini and additional conf.d files. Changes require an Apache reload/restart.

Shared hosting / cPanel / Plesk

Often uses per-user ini settings through the panel or .user.ini. But beware: panel UI can be writing to one ini while the running PHP is reading another (different PHP versions, different handler). Confirm with a runtime query.

Containers (Docker, Kubernetes)

Either bake the ini into the image or mount a config file. The biggest trap: editing a file in a running container and losing it at the next deploy. If it’s not in Git or the deployment manifest, it doesn’t exist.

What number should you set?

Common working values:

• 3000 for “bigger than average WordPress” (larger menus, some ACF repeaters)
• 5000–10000 for heavy WooCommerce variation editing, multilingual menus, or page builders used like spreadsheets

I’m not allergic to high numbers, but I’m allergic to setting them high with no guardrails. If you crank input vars, also consider request size limits and WAF rules, and monitor PHP-FPM memory and request time. Make it safe, not just permissive.

Practical tasks (commands, outputs, and decisions)

These are the “do this, see that, decide this” tasks I use when I’m on call and someone’s menu is actively eating itself.

Task 1: Check the PHP CLI setting (quick baseline)

cr0x@server:~$ php -i | grep -i max_input_vars
max_input_vars => 1000 => 1000

What it means: CLI PHP is currently set to 1000. This may or may not match the web runtime (FPM vs CLI can differ).

Decision: If CLI is low, it’s a hint your distro defaults are low. Still confirm the web SAPI next.

Task 2: Identify running PHP-FPM service and version

cr0x@server:~$ systemctl list-units --type=service | grep -E 'php.*fpm'
php8.2-fpm.service                 loaded active running   The PHP 8.2 FastCGI Process Manager

What it means: PHP-FPM 8.2 is running.

Decision: Any config changes must be applied to the FPM config paths for PHP 8.2, and you must reload that service.

Task 3: Ask PHP-FPM what ini file it uses (via php-fpm -i)

cr0x@server:~$ php-fpm8.2 -i | grep -E 'Loaded Configuration|Scan this dir'
Loaded Configuration File => /etc/php/8.2/fpm/php.ini
Scan this dir for additional .ini files => /etc/php/8.2/fpm/conf.d

What it means: This is the authoritative location for FPM’s ini. conf.d fragments can override values.

Decision: Edit /etc/php/8.2/fpm/php.ini or add a dedicated file in conf.d (preferred for manageability).

Task 4: Check current max_input_vars for FPM config context

cr0x@server:~$ php-fpm8.2 -i | grep -i max_input_vars
max_input_vars => 1000 => 1000

What it means: Web runtime is also set to 1000 (at least from FPM’s perspective).

Decision: Raising it is justified if your WordPress admin request needs more than 1000 vars.

Task 5: Search for overrides in FPM pool configs

cr0x@server:~$ grep -R --line-number -E 'max_input_vars|php_(admin_)?value' /etc/php/8.2/fpm/pool.d
/etc/php/8.2/fpm/pool.d/www.conf:315:;php_admin_value[max_input_vars] = 1000

What it means: There is a commented-out override. If it were enabled, it would force the value for that pool.

Decision: Choose one control plane: either set it in php.ini/conf.d globally or enforce in the pool with php_admin_value. Don’t split-brain it.

Task 6: Add a dedicated conf.d file for clarity

cr0x@server:~$ sudo tee /etc/php/8.2/fpm/conf.d/99-wordpress-input-vars.ini >/dev/null <<'EOF'
; WordPress admin can exceed default input var count (menus, ACF, Woo variations).
max_input_vars = 5000
EOF

What it means: You’ve added a high-precedence config fragment (99-*) to set the value for FPM.

Decision: 5000 is a reasonable starting point for large menus. If you routinely edit thousands of variations, consider higher—after measuring.

Task 7: Reload PHP-FPM and verify it actually loaded

cr0x@server:~$ sudo systemctl reload php8.2-fpm
cr0x@server:~$ php-fpm8.2 -i | grep -i max_input_vars
max_input_vars => 5000 => 5000

What it means: FPM has the new value.

Decision: Now reproduce the WordPress save. If it still fails, you’re likely hitting a different limit (request body size, timeouts, or application logic).

Task 8: Check PHP error logs for the smoking gun message

cr0x@server:~$ sudo tail -n 50 /var/log/php8.2-fpm.log
[27-Dec-2025 11:09:31] WARNING: [pool www] child 18422 said into stderr: "PHP Warning:  Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini in Unknown on line 0"

What it means: Classic warning: PHP hit the limit and truncated input parsing.

Decision: If you see this at the time of the admin save, you can stop debating. Raise the limit (and confirm there aren’t other constraints).

Task 9: Check Nginx request body size limits (common companion issue)

cr0x@server:~$ sudo nginx -T 2>/dev/null | grep -R --line-number 'client_max_body_size' /etc/nginx
/etc/nginx/nginx.conf:36:    client_max_body_size 10m;

What it means: Nginx will reject bodies larger than 10 MB (with a 413).

Decision: If admins are uploading huge serialized builder payloads or product variation edits, you may need to raise this too. If you’re not seeing 413s, don’t touch it.

Task 10: Confirm Apache request body limits if Apache is in play

cr0x@server:~$ sudo apachectl -M | head
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)

What it means: Modules list confirms Apache is installed and what’s loaded (this snippet doesn’t show PHP handler yet).

Decision: If Apache is fronting the site, search configs for LimitRequestBody when you see 413/400 issues.

Task 11: Find which PHP handler Apache uses (mod_php vs proxy_fcgi)

cr0x@server:~$ sudo apachectl -M | grep -E 'php|proxy_fcgi'
 proxy_fcgi_module (shared)

What it means: Apache is using FastCGI proxying, usually to PHP-FPM.

Decision: Changes must be in PHP-FPM, not Apache’s php.ini (unless you also run mod_php, which you don’t here).

Task 12: Validate active php.ini path and overrides via a temporary admin-only endpoint

cr0x@server:~$ sudo -u www-data php -r 'echo "SAPI=".php_sapi_name().PHP_EOL; echo "max_input_vars=".ini_get("max_input_vars").PHP_EOL;'
SAPI=cli
max_input_vars=1000

What it means: This still shows CLI values, not web values. Useful reminder: context matters.

Decision: If you can’t safely expose phpinfo, prefer inspecting FPM directly (php-fpm8.2 -i) and logs. Avoid leaving diagnostic endpoints lying around.

Task 13: Confirm WordPress is receiving truncated POST by counting keys in a controlled test

cr0x@server:~$ sudo tee /var/www/html/wp-content/mu-plugins/input-vars-debug.php >/dev/null <<'EOF'

What it means: A must-use plugin that prints counts for admins when you add ?input_vars_debug=1 in wp-admin. This helps prove truncation without guessing.

Decision: Use briefly, then remove. Debug plugins are like ladders: useful until someone trips over them.

Task 14: Watch PHP-FPM for resource impact after raising the limit

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager | sed -n '1,15p'
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 10:55:02 UTC; 16min ago
       Docs: man:php-fpm8.2(8)
    Process: 18110 ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php8.2-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: 18106 (php-fpm8.2)
     Status: "Processes active: 1, idle: 5, Requests: 914, slow: 0, Traffic: 0.00req/sec"

What it means: You’re looking for rising “slow” counts or instability after increasing parsing capacity.

Decision: If slow requests rise, you may need to tune FPM children, timeouts, or protect wp-admin with tighter access controls rather than unlimited parsing.

Note on safety: Every one of these tasks is operationally reversible. That’s not an accident. When you’re changing production config, you want “undo” to be boring.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

The company had a “marketing-owned” WordPress site, but it wasn’t small. There were multiple languages, hundreds of landing pages, and a nav structure that kept accreting like barnacles. On a Tuesday, the head of marketing asked for a menu cleanup. An editor spent an hour reorganizing menus and hit save.

The site didn’t go down. That was the problem. It looked like a successful save, but the menu lost a chunk of items. The editor re-added them, saved again, and lost a different chunk. Support tickets started with “the header is missing links.” The social team escalated because paid campaigns were sending traffic to pages that suddenly weren’t reachable from the navigation.

Engineering assumed it was a caching issue—because most WordPress weirdness in production is caching. They purged CDN, cleared object cache, restarted PHP-FPM, and reloaded Nginx. No change. The wrong assumption was: “If the UI shows a success message, the server accepted the data.” It had not.

The fix was raising max_input_vars and verifying the warning disappeared from logs. The deeper lesson was cultural: treat admin actions as production writes. Log them, monitor them, and don’t assume “marketing changes” are harmless. They’re production changes with a different UI.

Mini-story 2: The optimization that backfired

A different org was obsessed with “hardening.” They had a checklist: reduce timeouts, shrink limits, disable anything that looks optional. Someone noticed PHP had a default max_input_vars=1000 and decided that was too generous. They dropped it to 300 globally to “reduce attack surface.”

Nothing broke immediately. The site served pages fine. Monitoring stayed green. Then the content team rolled out a new mega-menu for a seasonal campaign, plus a few multilingual variants. The menu editor became a slot machine. Sometimes it saved; sometimes it didn’t; sometimes it saved half. People blamed WordPress. People blamed the menu plugin. People blamed each other.

The optimization backfired because it reduced safety for legitimate workloads while not meaningfully improving security posture. Attackers trying to DoS your PHP parser aren’t going to politely stop at 301 variables; they’ll use other vectors. Meanwhile, your business users are now tripping over a limit that was never measured against real admin behavior.

They restored the value to 5000 for wp-admin traffic and paired it with better controls: IP allowlisting for admin, rate limiting, and WAF rules that target actual malicious patterns. Security improved. Productivity returned. The “optimization” became a cautionary tale told whenever someone wanted to “tighten” a setting without telemetry.

Mini-story 3: The boring but correct practice that saved the day

Another team ran WordPress at scale in containers. Nothing glamorous: standard images, GitOps, and the kind of config management that makes auditors yawn. They had a known set of PHP directives in a mounted config file, including max_input_vars. They also had a smoke test job that performed a wp-admin save operation in staging using a huge menu fixture.

One week, an engineer bumped the base image and unknowingly changed the PHP ini search order. The mounted file still existed, but it wasn’t being read by the FPM process. In staging, the smoke test failed: menu save resulted in missing items, and logs showed the max_input_vars warning.

Because the practice was boring and automated, the failure never reached production. They adjusted the container entrypoint to ensure the ini fragment landed in the correct conf.d directory for that image. The next pipeline run went green, and nobody outside engineering even knew there was a near miss.

That’s the whole point. The best ops wins are the ones no one has to clap for because nothing caught fire.

Common mistakes: symptoms → root cause → fix

1) Menu items disappear after saving

Symptom: You save a large menu; items vanish or reorder strangely.

Root cause: max_input_vars truncation. WordPress saves partial POST data.

Fix: Raise max_input_vars for the web runtime (FPM/mod_php) and confirm via logs that the warning disappears.

2) ACF repeater rows vanish on update

Symptom: Repeater subfields are missing after saving a post.

Root cause: Total input vars exceed limit due to nested field arrays.

Fix: Raise max_input_vars; if you’re hitting absurd counts, consider refactoring field structure or splitting content into smaller posts/meta groups.

3) Form submits but some fields arrive empty

Symptom: Submission email/CRM payload is missing random fields.

Root cause: Input vars truncated; plugin reads missing keys as empty.

Fix: Raise max_input_vars and confirm no post_max_size / body size errors. Also check cookie bloat if the form is near the threshold.

4) You increased max_input_vars but nothing changed

Symptom: You edited php.ini; warning persists.

Root cause: Wrong ini file or wrong SAPI; FPM pool override still forcing old value; service not reloaded.

Fix: Use php-fpmX.Y -i to confirm “Loaded Configuration File,” search pool overrides, reload the correct FPM service.

5) WP-Admin returns 413 Request Entity Too Large

Symptom: Save fails with 413 or blank white error page.

Root cause: Web server body size limit (client_max_body_size or LimitRequestBody) rather than input var count.

Fix: Raise the relevant server limit for wp-admin paths only if possible; don’t globally open it unless you have a reason.

6) Random admin saves fail only for some users

Symptom: One editor can’t save big forms; another can.

Root cause: Cookie differences. Some users carry larger cookie sets (analytics segments, preview tools), pushing them over the edge.

Fix: Reduce cookie bloat for wp-admin, ensure consent tools don’t inject marketing cookies into admin sessions, and raise max_input_vars if needed.

7) You raised limits and PHP-FPM memory spiked

Symptom: After the change, FPM workers use more memory, or OOM kills happen under load.

Root cause: Larger parsing workloads per request increase memory usage; wp-admin requests are heavy and serialized.

Fix: Use a sensible value, tune FPM (children, memory limits), and restrict admin access. Don’t “fix” it by unlimited values and hope.

Checklists / step-by-step plan

Step-by-step: production-safe fix for a broken menu save

1. Reproduce and timestamp the failure. You want a log correlation point.
2. Check logs for the explicit warning. If present, proceed; if absent, don’t tunnel vision.
3. Identify runtime (FPM/mod_php) and active ini paths. Use FPM introspection, not guesses.
4. Raise max_input_vars in one authoritative place. Prefer a dedicated conf.d file with comments.
5. Reload the right service. FPM reload for FPM changes; Apache reload for mod_php.
6. Verify the runtime value. Confirm via php-fpm -i or controlled admin-only output.
7. Re-test the exact editor workflow. Same menu, same steps, same user if possible.
8. Remove temporary debug instrumentation. Especially mu-plugins you added for counting.
9. Monitor for side effects. Slow requests, FPM memory, increased request times.

Checklist: don’t miss adjacent limits

• Is the server returning 413? If yes, it’s body size, not input vars.
• Is the POST body big? Check post_max_size.
• Is PHP timing out parsing? Check max_input_time and FPM terminate timeouts.
• Is a WAF blocking wp-admin POSTs? Check for 403s at the edge.
• Are cookies enormous for affected users? Compare cookie counts/size.

Checklist: sane values and guardrails

• Start at 3000 or 5000 for large sites; go higher only with evidence.
• Keep post_max_size and server body size aligned with real needs.
• Protect wp-admin: MFA, IP allowlists where feasible, rate limits, and reduced exposure.
• Track changes: config in version control or at least in a configuration management system.
• Make rollback easy: one file, one reload, one verification command.

FAQ

1) What is the default max_input_vars for PHP?

Often 1000, but “default” is a moving target: distro packages, hosting panels, and hardened builds can change it. Verify the active runtime value.

2) Why does WordPress say “Menu saved” when it didn’t save everything?

Because WordPress only sees what PHP parsed. If PHP truncates inputs, WordPress receives a valid (but incomplete) dataset and processes it normally.

3) Is this a WordPress bug?

No. It’s a server-side PHP parsing limit. WordPress could arguably warn better, but the root cause is configuration and request size.

4) How high should I set max_input_vars?

For many sites, 3000–5000 works. WooCommerce variable products and heavy page builders may need 10000+. Measure, then set the smallest value that stops truncation.

5) If I raise max_input_vars, do I need to restart anything?

Yes. For PHP-FPM you must reload/restart the FPM service. Reloading Nginx or Apache alone won’t apply PHP ini changes unless you’re using mod_php.

6) I changed php.ini but phpinfo still shows the old value. Why?

Most commonly: you edited the wrong php.ini (CLI vs FPM), a pool-level override is forcing another value, or the service wasn’t reloaded. Use php-fpm -i to confirm loaded config files.

7) Can cookies really affect max_input_vars issues?

Yes. Cookies are input variables too. Usually the POST body is the main culprit, but large cookie payloads can push borderline requests over the limit.

8) Is there a security downside to raising it?

It can increase parsing work and memory usage per request, which can be abused in DoS scenarios. Mitigate with wp-admin access controls, rate limiting, WAF rules, and reasonable request size limits.

9) Does max_input_vars affect file uploads?

Not directly. File uploads are governed by body size limits (upload_max_filesize, post_max_size, and web server body limits). But upload forms can also have many input fields, so both can matter.

10) Can I fix it in WordPress without touching server config?

Sometimes you can reduce input variable count by simplifying menus, splitting forms, reducing repeater complexity, or avoiding plugins that generate massive hidden fields. But if the site legitimately needs the complexity, the correct fix is server configuration.

Conclusion: production-safe next steps

If WordPress menus or complex forms “save” but don’t actually save, treat it as data loss. Not a nuisance. The most common culprit is max_input_vars truncation, and it’s diagnosable with logs and a couple of runtime checks.

Do this next, in order:

1. Reproduce the failure and check PHP-FPM logs for the “Input variables exceeded” warning.
2. Confirm which PHP runtime serves wp-admin and where it loads configuration from.
3. Raise max_input_vars to a measured value (often 5000), reload the correct service, and verify the runtime value.
4. Re-test the exact admin workflow and watch for adjacent limits (413s, size/timeouts).
5. Put the config change somewhere durable (conf.d fragment, IaC, container mount) so it survives the next deploy.

The best fix is the one that doesn’t require heroics at 4 a.m. Set it, verify it, and make the change reproducible. Your editors will never thank you. That’s how you’ll know it worked.