You update a plugin or theme, and instead of the usual success notice, WordPress shows “There has been a critical error” or the admin menu items go missing or the page fails to save with the data intact. Checking the WordPress debug log reveals “PHP Warning: max_input_vars” or a variation of it. The WordPress max input vars error is one of the most confusing PHP configuration issues because it silently truncates form data rather than showing a clear error — causing partial saves, missing settings, and broken admin functionality with no obvious explanation. This fits into the wider topic we cover in our WordPress Errors Complete Guide.
WordPress Max Input Vars — What the Limit Does
The WordPress max input vars limit is a PHP security directive that caps the number of form input fields PHP processes in a single request. The default value is 1000 — any form submitted with more than 1000 input fields has the extra fields silently discarded by PHP before WordPress receives them.
WordPress generates more than 1000 input fields in several legitimate scenarios: the Menus admin page with a large navigation menu structure (every menu item generates multiple inputs for its title, URL, class, target, and relationship fields), the Customizer with many settings, the Widgets page with many active widgets, WooCommerce product attribute settings for products with many variations, and large plugin settings pages. When the WordPress max input vars limit is exceeded on these pages, saving produces a partial result — some fields are saved, others are silently ignored. The admin shows a success notice (because WordPress received a valid save request), but the actual saved data is incomplete, missing menu items, settings reverting to previous values, or product variations disappearing.
Identify the WordPress max input vars limit as the cause: enable WP_DEBUG → trigger the failing save → check /wp-content/debug.log for “Input variables exceeded X” or similar PHP warnings. Alternatively, check the PHP error log directly (cPanel → Logs → Error Log) for entries referencing max_input_vars around the time of the save. Some hosting environments suppress these warnings, making the issue harder to identify — if admin saves are producing incomplete results with no visible error, check the current max_input_vars value (WordPress admin → Tools → Site Health → Info → Server → max_input_vars) and compare it against the number of inputs on the failing page. According to the PHP documentation, max_input_vars was introduced in PHP 5.3.9 specifically as a security measure against hash collision attacks that exploited large numbers of POST variables — it is a legitimate security feature, but its default of 1000 is too low for modern WordPress admin pages.
Increasing Max Input Vars on cPanel Hosting
The WordPress max input vars limit is a PHP ini directive that must be increased to a value that accommodates the site’s largest form — typically 3000–5000 for WordPress admin pages with complex menus or many widgets, and 10000 or more for WooCommerce stores with many product variations.
Increase via cPanel MultiPHP INI Editor: cPanel → Software → MultiPHP INI Editor → select the PHP version → find “max_input_vars” → increase from 1000 to 3000 (or higher if the site has very large menus or WooCommerce product variations) → Apply. The change applies immediately. Verify in WordPress admin → Tools → Site Health → Server section — the new value should appear within 60 seconds. Test the previously failing save — if the complete data is now saved, the WordPress max input vars increase resolved the issue.
If the MultiPHP INI Editor is not available, create a php.ini file in the WordPress root directory: max_input_vars = 3000. Or add to .htaccess (Apache with mod_php): php_value max_input_vars 3000. Or add to wp-config.php: @ini_set('max_input_vars', 3000);. The .htaccess and wp-config.php approaches work on shared hosting where direct php.ini editing is not available. After any change, verify the new value in WordPress Site Health and test the failing admin save. Our guide on increasing the WordPress upload size limit covers the same PHP configuration approaches (cPanel INI editor, php.ini, .htaccess, wp-config.php) that apply identically to the WordPress max input vars setting — the configuration method depends on the hosting environment, not the specific PHP directive being changed.
Diagnosing Which Admin Page Is Exceeding the Limit
When the WordPress max input vars issue occurs but the PHP logs are not revealing which page triggers it, a systematic approach to counting form inputs identifies the problem source and the appropriate limit to set.
Count inputs on the Menus page: Appearance → Menus → open browser DevTools → Console → run: document.querySelectorAll('input, select, textarea').length. This returns the total number of form elements on the page — if it exceeds the current max_input_vars value, the Menus save silently truncates. A navigation menu with 50 items typically generates 300–500 inputs; menus with 100+ items can exceed 1000 easily. For WooCommerce, count inputs on the product variations tab of any product with many variations — a product with 50 variations across 3 attributes can generate 2000+ inputs on the product edit screen.
The recommended WordPress max input vars values by site type: standard WordPress site with a modest menu: 3000 is sufficient. WooCommerce site with product variations: 5000–10000 depending on variation count. Large multisite installation with many active plugins per subsite: 5000. Enterprise WordPress with complex admin configurations: 10000 or higher. Setting a conservatively high value (10000) on any site does not create security or performance issues — the PHP security benefit of max_input_vars is preventing hash collision attacks, and 10000 simultaneous variables is well within the threat model protection range while eliminating all practical WordPress max input vars truncation issues. Our guide on using WordPress site health covers the Server info tab that displays the current max_input_vars alongside all other PHP configuration values — the single most useful reference for confirming configuration changes took effect across all PHP limits including max_input_vars, upload_max_filesize, and memory_limit.
Max Input Vars on WooCommerce and Page Builders
WooCommerce is the most common trigger for WordPress max input vars issues because variable products with many attributes generate large numbers of input fields on the product edit screen. A configurable product with size (S/M/L/XL/XXL), colour (10 options), and material (3 options) has 150 possible variations, and WooCommerce generates inputs for each variation’s price, stock, SKU, and weight — quickly exceeding 1000 total inputs per product edit page.
WooCommerce’s approach to managing this: the product variation inputs load via AJAX rather than all at once, meaning only the currently displayed variations are in the DOM at any time. However, the save operation still sends all variation data in a single POST request — if there are 200 variations with 10 fields each, the save sends 2000 inputs. Set max_input_vars to at least 3× the maximum expected variation count × 10 fields per variation to provide headroom. For stores with products that have hundreds of variations, 10000 or higher is the appropriate WordPress max input vars setting. After increasing the limit, verify by editing the most complex product on the site, making a small change to all variations, and confirming all changes are saved correctly — the complete test with actual product data is more reliable than input counting alone.
Page builders (Elementor, Divi, Beaver Builder) save page layouts as complex serialised data through a combination of POST fields and JSON — the number of POST fields they send depends on the page complexity but can exceed 1000 on pages with many elements and settings. If a page builder shows a save failure or silently loses elements after saving, and the hosting environment has a low WordPress max input vars value, increasing the limit resolves the save truncation. Elementor specifically uses a combination of standard POST fields for basic settings and AJAX-transmitted JSON for the page structure — the JSON transmission bypasses max_input_vars completely since it is a single POST field containing all the data. However, the initial page load and some legacy save operations still use multiple POST fields that are subject to the limit. Reviews from the WordPress support community confirm that the Menus save losing items and the WooCommerce product variation disappearing are the two most commonly reported manifestations of the WordPress max input vars limit being exceeded on standard WordPress admin operations. Our guide on fixing WordPress post not saving covers the overlapping server limit context that includes max_input_vars alongside post_max_size and memory_limit as the PHP configuration values most commonly responsible for silent save failures in the WordPress admin.
Verifying the WordPress max input vars fix is complete requires testing the actual failing operation rather than just checking the PHP configuration value. PHP configurations can be set in multiple places, and a value set in one location may be overridden by another — a php.ini file in the WordPress root might be overridden by a server-level php.ini that sets a lower limit. Always test by performing the complete save operation that was failing: navigate to Appearance → Menus → add a test menu item → Save Menu → confirm all items are present → navigate away and return to confirm the saved state matches. Similarly for WooCommerce: edit a complex product → make minor changes to several variations → save → reload → confirm all changes are present in the saved product. This end-to-end test with real data is the definitive confirmation that the WordPress max input vars increase resolved the truncation issue completely rather than just partially.
Monitoring for WordPress max input vars errors in production uses the same debug log monitoring approach as other PHP configuration issues. Add to wp-config.php temporarily: @ini_set('log_errors', 1); @ini_set('error_log', WP_CONTENT_DIR . '/debug.log'); — this logs all PHP errors including max_input_vars warnings to the debug log. After any admin save operation on a complex page, check the debug log for input variable exceeded warnings. If warnings appear despite the limit being raised, the current limit is still too low for the specific page — increase it further. For production sites where PHP error logging is not normally enabled, enable it briefly, perform the complex admin operations that were previously failing, check for warnings, then disable it again. This targeted logging approach confirms the fix without leaving debug logging permanently active on a production site.
Nginx servers with PHP-FPM (common on VPS and managed WordPress hosting) require the WordPress max input vars setting in the PHP-FPM pool configuration rather than .htaccess: edit the PHP-FPM pool file (typically /etc/php/8.x/fpm/pool.d/www.conf) → add php_admin_value[max_input_vars] = 5000 in the [www] section → restart PHP-FPM: sudo systemctl restart php8.x-fpm. The php_admin_value directive sets the limit at the pool level, overriding any .htaccess or wp-config.php ini_set attempts. Managed hosting providers that use Nginx with PHP-FPM (Kinsta, WP Engine, Gridpane) configure PHP-FPM settings through their own control panel interfaces — check the hosting dashboard for PHP settings rather than editing PHP-FPM configuration files directly on managed hosting.
The WordPress max input vars limit also affects theme option pages, plugin settings pages with many options, and import/export operations that pass large datasets through form fields. A plugin settings page with 200 individual option fields (common in comprehensive SEO plugins or page builder global settings) generates far more than 200 inputs when WordPress’s nonce fields, page identifiers, and option group markers are included. If a plugin’s settings page shows partial saves where some settings revert after saving, the WordPress max input vars limit is the most likely cause before investigating plugin-specific bugs. Increasing the limit to 5000 and retesting resolves this class of partial save failures more quickly than detailed plugin debugging. The same applies to WooCommerce settings pages — the shipping zone configuration, tax rate tables, and payment gateway settings pages all generate many form fields that can approach or exceed the default 1000 limit when many configurations are active.
The PHP max_input_nesting_level directive is related to but separate from the WordPress max input vars limit — it controls the maximum depth of nested arrays in form input names. WordPress uses nested input names for options (option[section][key] format) and menu items (menu-item-position[123] format). The default nesting level of 64 is sufficient for most WordPress use cases, but extremely complex nested option structures from premium plugins can occasionally exceed it. If after increasing max_input_vars the partial save issue persists, check whether max_input_nesting_level is also a factor — increase it to 128 using the same methods described above for max_input_vars. Both directives can be set in the same configuration file or .htaccess block, and setting both proactively eliminates both potential truncation causes in a single configuration change without requiring a second debugging cycle if the nesting limit turns out to also be a factor alongside the input variable count limit.
