If a large form, a big WooCommerce cart update, or a page builder with dozens of fields is silently dropping data on submit, the cause is usually max_input_vars. PHP caps how many input variables (GET, POST, and cookie fields combined) it will accept in a single request, and once a submission goes over that cap, PHP discards the extras. There's no error, no warning in your browser: the form "saves" but some fields never make it through. To fix this, raise max_input_vars in MultiPHP INI Editor in cPanel. Log in to portal.flashcloud.com, open Services for the affected hosting account, and launch cPanel. From there go to Software → MultiPHP INI Editor.
Why this happens
PHP limits how many named fields a single request can carry, and that limit adds up fast:
- A WordPress page built with a heavy block or page-builder layout can easily have hundreds of named fields on save, especially with nested repeater blocks or widget areas.
- WooCommerce checkout and cart pages, especially with variable products or bundles, generate one input per line item, per meta field.
- Any admin form with a large repeating structure (menus with many items, ACF repeater fields, complex settings pages) can multiply quickly since every array field counts as a separate variable.
Because PHP truncates rather than errors, the usual symptom is confusing: a menu loses its last few items, a settings page only half-saves, or a WooCommerce order comes through missing some line items. If nothing in the browser console or server error log points to an obvious cause, this is worth checking early.
Raise it in MultiPHP INI Editor
In cPanel, open Software → MultiPHP INI Editor. You have two modes:
- Basic mode: select the location, and if
max_input_varsis listed among the common directives there, raise it and save. - Editor mode: select the home directory or specific docroot, and add or edit the line directly:
max_input_vars = 3000
Editor mode is useful if the directive isn't listed in Basic mode, or if you want to set several PHP values at once. Save the file.
Check it worked
Confirm the new value actually took effect before assuming the issue is fixed. Either:
- Create a small PHP file with
<?php phpinfo(); ?>, load it in a browser, and search the page formax_input_vars, or - Run
php -i | grep max_input_varsif you have SSH access via an SSH client.
If the value still shows the old default, double check you edited the correct domain or docroot in MultiPHP INI Editor. Each domain on an account can have its own PHP configuration, and it's easy to edit the wrong one on an account with several addon domains.
Related PHP settings worth checking at the same time
If you're already in MultiPHP INI Editor because a large form or import is failing, it's worth checking a few neighboring settings while you're there, since they fail in similarly silent ways:
post_max_sizeandupload_max_filesize, for uploads or large POST bodies failing separately from the input-vars issuemax_execution_time, if the form submission also involves heavy processing (large imports, bulk updates)memory_limit, if PHP is running out of memory partway through processing a large request
All of these live in the same MultiPHP INI Editor screen, so check them together instead of one at a time.
When to contact support
If you've raised max_input_vars and confirmed the new value is live, but fields are still going missing, open a ticket from the portal (Support → New ticket) or start a live chat. Mention what you changed and the confirmed new value, plus the form or page where fields are being dropped, so support can check the specific site rather than starting from scratch.