PrestaShop max_input_vars: Why Products With Many Combinations Won't Save

Understanding max_input_vars in PrestaShop

If you have ever tried to save a product with dozens or hundreds of combinations in PrestaShop and received a silent failure, a partial save, or a cryptic error, the culprit is almost certainly the PHP max_input_vars directive. This setting controls how many individual form fields PHP will accept in a single POST request. When PrestaShop submits a product form that exceeds this limit, every field beyond the threshold is silently discarded, leading to incomplete saves, missing combinations, or data that simply vanishes without any visible error message.

By default, most PHP installations ship with max_input_vars set to 1000. For a simple blog or brochure site, that is more than enough. For PrestaShop, however, product editing pages can generate thousands of form fields, especially when combinations, multi-language fields, and custom features are involved. Understanding this directive, knowing how to calculate the value your store actually needs, and applying the fix correctly will save you hours of debugging.

Why PrestaShop Needs High max_input_vars Values

PrestaShop's product editing form is one of the most complex forms in any e-commerce platform. Each combination of a product generates multiple input fields: one for the price impact, one for the weight impact, one for the quantity, one for the reference, one for the EAN-13, one for the UPC, one for the MPN, one for the minimum quantity, one for the low stock threshold, one for the availability date, and several more depending on your configuration. A single combination can easily produce 15 to 25 form fields.

Now multiply that by the number of combinations. A t-shirt available in 5 sizes and 10 colors has 50 combinations. At 20 fields per combination, that is already 1,000 fields just for the combinations tab. Add the base product fields, SEO fields for each language, feature values, specific prices, and other tabs, and you can easily reach 1,500 to 2,000 fields for a moderately complex product.

For stores selling products with extensive attribute sets, such as electronics with different storage capacities, colors, RAM options, and regional variants, a single product can have 200 or more combinations, generating 4,000+ form fields. The default limit of 1,000 is not even close to sufficient.

Symptoms of max_input_vars Being Too Low

The most frustrating aspect of hitting the max_input_vars limit is that PHP does not throw an error. It silently truncates the input data. This means you will see a variety of confusing symptoms without any clear indication of what went wrong.

The most common symptom is that combinations disappear after saving. You create 80 combinations, click save, and when the page reloads only 40 are present. The form submitted all 80, but PHP only processed the first portion of the POST data before hitting the limit, so the remaining combinations were never received by the server.

Another common symptom is that product data partially saves. The basic information tab saves correctly, but the pricing, SEO, or combinations data is lost. This happens because the form fields are submitted in a specific order, and whichever fields come after the cutoff point are discarded.

You may also experience the product page simply reloading without saving at all, or PrestaShop displaying a generic error such as "An error occurred while updating the product." In PrestaShop 1.7 and 8.x, the Symfony-based product page may show validation errors for required fields that were actually filled in but truncated by PHP.

A less obvious symptom affects multi-language stores. If your store supports 5 languages, every text field is multiplied by 5. A product that saves fine on a single-language store fails on a multi-language one because the additional language fields push the total past the limit.

How to Check Your Current max_input_vars Value

Before making changes, verify your current setting. Create a PHP file in your PrestaShop root directory (remember to delete it afterward for security):

<?php phpinfo(); ?>

Access this file through your browser and search for max_input_vars. You will see both the Local Value (what is currently active) and the Master Value (the default from php.ini). Pay attention to the Local Value, as it may differ from the Master Value if an .htaccess or per-directory configuration overrides it.

Alternatively, you can check from the PrestaShop back office. Navigate to Advanced Parameters, then Information. The PHP configuration section displays key PHP settings including max_input_vars. PrestaShop 1.7.7 and later versions also display a warning on this page if the value is considered too low.

Calculating the max_input_vars Value You Need

Rather than blindly setting a high number, you can estimate the value your store requires. Use this formula as a baseline:

