WordPress Settings Not Saving? Fix the max_input_vars Limit

You edit a page in Elementor, save it, and reload — and half your widget settings are just gone. No error, no warning, nothing in the WordPress debug log. If that sounds familiar, the culprit is almost never the plugin. It's a PHP setting called max_input_vars quietly truncating your form submission before WordPress ever sees the missing fields.

Symptom: What You'll Notice

This one is sneaky because it doesn't throw a clean error. What you'll actually see is:

• Elementor or Divi widgets reverting to default styling after you save, even though the save "succeeded"
• WooCommerce bulk product edits or attribute lists losing entries midway through
• ACF (Advanced Custom Fields) repeater rows disappearing on large forms
• Theme Customizer or plugin option pages with dozens of toggles — some just don't stick
• Import tools (WP All Import, Customizer export/import) stopping partway with no visible failure

The pattern is always the same: the more fields a form has, the more likely it fails, and it's inconsistent — smaller edits save fine, big ones don't.

Why This Happens: The max_input_vars Limit

PHP caps how many input variables (POST fields, GET fields, cookies) it will accept in a single request via the max_input_vars directive. The default in most PHP builds is 1000.

That sounds like a lot until you look at what a modern page builder actually submits. A single Elementor page with 20-30 widgets can easily generate 2,000-5,000 individual input fields, because every widget setting (color, padding, font, breakpoint, animation) is its own array entry in the form POST. WooCommerce variable products with many attributes and variations do the same thing.

When PHP hits the cap, it doesn't error out — it just silently stops accepting fields past the limit. WordPress receives a truncated $_POST array, saves what it got, and reports success because, as far as it knows, nothing went wrong.

This is different from upload_max_filesize or post_max_size, which cause outright rejected uploads. It's also different from max_execution_time, which causes a timeout. max_input_vars fails quietly, which is exactly why it's so often misdiagnosed as "a bug in the plugin."

How to Confirm This Is Your Issue

Before changing server settings, verify the limit is actually the problem:

1. Check your current value. Create a temporary PHP file (or use WP-CLI) with:

   <?php echo ini_get('max_input_vars');

   or via WP-CLI:

   wp eval "echo ini_get('max_input_vars');"

2. Compare that number to roughly how many fields your form generates. For Elementor, right-click the page in a browser, view source on the edit screen, or just count: 30+ widgets with 40-80 settings each will blow past 1000 fast.
3. Enable PHP's own warning by temporarily adding this to wp-config.php just to observe behavior (remove after testing):

   ini_set('display_errors', 1);

   You usually won't see a hard error, which itself is a strong signal — a silent partial-save with no logged exception points straight at max_input_vars.

The Fix: Raise max_input_vars

Where you make this change depends on your hosting setup. Pick the method that matches your Getwebup plan.

Option 1: Shared Hosting via MultiPHP INI Editor (cPanel)

This is the fastest route on cPanel-based shared or reseller hosting:

1. Log in to cPanel → open MultiPHP INI Editor
2. Select your domain from the dropdown
3. Switch to Editor Mode and find (or add) the line:

   max_input_vars = 3000

4. Click Apply — no restart needed, it takes effect on the next request

If max_input_vars isn't listed by default, just add it as a new line; cPanel's PHP handler picks it up.

Option 2: php.ini via File Manager

If MultiPHP INI Editor isn't available on your plan, edit php.ini directly in your home directory (create it if it doesn't exist):

max_input_vars = 3000
max_input_time = 120
memory_limit = 256M

Bumping max_input_time alongside it helps too — large forms with many fields take longer to parse, not just more memory to hold.

Option 3: VPS with PHP-FPM

On a Getwebup VPS running PHP-FPM (Nginx or Apache), edit the pool config directly:

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

Add or update:

php_admin_value[max_input_vars] = 3000

Then reload PHP-FPM:

sudo systemctl reload php8.2-fpm

Adjust the version number to match your installed PHP. You can also set it in the global php.ini at /etc/php/8.2/fpm/php.ini, but the per-pool override is safer if you host multiple sites on the same VPS with different needs.

What Doesn't Work

Don't bother trying to set this in .htaccess with php_value on most modern setups — max_input_vars is PHP_INI_PERDIR, meaning it can only be set in php.ini, a pool config, or (on some Apache+suPHP configs) a directory-level php.ini. It will not work through .htaccess on LiteSpeed or PHP-FPM, which covers most Getwebup hosting. If you add it to .htaccess and it has no effect, that's why — move it to one of the methods above.

Which Tools Hit This Limit Most

Prevention: Keep This From Recurring

• Set it once, generously. There's little downside to running 3000-5000 instead of the 1000 default — memory overhead per request is negligible.
• Re-check after PHP upgrades. Changing PHP versions in MultiPHP Manager can reset custom php.ini values if you didn't set them per-version. Verify after any version switch.
• Watch large ACF/Elementor pages specifically. If a client site regularly builds huge landing pages, set the limit high from day one rather than waiting for a support ticket.
• Pair it with adequate memory_limit. A high max_input_vars with a low memory_limit (like 64M) can just trade one silent failure for a different one.

If you've raised the limit and fields are still vanishing, the next thing to check is a security plugin or WAF rule stripping large POST bodies before PHP even processes them — that's a separate issue from max_input_vars, but it produces a nearly identical symptom.