WordPress does not have a confirmed, documented maximum number of navigation items. When items vanish, a menu refuses to save, or a menu location loses its assignment after you add more links, the usual cause is PHP’s max_input_vars limit. A menu save sends every item’s fields in one request; once that request exceeds the PHP limit, PHP silently discards the excess fields before WordPress can store them.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Raise max_input_vars at the PHP level—normally to 3,000 or 5,000 for a large menu—then save and reload the menu to verify it. The exact method depends on your host: support requests are safest on shared hosting, while .htaccess, php.ini, cPanel, or wp-config.php may be available on other setups.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
What the “WordPress menu item limit” actually is
The apparent limit is usually not a WordPress menu cap. WordPress’s Appearance → Menus screen builds one form containing the fields for every menu item: title, URL, object ID, parent relationship, menu order, CSS classes, descriptions, and hidden fields used by the editor. A menu with many links therefore creates a large POST request when you click Save Menu.
PHP’s max_input_vars directive limits how many input variables PHP will accept from a request. The commonly cited built-in default is 1,000, according to MoodleDocs and an Amazon Linux security advisory. Hosts can override that value: for example, DreamHost documents a 3,000 default for its own hosting, which is a host-specific setting rather than PHP’s universal default.
If the request contains more variables than the active limit, PHP drops the excess. WordPress receives an incomplete set of fields and saves what remains. The result can look random: the last several links disappear, child items lose their parent, or a menu location appears unassigned. Usually there is no red WordPress notice and no obvious log entry.
No verified WordPress core setting establishing a hard maximum number of menu items has been identified. That does not mean every menu can grow indefinitely: server request limits, memory, timeouts, plugins, and themes can still impose practical limits. Treat max_input_vars as the first thing to check when failure starts only after a menu becomes large.
How a large menu save fails
Why the missing items are often at the end
PHP processes the submitted variables up to the configured ceiling. Fields beyond that point are omitted before WordPress handles the form. Because menu fields are serialized in a predictable order, the newest or last-rendered items are often the ones that disappear, although the exact pattern depends on the form and the fields each item generates.
Why a menu location can lose its assignment
Location assignments are submitted with the menu form too. If those fields are among the discarded variables, the menu itself may still exist while its header, footer, or other theme location appears empty. Reassigning the location before the request limit is fixed usually fails again.
Why the screen can look successful
The browser receives a normal response because PHP did not necessarily produce an error. WordPress can display its usual “Menu saved” behavior while working with incomplete input. A browser refresh then reveals that some links or assignments were never stored.
Signs that max_input_vars is the cause
- The menu saves normally when it is small but loses links after you add more.
- Only part of the menu survives a save, often the items added or edited most recently.
- A location assignment disappears even though the menu still appears in the menu list.
- There is no useful WordPress error, and the browser does not show a failed request.
- Increasing the limit makes the same menu save correctly without changing its content.
These symptoms are not proof by themselves. Plugin conflicts, theme code, and JavaScript errors can also prevent a menu from saving, so verify the PHP value and test those alternatives if the setting is already high enough.
Check the value PHP is actually using
Changing a configuration file is not the same as changing the PHP runtime used by wp-admin. Hosts may use a different PHP version, a separate PHP-FPM pool, or a configuration file that overrides the one you edited. Confirm the effective value through your host’s PHP information or settings panel, or ask support to report the value for the website’s administrative requests.
If your host exposes PHP-FPM logs, one troubleshooting guide recommends looking for an “Input variables exceeded” warning. The absence of that message is not conclusive because logging differs between hosts, but a warning that disappears after the change is useful confirmation.
Record the current value before changing it. That gives you a rollback point and helps support staff identify which configuration layer is active.
Choose the right fix
| Method | Access needed | Persistence and scope | Risk and limitations | Does it address the cause? |
|---|---|---|---|---|
| Ask hosting support | Only a support account or ticket | Set by the host for your account, pool, or server | Safest when you cannot edit PHP settings; timing depends on support | Yes |
.htaccess |
File access and an Apache server that permits PHP overrides | Usually applies to that directory and its WordPress install | Unsupported directives can trigger a 500 error; does not work on most nginx-only setups | Yes, when accepted by the host |
php.ini |
Permission to edit the active PHP configuration | May apply to an account, pool, or server; a reload may be required | Shared hosts may ignore or forbid it; editing the wrong file has no effect | Yes |
| cPanel PHP Settings editor | cPanel access | Usually account or domain level, depending on the host | Labels and available directives vary | Yes |
wp-config.php |
WordPress file access | Runs for that WordPress request only if the host allows the change | ini_set() may be disabled or too late to override the PHP-level limit |
Sometimes |
| Split the menu | Only WordPress administrator access | Immediate workaround; each smaller menu has fewer fields | Changes navigation design and does not correct the server limit | No |
Fix 1: ask your hosting provider to raise the limit
This is the preferred route on shared hosting or whenever you do not control PHP configuration. Open a support ticket and include:
Rank #3
- The domain and the affected WordPress installation.
- The symptom: menu items disappear or the location assignment is lost after saving a large menu.
- The current and requested values for
max_input_vars. - A request that the change apply to the PHP runtime serving
wp-admin, not only to a command-line PHP version. - A request for confirmation of the effective value after the change.
Guides commonly suggest starting at 3,000 and using 5,000 for especially large menus. These are practical guide values, not official WordPress recommendations. Ask support what value is appropriate for your account and whether the change has resource or security implications.
Fix 2: set max_input_vars in .htaccess
Use this only when the site runs under Apache and the host allows per-directory PHP settings.
- Back up the existing
.htaccessfile and, if possible, test the change on a staging copy. - Open the file in the WordPress document root, usually the directory containing
wp-adminandwp-content. - Add this line outside any WordPress rewrite block:
php_value max_input_vars 5000- Save the file and return to WordPress. If the host uses PHP-FPM or disallows this directive, the line may be ignored.
- Check the effective PHP value, then save and reload the menu.
If the site immediately returns a 500 Internal Server Error, remove the line using your file manager or SFTP and contact the host. Do not leave a directive that the server rejects.
Fix 3: set it in php.ini
- Locate the
php.inifile used by the website’s PHP runtime. Your host’s PHP information page or support team can identify it. - Set the directive on its own line:
max_input_vars = 5000- Save the file. Depending on the hosting architecture, restart Apache or reload PHP-FPM for the change to take effect.
- Confirm the value from the runtime used by
wp-admin; do not assume the edited file is active. - Save the menu, reload the editor, and check every item and location.
Many shared hosts restrict php.ini changes or provide a per-account alternative. If the value does not change, revert the file and use the host-support or control-panel method instead.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Fix 4: use your cPanel PHP settings editor
Hosts expose this control under names such as PHP Settings, MultiPHP INI Editor, or a domain-specific PHP configuration page. The exact labels vary.
- Open cPanel’s PHP settings editor and select the domain or document root that contains WordPress.
- Find
max_input_vars. If it is not listed, use the editor’s field for additional directives or ask the host whether the setting is locked. - Enter
3000as a starting point, or5000if the menu is substantially larger and the host permits it. - Save the configuration.
- Verify the effective value for the website’s PHP runtime, then resave and reload the menu.
A cPanel value can be overridden by a higher-level server policy. If the panel reports one value but WordPress behaves as though another is active, request confirmation from the host.
Fix 5: try wp-config.php only when server settings are unavailable
Some guides suggest placing this line in wp-config.php before the file’s “That’s all, stop editing!” line:
@ini_set( 'max_input_vars', 5000 );This method is not universal. The host may disable ini_set(), enforce max_input_vars at a PHP configuration level that cannot be changed in application code, or apply the limit before WordPress starts. The leading @ suppresses a warning; it does not make an unsuccessful change work.
Free tools Windows power users keep installed
One-click scans. No signup required.
Back up wp-config.php before editing. Afterward, verify the runtime value rather than relying on the presence of the line. If the value is unchanged, remove the line and use a supported PHP-level method.
Verify that the fix worked
- Confirm the active
max_input_varsvalue from the host’s PHP status tools or support response. - Open Appearance → Menus and select the affected menu.
- Check that all expected items, nesting relationships, custom links, and descriptions are present before saving.
- Click Save Menu once and wait for the normal completion response.
- Reload the page. Verify the full item list again, then check Appearance → Menus → Manage Locations to ensure each location still points to the intended menu.
- If the save is still incomplete, note exactly which fields disappear and check server logs for input-variable warnings.
Do not test only by watching for a success notice. The decisive test is a fresh reload showing that every item and location assignment persisted.
If raising the limit does not solve the problem
Test for a plugin conflict
Temporarily disable plugins and save the menu again. If the problem disappears, reactivate plugins one at a time, saving after each activation, until the conflicting plugin is identified. Make the test during a maintenance window or on staging if the site is busy.
Switch to a default theme
Activate a current default WordPress theme temporarily and repeat the save. Theme code can alter menu fields or interfere with the request. If the default theme works, inspect the original theme’s menu walkers, custom fields, and JavaScript before switching back.
Check the browser for JavaScript failures
Open the browser’s developer tools and watch the Console and Network panels while clicking Save Menu. A JavaScript error, a blocked request, or a response that never reaches the server points away from max_input_vars. Resolve that error first; increasing a PHP limit cannot repair a form that is not submitted.
Separate server-limit symptoms from editor failures
If a small menu also fails, the input-variable ceiling is unlikely to be the only cause. Check the PHP value, plugin and theme tests, and the server response together. A limit problem normally appears only when the form becomes large; a universal failure suggests another configuration or code issue.
Workaround: split an oversized navigation
If your host will not raise the limit, divide the navigation into smaller menus and assign them to separate theme locations, such as a primary header menu and a footer or utility menu. Each save then contains fewer fields. This reduces the size of an individual request but does not change PHP’s limit.
Splitting is also useful when the design genuinely benefits from separate navigation groups. It is not a substitute for fixing max_input_vars when one location must contain all links, because adding more fields can recreate the failure.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Plan the split safely
- Duplicate or document the current menu structure before editing.
- Create the additional menu and move only a manageable group of items at a time.
- Save and reload after each move.
- Assign each menu to its intended location and confirm the front end on desktop and mobile layouts.
Prevent the problem from returning
- Keep a record of the effective
max_input_varsvalue and which configuration layer controls it. - After changing hosts, PHP versions, or control-panel settings, verify the value again; defaults and overrides vary by provider.
- Increase the limit only as far as the menu requires. Higher limits allow larger requests and can increase processing and memory exposure, so avoid an unbounded value.
- Use staging or a maintenance window for major menu reorganizations.
- After bulk edits, reload the menu and inspect location assignments instead of trusting the save notice alone.
- Keep a backup or export of important navigation structures before changing server configuration.
A practical decision path
- Only large menus fail: check the effective
max_input_varsvalue first. - The value is near 1,000 or another low host default: ask the host to raise it, or use a supported Apache, PHP, or cPanel setting.
- The value is already high: test plugins, then a default theme, and inspect browser errors.
- You cannot change PHP: split the navigation across menu locations as a temporary workaround.
- The site breaks after a configuration edit: restore the backup or remove the new directive, then have the host apply the setting safely.
The Bottom Line
A disappearing WordPress menu is usually a PHP input-variable problem, not a fixed WordPress item cap. Confirm the runtime value of max_input_vars, raise it through the hosting method available to you, then save and reload the menu to verify every item and location persisted.
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.