Required value = (number of combinations x fields per combination) + base product fields + (text fields x number of languages) + safety margin

For a practical example, consider a store with 3 languages and a product that has 100 combinations. The calculation would look like this: 100 combinations multiplied by 20 fields each equals 2,000. The base product fields across all tabs contribute roughly 200. Text fields (name, description, meta title, meta description, link rewrite, and others) multiplied by 3 languages add another 150. Adding a 20% safety margin brings the total to approximately 2,820.

For most PrestaShop stores, setting max_input_vars to 10000 provides ample headroom. Stores with products that have 300+ combinations or that operate in 5+ languages should consider 20000 or even 50000. The memory overhead of a higher value is negligible on modern servers.

How to Increase max_input_vars

Method 1: php.ini (Recommended)

If you have access to your server's PHP configuration, editing php.ini is the cleanest approach. Locate your php.ini file (the phpinfo() output tells you exactly which file is loaded) and find or add the following line:

max_input_vars = 10000

After saving the file, restart your web server or PHP-FPM service for the change to take effect. On Apache with mod_php, restart Apache. On Nginx with PHP-FPM, restart the php-fpm service. The exact command depends on your operating system and PHP version.

Method 2: .htaccess (Apache with mod_php or mod_fcgid)

If you do not have access to php.ini, such as on shared hosting, you can try adding the directive to the .htaccess file in your PrestaShop root directory:

php_value max_input_vars 10000

This method only works if PHP is running as an Apache module (mod_php). If your host uses PHP-FPM or CGI, this directive will cause a 500 Internal Server Error. In that case, remove the line immediately and try the next method.

Method 3: .user.ini (PHP-FPM / CGI)

For servers running PHP-FPM, create or edit a .user.ini file in your PrestaShop root directory:

max_input_vars = 10000

Note that .user.ini changes are not immediate. PHP caches this file for a period defined by user_ini.cache_ttl, which defaults to 300 seconds (5 minutes). Wait at least 5 minutes after saving the file before testing.

Method 4: Hosting Control Panel

Many hosting providers expose PHP settings through their control panel. In cPanel, navigate to "Select PHP Version" or "MultiPHP INI Editor" and look for max_input_vars. In Plesk, go to PHP Settings for your domain. DirectAdmin and other panels have similar options. This is often the easiest method on shared hosting.

The Suhosin Patch Complication

Suhosin is a PHP security patch that was common on older servers, particularly those running PHP 5.x. It imposes its own set of input limits that override the standard max_input_vars setting. Even if you increase max_input_vars to 10000, Suhosin may still enforce a lower limit through its own directives.

The Suhosin-specific settings you need to adjust are:

suhosin.post.max_vars = 10000
suhosin.request.max_vars = 10000

These must be set in addition to the standard max_input_vars. If your phpinfo() output shows a Suhosin section, you are affected and must adjust all three values. Suhosin settings can typically only be changed in php.ini, not in .htaccess or .user.ini.

On modern PHP 7.x and 8.x installations, Suhosin is rarely present. If you are running a recent PHP version, you almost certainly do not need to worry about it. However, if you are on an older shared hosting account that has not been updated, it is worth checking.

Alternative Approaches for Products With 500+ Combinations

While increasing max_input_vars solves the immediate problem, stores with extremely large numbers of combinations per product should consider alternative approaches that reduce the form field count or avoid the limitation entirely.

Import Combinations via CSV

PrestaShop's built-in import functionality processes combinations through file upload rather than form submission, completely bypassing the max_input_vars limit. Prepare a CSV file with your combination data and import it through the back office under Advanced Parameters, Import. This is often the most practical approach for products with hundreds of combinations.

Use the PrestaShop Webservice API

The PrestaShop webservice API allows you to create and update combinations programmatically. API requests are not subject to max_input_vars because they use structured XML or JSON payloads rather than form-encoded POST data. This approach requires technical knowledge but scales to any number of combinations.

