If WooCommerce product variations, tax rates, or other large admin forms stop saving, check the active PHP limit first. In WordPress, go to WooCommerce > Status and read Server environment > max_input_vars. PHP’s documented default is 1,000 variables (PHP Group, 2026), while WooCommerce uses 3,000 as an example for larger forms—not as a universal requirement.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Raise the limit in the configuration used by the active PHP handler, reload that handler when necessary, then confirm the new effective value in WooCommerce Status. If the value will not change, or the request returns a 503 error, the host may control the setting or another security limit may be blocking the request.
As an Amazon Associate I earn from qualifying purchases.
What max_input_vars controls
max_input_vars is a PHP request limit. It caps how many input variables PHP accepts from one request, including fields submitted by an HTML form. PHP lists the directive as INI_PERDIR, with a documented default of 1,000 variables (PHP Group, 2026).
WooCommerce’s administration screens can submit hundreds or thousands of fields at once. A variable can be a product setting, a variation field, a tax-rate field, or another named value in the request. When a form exceeds the active limit, PHP can discard the excess variables. The page may appear to submit normally while the saved product or settings are incomplete.
#1 Best Overall
This is why the symptom is often selective: basic products may save, while a product with many variations does not; a small tax table may work, while a larger import or rate form loses rows. The browser is not the authority for the effective limit—the server-side value shown by WooCommerce is.
Check the effective value in WooCommerce first
- Sign in to the WordPress administrator.
- Open WooCommerce > Status.
- In the Server environment section, locate max_input_vars.
- Write down the value before changing anything, along with the exact form that fails.
Record whether the failure affects one product, all products with variations, tax rates, or another settings screen. This gives you a before-and-after test and helps distinguish an input-variable limit from a product, permission, database, or security problem.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallChoose a practical target value
There is no single WooCommerce value that fits every store. The correct setting is high enough for the largest form you actually submit, with headroom for additional variations or fields. WooCommerce documentation shows 3,000 as an example configuration; treat that figure as guidance for a large form, not a promise that every store needs exactly 3,000.
Use the largest real form as your baseline
Start with the screen that fails. A product with many variations generally submits substantially more fields than a simple product. If the current value is 1,000 and the form is truncated, increasing it to 3,000 provides a useful test because it follows WooCommerce’s documented example. If the form still fails, increase only after checking the actual request size and the other limits described below.
Leave reasonable headroom
Do not copy an extremely large number just because it removes the immediate error. A higher limit permits larger requests and should be chosen with the capacity and policies of the host in mind. Add enough margin for planned catalog growth, then verify that the form saves every field. If you routinely manage unusually large catalogs, ask the host what request-size and security limits apply before selecting a much higher value.
Method 1: change php.ini
php.ini is the primary server-level method when you control the PHP configuration. Add or edit the directive in the configuration file used by the PHP handler serving WordPress:
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →; php.ini
max_input_vars = 3000The number above is WooCommerce’s example. Replace it with the value appropriate for your largest form. Save the file, then reload or restart the relevant PHP service if the server stack requires it. A file edit alone does not prove that the running PHP process has adopted the change.
Confirm that you edited the active configuration
Servers can have separate PHP installations, versions, handlers, or pools. A command-line PHP configuration may not be the one used by the web server. After the reload, return to WooCommerce > Status and check Server environment > max_input_vars again. Continue only when that screen displays the intended value.
Rank #2
Method 2: use an .htaccess override where permitted
On hosts that allow per-directory PHP overrides, add this line to the site’s applicable .htaccess file:
php_value max_input_vars 3000WooCommerce documents this approach for situations such as shared hosting. It works only when the web server and PHP handler permit php_value directives. Some PHP configurations, including common PHP-FPM arrangements, do not read this directive from .htaccess; others may reject it.
Watch for a broken-site response
If adding the line causes an immediate server error, remove it or restore the previous file and contact the host. Do not leave a configuration directive in place when the active handler does not support it. Ask support which per-directory mechanism, if any, is allowed for the PHP version serving the site.
Configuration methods compared
| Method | Access required | Will it work? | Reload usually needed? | How to verify |
|---|---|---|---|---|
php.ini |
Server, virtual-server, or hosting-panel access | Works when it is the active PHP configuration | Often; reload the relevant PHP service or apply the host-panel change | WooCommerce > Status > Server environment |
.htaccess with php_value |
File access plus a host that permits overrides | Only where the web server/PHP handler supports per-directory overrides | Usually not a separate service restart, but the server must accept the directive | WooCommerce > Status; also check for server errors |
| Hosting control panel | Permission to edit the site’s PHP options | Depends on the panel and host policy | Handled by the panel or host | WooCommerce > Status after applying the change |
| Hosting support request | No server-level access needed | Best option when the value is centrally enforced | Performed by the host when required | Ask support to confirm, then verify in WooCommerce |
Apply and test the change safely
- Reproduce the problem. Note the product, variation set, tax-rate screen, or settings form that fails and identify which values disappear after saving.
- Capture the current limit. Read
max_input_varsin WooCommerce > Status > Server environment. - Estimate the form’s demand. Consider every submitted field, including the fields repeated for each variation or rate row. Use the failing form—not a smaller test product—as the baseline.
- Select a measured target. Use WooCommerce’s 3,000 example as a reasonable diagnostic increase for a large form, or choose another value that provides headroom without blindly setting an extreme limit.
- Change the active configuration. Edit
php.ini, use an approved hosting-panel control, or add the.htaccessdirective only when the host permits it. - Reload the active PHP handler. Follow the host’s procedure for the PHP service serving the website. On managed hosting, ask the provider to apply or reload the setting.
- Verify the effective value. Reopen WooCommerce Status and confirm that the displayed value changed. If it did not, the request is still using a different configuration or a centrally enforced policy.
- Retry the exact save. Save the same product or form and check every variation, rate, or setting that previously disappeared.
- Check the result over a second save. Reopen the item, confirm the values persisted, and save again only after verifying the first result.
Why the value may not change
The wrong PHP configuration was edited
The web server may use a different PHP version or handler from the one you edited. This is common when command-line PHP and web PHP are configured separately, or when a site has multiple pools. The decisive test is the value reported by WooCommerce Status after the change. If it remains at the old number, identify the active handler with the host rather than repeatedly editing unrelated files.
The host enforces a central policy
Shared and managed servers can prevent customers from overriding request limits. A local php.ini or .htaccess edit may be ignored, rejected, or overwritten. Ask hosting support to raise max_input_vars for the PHP environment serving the site and to tell you whether a per-directory override is allowed.
The PHP service was not reloaded
Some stacks read configuration only when the PHP process starts or reloads. If the file contains the new value but WooCommerce still reports the old one, follow the provider’s reload procedure. Verify again in WooCommerce before testing the form.
Recommended Free Tools
Other limits that can produce similar failures
Suhosin request limits
WooCommerce identifies suhosin.post.max_vars and related request or post limits as possible constraints on older or specialized PHP installations. Raising max_input_vars alone will not help if Suhosin imposes a lower ceiling. Ask the host whether Suhosin is installed and whether its POST limits need to be reviewed.
mod_security rules
WooCommerce warns that mod_security can block an otherwise valid submission. A blocked request may produce a 503 response rather than a quietly truncated form. Rule changes normally require the hosting provider. Give support the time of the failed request, the affected administrator URL, and the fact that the failure occurs while saving a large WooCommerce form.
PHP version and handler differences
WooCommerce notes that the host controls PHP at the server level and recommends using a current supported PHP version. A PHP-version change is separate from changing max_input_vars, but it can alter which configuration file or handler is active. If the displayed value changes unexpectedly after a PHP upgrade, recheck the WooCommerce Status screen and ask the host which configuration now applies.
Diagnose truncation versus a blocked request
| Observed behavior | Likely direction | Next action |
|---|---|---|
| The page saves, but later variation or rate fields are missing | Input variables may have been truncated | Check max_input_vars, raise it through an approved method, reload, and verify the exact form again |
| WooCommerce Status still shows the old value after editing a file | The file is not active or the host overrides it | Confirm the PHP handler and ask hosting support to apply the setting |
| The submission returns HTTP 503 | A security module such as mod_security may be blocking the request, or an invalid override may have broken the server response | Review the last configuration edit, then have the host inspect security rules and server logs |
| A small form saves but a large variation or rate form fails | The request size is near or above a server limit | Measure against the largest failing form and review related POST limits, not just the visible browser error |
When to contact your hosting provider
Escalate instead of making repeated edits when any of these conditions apply:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- You cannot access the active
php.inior PHP settings in the hosting panel. - WooCommerce Status does not display the new value after a reload.
- The host’s PHP handler does not support
php_valuein.htaccess. - The change produces a 503 or another server-level error.
- Suhosin, mod_security, or another centrally managed request limit may be involved.
- You need a substantially higher limit for a growing catalog and want to understand host capacity or policy first.
Tell support the current and desired max_input_vars values, the exact WooCommerce screen that fails, whether the request is truncated or returns 503, and the time of a recent test. Ask them to confirm which PHP handler serves the site and whether any Suhosin or mod_security rule limits the request.
Frequently overlooked details
Do not infer success from the browser
A normal-looking admin response does not establish that every submitted field reached PHP. Reopen the product or settings page and inspect the values that were previously lost. WooCommerce Status is the correct place to confirm the server’s effective directive.
Do not treat 3,000 as a mandatory WooCommerce setting
3,000 is WooCommerce’s published example for the configuration line. Your store may need less or more depending on the largest form and the number of repeated fields. Set the smallest value that reliably handles the workload with sensible growth headroom.
Do not change unrelated limits first
PHP memory, upload size, execution time, and database limits solve different classes of failures. Review them only when the observed symptom points to them. For missing fields in a large submitted form, start with max_input_vars and then investigate Suhosin or mod_security if the evidence indicates another ceiling.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsFinal verification checklist
- Before: The failing form and its missing values are documented.
- Baseline: The current value is recorded from WooCommerce > Status > Server environment > max_input_vars.
- Change: The directive was edited in the configuration actually used by the web PHP handler, or the host applied it.
- Reload: The relevant PHP service or hosting control-panel change was completed when required.
- After: WooCommerce Status displays the intended effective value.
- Functional test: The original product, variation, tax-rate, or settings form saves and retains every field.
- Escalation: If the value is unchanged or a 503 persists, the host is checking handler policy, Suhosin, mod_security, and related request limits.
For stores that cannot edit server settings themselves, managed WooCommerce hosting that permits PHP-limit changes—or a direct request to the current host—is the practical route. The important outcome is not a particular number; it is a verified effective limit that accommodates the largest form your store actually submits.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
