You've set up your theme, added a dozen plugins, configured custom fields, and then WordPress stops saving menu settings. You click "Save," but some menu items simply disappear.

This isn't an admin panel glitch or a plugin issue. PHP on the server has hit the max_input_vars input variable limit and silently truncates data coming from the form. By default, the limit is 1000, which is clearly insufficient for a modern WordPress setup with a couple of heavy plugins.

Below are three ways to increase the limit: from a quick.htaccess edit to hosting panel settings. All methods have been tested on Apache and PHP-FPM and work from PHP 7.4 through 8.4.

What is max_input_vars and how does the error manifest

max_input_vars is a PHP directive that limits the number of variables accepted from GET, POST, and COOKIE requests. The restriction applies to each superglobal array separately: POST variables are counted independently from GET and COOKIE.

For a small business card website, a thousand variables is more than enough. But the WordPress admin panel generates dozens of fields for each entity: menu items, widgets, customizer options, plugin metaboxes. When a menu form contains 80 items, each transmitting 12-15 variables, the limit is exceeded invisibly and part of the data is lost during saving.

Symptoms that indicate this specific problem:

• Menu items don't save or save only partially.
• Widgets spontaneously reset to inactive.
• A plugin (such as an SEO plugin or page builder) loses some settings after saving.
• In Site Health (Tools → Site Health → Info → Server), the PHP max input variables value equals 1000 or less.

The standard WordPress community recommendation is to raise the limit to 3000. This is sufficient for most setups. Sites with particularly heavy admin panels (multi-level menus with 100+ items, Mega Menu, dozens of ACF fields) can safely set 5000 or even 10000, as this has virtually no impact on server performance.

💡 Quick overview:

• Check the current limit: phpinfo() or Site Health in the WordPress admin.
• Method 1: add php_value max_input_vars 3000 to your.htaccess file, works with Apache using mod_php.
• Method 2: add max_input_vars = 3000 to php.ini or.user.ini, suitable for PHP-FPM.
• Method 3: change the value through the hosting panel, an option for those without direct access to server files.

Method 1: editing.htaccess

This method works when PHP runs as an Apache module (mod_php). You can determine this in Tools → Site Health → Info → Server: the Server architecture line contains Apache, and the PHP handler is listed as a module, not FPM/FastCGI.

Before editing, make a backup of.htaccess: download the file via FTP or your hosting's file manager to your computer. Edits to this file are syntax-sensitive; an extra space or line break can bring down the site with a 500 error.

Open.htaccess (located in the site root, next to wp-config.php) and add the line:

1
php_value max_input_vars 3000

If the server has the Suhosin extension installed (rare in 2026 but still found on older shared hosts), one line isn't enough. Add three directives:

1
php_value suhosin.request.max_vars 3000
2
php_value suhosin.post.max_vars 3000
3
php_value suhosin.get.max_vars 3000

Suhosin intercepts variables before PHP and truncates them independently of max_input_vars, hence the additional set of lines.

After saving.htaccess, open WordPress admin → Tools → Site Health → Info → Server and verify that PHP max input variables shows the new value. If it hasn't changed, read the section "What to do if the limit still doesn't change" below.

Method 2: editing php.ini or.user.ini

On modern servers, PHP most often runs through PHP-FPM, and php_value directives in.htaccess are ignored. The working tool here is php.ini or.user.ini.

.user.ini is processed by PHP-FPM on a per-directory basis: the file is placed in the site root and applies recursively to all subdirectories. Unlike .htaccess, which Apache reads on every request, this is PHP's standard mechanism, supported since version 5.3.

Create (or edit an existing) .user.ini file in the site root and add:

1
max_input_vars = 3000

If you have access to the global php.ini (VPS/dedicated server), change the value there as well. The exact path to php.ini can be found via phpinfo(): look for the Loaded Configuration File line. After editing php.ini, a PHP-FPM restart is required:

1
sudo systemctl restart php8.2-fpm

Replace the version number in the command with your own (8.1, 8.2, 8.3, 8.4). Check the new value through Site Health; it should update immediately.

If the .user.ini file doesn't exist, simply create it in a text editor. The name starts with a dot, so you may need to enable hidden file display in your hosting's file manager.

Method 3: changing the limit through the hosting panel

For shared hosting (cPanel, ISPmanager, DirectAdmin), the simplest approach is to change the value through the graphical interface without touching files manually.