Split Large Products

In some cases, it makes more business sense to split a product with 500+ combinations into multiple products. A product with 5 sizes and 100 colors could be split into 5 products, one per size, each with 100 color options. This not only avoids the technical limitation but often improves the customer experience as well.

Manage Combinations in Batches

If you must use the back office form, create combinations in smaller batches. Generate 50 combinations at a time, save, then generate the next 50. This is tedious but avoids hitting the limit without requiring any server configuration changes.

Verifying the Fix

After increasing max_input_vars, verify that the change took effect. Check phpinfo() again and confirm the Local Value matches what you set. Then test by editing your most complex product, making a small change, and saving. All combinations and data should be preserved.

If the problem persists after increasing the value, check for these additional possibilities. Your hosting provider may be overriding your settings with a global configuration. The PHP instance serving your website may be different from the one shown in a CLI phpinfo(). There may be a web server limit such as Apache's LimitRequestBody or Nginx's client_max_body_size that is also truncating the request. Some web application firewalls (WAF) or security plugins (like ModSecurity) impose their own limits on POST data size and number of parameters.

Related PHP Settings to Check

While you are adjusting max_input_vars, review these related settings that can also cause issues with large product forms:

post_max_size: This sets the maximum size of POST data in bytes. If your form data exceeds this limit (typically when products have many large text fields across multiple languages), the entire POST is discarded. Set this to at least 32M for PrestaShop.

memory_limit: Processing thousands of form fields requires memory. If PHP runs out of memory while parsing the input, the request fails. A value of 256M or 512M is recommended for PrestaShop.

max_execution_time: Saving a product with many combinations involves numerous database queries. If the save operation takes longer than the allowed execution time, it will be terminated mid-process, leading to partial saves. Set this to at least 300 seconds for stores with complex products.

max_input_nesting_level: PrestaShop uses nested arrays in its form data (for example, multi-language fields use arrays like name[1], name[2]). The default nesting level of 64 is usually sufficient, but if you encounter issues with deeply nested form structures, increase it to 128 or 256.

PrestaShop Version-Specific Notes

In PrestaShop 1.6, the product page is entirely legacy PHP with a traditional form submission. The max_input_vars issue affects all operations on the product page. There is no workaround other than increasing the limit or using imports.

PrestaShop 1.7 introduced a partially Symfony-based product page. While the architecture changed, the underlying form submission still uses POST data and is still subject to the same PHP limits. The Symfony form component may display more informative error messages when fields are missing, but the root cause is the same.

PrestaShop 8.x features a completely redesigned product page with a new Symfony form structure. The combination management was significantly reworked, with combinations now managed through a dedicated interface that loads and saves data via AJAX in smaller batches. This architectural change naturally reduces the impact of max_input_vars for combination data, though the main product form can still be affected in multi-language stores with many features.

PrestaShop 9.x continues the trend toward AJAX-based data handling, further reducing the dependency on massive form submissions. However, max_input_vars remains relevant for bulk operations and legacy modules that still use traditional form submissions.

Preventing Future Issues

Set max_input_vars to a generous value during your initial PrestaShop installation rather than waiting for problems to appear. A value of 20000 is safe for virtually all scenarios and has no meaningful performance impact. Document the setting in your server configuration notes so that future server migrations preserve it.

If you are a hosting provider or system administrator managing multiple PrestaShop installations, consider setting max_input_vars = 20000 as a default in your PHP configuration templates. This single change eliminates one of the most common support requests related to PrestaShop product management.

Monitor your error logs after making changes. While max_input_vars truncation itself does not generate PHP errors, some PrestaShop versions log warnings when they detect that received data does not match expected data. These log entries can help you identify if the limit is still being hit despite your increase.

For more details, read our guides: Product Combinations and Variants: When Your Store Needs Them and Choosing Hosting for PrestaShop: What Matters and What Is Marketing.