You hit Save, refresh the page, and part of your menu or settings panel has vanished. Frustrating? Absolutely. The likely culprit is a PHP limit called WordPress max input vars.
This setting is easy to raise, but it shouldn’t be treated like a mystery switch. A smart change fixes the blocked form, keeps your site stable, and avoids piling huge limits onto a shared server. Let’s get the right number in place.
What WordPress max input vars actually controls
max_input_vars is a PHP setting, not a WordPress setting. It limits how many input fields PHP will accept during one request.
PHP’s documented default is 1,000 variables. The limit applies separately to $_GET, $_POST, and $_COOKIE. When a form sends more fields than PHP allows, PHP drops the extras before WordPress gets a chance to save them.
You can review the directive in PHP’s runtime configuration documentation. The important part is simple: this is a server-level limit with real consequences.
Why a WordPress site can hit the limit
A form can contain far more fields than you see on screen. Hidden fields, repeaters, menu-item settings, product attributes, and page-builder controls all count.
Large WordPress navigation menus are a classic example. So are theme option screens with dozens of toggles, WooCommerce products with many variations, and complex form-builder layouts.
The failure is often silent. Your page loads. Your site stays online. But the last portion of submitted data never saves.
When only the final menu items or settings disappear after a save, PHP likely cut off the request before WordPress processed it.
What this setting does not fix
Raising the limit won’t repair every save issue. A plugin conflict, expired login session, low PHP memory limit, firewall rule, or database error can cause similar symptoms.
Start with the evidence. If a plugin reports that PHP max input vars is too low, or your changes disappear only on a large settings screen, you’ve found a strong lead.
Spot the problem before changing server settings
Don’t raise limits blindly. We recommend confirming which page fails, how it fails, and whether the issue repeats.
That takes a few minutes. It can save you from changing the wrong PHP setting and wondering why nothing improved.
Look for partial saves and PHP warnings
Try saving a smaller version of the same form. If it works, then fails once you add more menu items or fields, the input limit is likely involved.
Some hosts log a warning when the cap is reached. It may say that the number of input variables exceeded max_input_vars. You might see it in a PHP error log, a hosting dashboard, or a plugin health report.
Beaver Builder also identifies this pattern in its guide to PHP max input vars errors. The issue is not the builder itself. The submitted settings simply contain more fields than PHP accepts.
Rule out the usual suspects
Before editing configuration files, test the save with plugins temporarily deactivated. Clear any server, plugin, or CDN cache. Then try again with a current WordPress theme if the issue is isolated to a theme options screen.
Also check your PHP version and available memory. A crowded site with an outdated PHP stack can develop several problems at once.
A reliable hosting account gives you room to check those basics without digging through server commands. Our WordPress hosting with 24/7 support includes backups, security tools, and WordPress-ready controls when you need a quick, human answer.
Choose a safe new limit for the form you have
The goal isn’t to set the largest possible number. The goal is to give your biggest legitimate form enough space.
PHP uses this limit as a security control against certain denial-of-service attacks. Raising it moderately is normal for a busy WordPress site. Raising it to a huge number “just in case” is not smart server housekeeping.
Start at 2,000 or 3,000
For a medium-sized menu or options panel, 2000 or 3000 is often enough. Test the original form after making the change.
If it still cuts off, move to 5000. This is a common practical setting for WordPress sites with large menus, detailed product edits, or feature-heavy page builders. cPanel guidance and many hosting environments use 5000 as a working example.
| Site situation | Practical starting value |
|---|---|
| Small settings pages and short menus | 1000 to 2000 |
| Larger menus or plugin settings | 3000 |
| WooCommerce variations or complex builders | 5000 |
The best value is the lowest one that reliably saves your real form. If 3,000 works, there is no prize for setting 20,000.
Count hidden fields in heavy admin pages
One menu item can create several submitted fields. A product variation can create many more. That’s why a screen with 150 visible choices may still hit a 1,000-variable limit.
Acquia’s notes on forms that exceed PHP’s input variable limit make the point well: reducing unnecessary form fields is sometimes a better fix than raising the cap again.
Clean up abandoned menu items, unused product data, and bloated option panels where you can. Less clutter means faster editing and fewer surprises.
Increase WordPress max input vars in cPanel
For most shared hosting accounts, cPanel’s PHP settings area is the safest route. It changes the setting at the account or domain level without asking you to edit files by hand.
First, back up your site. Configuration changes are usually low-risk, but we don’t gamble with a live business website. A current restore point gives you confidence to test properly.
Use MultiPHP INI Editor when it is available
Open cPanel and search for MultiPHP INI Editor, PHP Settings, or a similar tool from your host. Select the domain that runs WordPress.
Find max_input_vars, enter your chosen value, such as 3000 or 5000, then save the change. Some panels show the current and new values side by side. That makes the job refreshingly simple.
If you manage several sites, confirm you selected the correct domain. Changing PHP settings for example.com won’t help a WordPress install running on shop.example.com.
Our cPanel hosting for WordPress puts common site-management tools in one familiar dashboard, which makes these routine checks much less painful.
Allow time for PHP to reload
A panel-based change may work right away, but some PHP handlers take a few minutes to read a new configuration value. Clear your WordPress cache, wait briefly, then test the exact admin screen that failed.
Don’t test with a blank form. Recreate the large menu, product, or settings page that caused the problem. A green success message means little if the final fields still disappear after refresh.
Use a .user.ini file when the panel has no option
No PHP editor in your hosting account? A .user.ini file is usually the next best choice on PHP-FPM and CGI hosting.
Create the file in your WordPress document root, often public_html, www, or the folder containing wp-config.php. Add this single line:
max_input_vars = 5000
Save the file, then wait for PHP to detect it. Many servers scan .user.ini files on a schedule, so the update may not appear instantly.
Keep the file in the right directory
A .user.ini in the wrong folder won’t affect your WordPress site. If WordPress lives in public_html/store, place the file in that folder unless your host tells you otherwise.
The setting is directory-based. PHP documents max_input_vars as INI_PERDIR, which is why a per-site PHP file is a better fit than a normal WordPress function.
This is also why moving to a hosting plan with clear PHP controls can be worth it. When a site grows, server settings should support your work instead of turning every fix into a support ticket.
Treat wp-config.php and .htaccess as fallbacks
You may find advice telling you to add this to wp-config.php:
@ini_set( 'max_input_vars', 5000 );
It can work on some hosts. It can also be ignored, because this setting is not meant to be changed by every running PHP script. We don’t treat it as the first choice.
You may also see this .htaccess directive:
php_value max_input_vars 5000
Use it only if your host confirms Apache with mod_php supports it. On PHP-FPM or CGI, it may do nothing or trigger a server error. Hosting setup matters. If you are outgrowing shared limits and want more control, compare shared hosting and VPS hosting before making a bigger move.
Verify the live setting, then protect the change
A saved file isn’t proof. Your hosting provider may override it, the file may be in the wrong directory, or the site may use a different PHP version than expected.
Check the live value before calling the job done.
Use Site Health or a temporary phpinfo file
In WordPress, go to Tools > Site Health > Info > Server. Look for the PHP max input variables value. Some host dashboards also show it in the PHP settings area.
For a direct check, create a temporary file named phpinfo.php in the WordPress root with:
<?php phpinfo(); ?>
Open it in your browser and search the page for max_input_vars. Check the Local Value, not only the master setting. Delete that file immediately afterward. It exposes detailed server information and should never stay public.
Then return to the problem page, save the full form, refresh it, and confirm every field remains. That is the test that matters.
Keep backups close before admin work
Big menu edits, theme changes, and plugin setting updates can all go sideways for reasons beyond PHP. Backups turn a stressful moment into a quick restore.
Our website backup service gives you a practical safety net before you change server settings or make a large round of WordPress edits. Make the backup first. Make the change second. Test with confidence.
A Better Limit, Without the Guesswork
WordPress max input vars issues can look like random broken saves, but the pattern is clear once you know where to look. Check the failed form, raise the setting gradually, and verify the live PHP value before moving on.
Start with 3000 when the form is moderately large. Move to 5000 only when your real workload needs it. Keep a current backup ready, and use a hosting setup that gives you control when your site asks for more. Reliable WordPress management starts with settings you can trust.