cPanel: go to Select PHP Version → switch to the Options tab. Find the max_input_vars line, change the value from 1000 to 3000, and click Save. The change applies instantly; no restart is required.

ISPmanager: PHP section → settings → additional parameters → max_input_vars.

DirectAdmin: PHP Settings → find the directive in the list → change → save.

If the panel doesn't have a max_input_vars field, the hosting uses a hardcoded php.ini without editing rights. In this case, only contacting support will help: submit a ticket requesting to raise max_input_vars to 3000 (or whatever specific value you need). Most hosts change the limit upon first request; this is a routine operation.

What to do if the limit still doesn't change

Situation: lines in.htaccess and.user.ini are in place, the hosting panel shows the new value, but Site Health stubbornly shows 1000. Causes and their solutions:

Wrong method for the change. max_input_vars belongs to the PHP_INI_PERDIR mode: the directive can only be changed in php.ini,.htaccess,.user.ini, or httpd.conf. The ini_set() function in wp-config.php has no effect on it; the code @ini_set('max_input_vars', 3000) executes the operation, but PHP silently ignores it. Don't waste time on this method.

PHP configuration cache. Some panels (especially cPanel with PHP-FPM) cache ini files. After editing.user.ini, wait 5 minutes; this is how long PHP-FPM by default keeps the configuration cache for a specific directory. You can speed up the process by restarting PHP-FPM from the hosting panel.

Two php.ini files. On shared hosting, there's often a global php.ini in one folder and a local one in another. PHP picks up the first one found at startup. Check the path to Loaded Configuration File via phpinfo() and edit that specific one. The additional Scan this directory for additional .ini files may also contain the limit; check this folder too.

Hard hosting limit. Some providers block changes to max_input_vars at the container level (CloudLinux with PHP Selector limits). In phpinfo(), the directive is marked as no value or doesn't appear at all. This means the hosting has set a ceiling above user edits; only a support ticket or plan upgrade will help.

⁉️🤔 Frequently asked questions

How much exactly should I set: 3000 or more?

For the vast majority of WordPress sites, 3000 is enough. This value covers menus up to 120 items, admin panels with a dozen active plugins, and customizer pages with ten sections. Set 5000 if you use Mega Menu with 150+ items, a builder like Elementor with hundreds of fields per page, or ACF with flexible layouts. Above 10000, only if the plugin developer explicitly specifies it in the documentation.

Why did the limit reset to 1000 after a PHP update?

Updating the PHP version through the hosting panel often pulls in the default php.ini. Check.user.ini and the panel; most likely the file is still there, but the hosting switched the pool to a new config without your edits.

Can I set the limit through wp-config.php?

No. The max_input_vars directive has PHP_INI_PERDIR mode and cannot be changed via ini_set(); PHP will silently ignore such a call. Only.htaccess (on Apache with mod_php),.user.ini / php.ini, and the hosting panel work.

How can I tell if the problem is specifically max_input_vars and not something else?

The most accurate indicator is PHP logs. Enable WP_DEBUG in wp-config.php: define('WP_DEBUG', true);. After a failed form save, check /wp-content/debug.log: if there's an entry Warning: Input variables exceeded 1000, the diagnosis is confirmed.

What should I do if my hosting won't let me change the limit?

Contact support with a specific number (for example, "raise max_input_vars to 3000"). This is a standard request; support fulfills it free of charge at most providers. They refuse in two cases: an extremely cheap plan with strictly fixed limits (then only an upgrade helps) or a site on shared hosting with hundreds of neighbors where individual limits aren't architecturally supported.

Summary: which method to choose for your situation

Order of actions, from simplest to most complex.

If you're on shared hosting with cPanel, start with method 3 (panel). It takes three clicks, and in most cases the problem is solved. If the value doesn't change in Site Health, try method 2 via.user.ini: the file goes in the site root and is picked up by PHP-FPM automatically.

If you have a VPS or dedicated server with Apache and mod_php, method 1 (.htaccess) gives instant results and doesn't require restarting services. For an Apache + PHP-FPM setup, use method 2 (php.ini or.user.ini).

If the panel doesn't allow editing, support isn't responding, and the limit is stuck at 1000, you may have outgrown your current plan. WordPress setups get heavier every year: more fields, more data, higher server environment requirements. Switching hosting to a more flexible plan solves the problem radically and also improves overall site performance.

Start by checking Site Health right now: Tools → Site Health → Info → Server → PHP max input variables. If it shows 1000 or less, any of the three solutions above will restore your control over the admin panel in 5 minutes.