The WordPress Menu Item Limit or: Help! Half my menu items just disappeared!

So, you just saved your WordPress 3 menu and found to your horror that you lost menu items – maybe a LOT of menu items. And now you can’t add any more – when you add a new one, the one last drops off the end of the list.

Is this a WordPress bug? Did one of those darn plugins do it?! Nope, it’s a server configuration issue that silently cuts your menu items down before WordPress even knows about them, like wolves picking off sheep in the night. Or you know, the HTTP/PHP equivalent of that.

Shake your fist at the sky and take a deep breath, and I’ll lay it out for you.

High Level Overview

Let’s start at the beginning. There are three important things to understand:

1. To save a WordPress menu, you have to send data from the client (your web browser) to the server, where it is processed and stored by the WordPress Menu System. This form data is submitted to the server via an HTTP POST. PHP parses this data as a nice array that we know and love – $_POST.

2. The WordPress Menu System bases the menu items it saves on the data it receives from the client side via the $_POST array. It assumes that data that is not present should be removed – that is, WordPress deletes menu items not present in the $_POST array upon save.

3. Depending on your server configuration, not all of the POSTed variables sent by the client may be received by the WordPress, as the $_POST array can be truncated. And when that data is lost, we lose menu items. Dang.

Hold on, I’ve had enough of the techno-babble. Skip to the Solution

Here’s how it works

Every menu item on the Appearance > Menus screen has about 11-12 fields associated with it (Title, Classes, Description, ID, etc). There are also a few meta values for the menu overall (like the menu name, menu ID, and a few nonce-related fields for security). All this data gets sent to the server as POST data. Each field is a separate POST variable. So if you have 10 menu items, you’re sending around 120 POST variables (11 per menu item + various menu meta fields). If you have 100 menu items, you’re sending around 1200 POST variables.

Here’s the problem

Unfortunately, PHP’s desire to be secure and WordPress’s desire to be tidy conspire to stab you in the back. Two wrongs might not make a right, but in this case, two rights make a big ol’ headache.

PHP’s Security

For security reasons, PHP likes to limit the maximum numbers of POST vars you can submit. This is to mitigate the effects of DoS attacks. We’ll get into details below. The important bit from the PHP manual:

If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.

This is good, but in practice, if you’re unaware of this setting (and aren’t paying attention to Warnings in the logs – and the average user isn’t), it can produce stress-induced manual hair extraction.

WordPress’s housekeeping

The WordPress Menu System save mechanism works by iterating over the $_POST array, and then discarding any menu items that weren’t present in the array.

//nav-menus.php line 341
// Remove menu items from the menu that weren't in $_POST
if ( ! empty( $menu_items ) ) {
	foreach ( array_keys( $menu_items ) as $menu_item_id ) {
		if ( is_nav_menu_item( $menu_item_id ) ) {
			wp_delete_post( $menu_item_id );
		}
	}
}

That’s good, as it prevents us from having all sorts of orphaned menu items in the posts table. But it also means that if the menu system is sent incomplete data, WordPress assumes the menu items corresponding to that data should be deleted, rather than that they should be ignored.

The Upshot: The road to confounding data loss is paved with good intentions

In the end, if the client submits more menu item variables than the PHP-configured limit, any menu items over the limit will be lost. So if you submit 1200 variables, and the limit is 1000, the last 200 are simply discarded – WordPress never even knows they were sent. These 200 variables will correspond to the last 18 items or so in your menu.

And that is why the menu items are lost. PHP prevents the menu items that you saved on the client side from reaching WordPress’s processing on the server side, so WordPress decides to delete the menu items. Who’s at fault? (I demand blood!) No one, really. It’s just a situation where you need to configure your server properly.

Sidenote: If this happens, it’s all over. We haven’t just lost pointers, we’ve lost the actual data. The only way to recover the menu items would be to restore a backup of the database prior to the menu save. Gotta catch it before it happens to avoid the repercussions.

Menu Item Specifics

Here’s how the POST variables that are submitted on menu save break down, for those who want specifics:

Key

AbbreviationExample Value
n100Number of Menu Items
c10Number of Custom Menu Items
m2Number of Registered Theme Locations

POST Variables (Example values using 100 menu items)

KeyVariable CountExample CountExplanation
menu-name11User-defined Menu Name
save_menu11Submit button
closedpostboxesnonce11nonce
meta-box-order-nonce11nonce
update-nav-menu-nonce11nonce
_wp_http_referer11nonce
action11Form meta
menu11Menu ID
menu-item-urlc10Link URL for custom menu items
menu-item-titlen100Item Title
menu-item-attr-titlen100Item Title Attribute
menu-item-classesn100Item Custom Classes
menu-item-xfnn100Item XFN Attribute (rel=)
menu-item-descriptionn100Item Description
menu-item-db-idn100Menu Item ID
menu-item-object-idn100Linked object ID
menu-item-objectn100Linked object type (post/page/custom)
menu-item-parent-idn100Item Parent ID
menu-item-positionn100Item Position
menu-item-typen100Item Type
menu-locationsm2Theme Location
Total1120

You can estimate about 12 variables per menu item to be safe. So if you want to save a menu with 150 items, you’d want a POST variable limit of no less than 150*12 + 10 = 1810.

Sidenote: the actual number varies because some menu item types have more fields than others. For example, custom menu items have an extra field to set a URL as they are not linked to a post object.

So why does this happen suddenly and without warning?

Sometimes this issue manifests as a user reaching a simple limit: they’ve added 50 menu items. They try to add the 51st, and nothing happens if they’re adding it at the end. Or if they add it in the middle, the last menu item is dropped. The limit is 50, so every time they add X more items, the last X are deleted.

Much more distressing is the case where a user has happily had 120 menu items for the last month. Then, one fateful day, they go to manage their menu, as they have new content they wish to add. Upon adding their 121st menu item and saving, they find that suddenly, to their horror, the last 40 menu items have been deleted. How could that happen? The POST vars limit should have prevented them from adding 120 menu items in the first place, right?

The most likely scenario leading to this massive frustration is that the server’s PHP version has been updated, either by the user or the web host (or possibly added Suhosin, but let’s focus on one thing at a time). And here’s why:

The PHP directive max_input_vars was introduced in PHP 5.3.9 (a relatively recent addition from January 10, 2012). The real issue is that this directive has a default value of 1000. That’s a limit of around 80 menu items. The problem comes from this sequence of events:

  1. User adds 120 menu items while host is at PHP version < 5.3.9 (no menu item limit, because max_post_vars does not exist)
  2. Host upgrades server PHP to 5.3.9+
  3. User adds 121st menu item. Only the first 80 are sent to the server due to new POST variable limit. User loses 40ish menu items
  4. User rips out hair and smashes computer against wall. Vows to quit WordPress once and for all
Sidenote: I don’t actually recommend approaching 100 menu items, even in a mega menu. The general rule of thumb is that having more than 100 links on a page can have a negative impact on SEO. Plus, presenting a user with 100 options is generally overkill, and you should probably be rethinking the navigation on your site to make it more user-friendly

How UberMenu factors in (for those who care)

UPDATE for UberMenu 3

As of UberMenu 3.0, UberMenu’s settings have been extracted from the standard menu system save process and are now saved via AJAX in a single serialized string, so UberMenu’s settings no longer contribute to this limit. The limit will be the same whether or not UberMenu is present.

UberMenu 2 (this section does not apply to UberMenu 3)

I’d like to quickly address the impact my plugin, UberMenu – WordPress Mega Menu Plugin, has on this scenario. While UberMenu does not cause this limit, it does cause the user to reach their menu item limit faster, because it adds one extra variable to each menu item.

Note that UberMenu 2 actually adds around 10 extra settings to each menu item. However, in an effort to minimize this limitation effect, UberMenu serializes all of its settings into a single active form field (via javascript), so that it only contributes one additional POST variable per menu item, rather than 10 per item. This optimization was added in UberMenu 2.0.

So here’s how it breaks down with some quick examples.

max_input_varsNormal Menu Item Limit (approx)UberMenu 2 Item Limit (approx)
10008276
2000165153
3000249230

Adding UberMenu 2 to the mix means the limit decreases by about 6 menu items per 1000 POST vars.

Unfortunately, this has the effect of customers believing UberMenu is the cause of the issue, because with UberMenu enabled they can only add 76 menu items; with UberMenu disabled, they can add 77, 78, 79… and as such it is natural to confuse symptom for cause and conclude that UberMenu is the problem. It’s not; it just makes the problem apparent sooner, unfortunately.

Server Configuration Solution

As with most problems, once you understand the issue, it’s easy to solve it. The server configuration is limiting the number of POST variables the can be submitted to the server; we need to increase that.

There are two ways this limit may be imposed

1. PHP’s max_input_vars

The increasingly common issue is the max_input_vars PHP directive. By default, it is set to 1000. To increase this, simply set it in php.ini. I’d suggest 3000 to be safe, but 2000 should be sufficient for most sites.

max_input_vars = 3000

How do you edit php.ini? That depends on your host. If you have access to the php.ini file, simply add or edit the directive, save, and restart Apache. If you’re with a web host that doesn’t give you access (common with shared hosting), you may have to contact your host and have them make the change for you.

2. Suhosin

Prior to PHP’s max_input_vars, the Suhosin PHP Security module introduced a similar pair of max_vars directives that are identical in purpose. Not all servers run Suhosin, but those that do will need to increase the following directives in php.ini:

suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000

Again, you may need to contact your host to get them to make these changes if you don’t know how or can’t do it yourself.

Restarting Apache with the new maximum POST variable values should allow you to submit all of your menu item variables and therefore save new menu items. Hoorah!

Keep in mind this won’t actually recover your lost menu items – that data is gone. The only way to get it back would be to restore from a backup copy of your database.

How to edit php.ini on various hosts:

Is there a better solution?

Wouldn’t it be nice if this wasn’t an issue? Theoretically, there may be a few options. In practice, most are more easily said than done.

Option 1: Condense all of the WordPress Menu Item fields into a single input before submitting

This is what I did with UberMenu – just serialize all the settings and decode the string on the server side. It works well, with two caveats. First, we still have the potential to reach a menu item limit eventually. Second, it means we don’t have a non-javascript fallback, and for core WordPress functionality, that’s a no-go. So that solution is probably out.

Option 2: Save menu items individually

We could save menu items via AJAX, individually, so we’d only ever submit data for one menu item at a time. Again, this requires javascript, and I suspect it would also require a major reworking of how the menu system works. It would also have to be implemented carefully in order to be intuitive and convenient; I think there would still need to be a Save-All button that would sequence all of the menu items for processing.

I don’t have enough expertise in the nitty gritty of the menu system to say whether this is truly a viable/practical option.

Option 3: Use a “checksum” to protect from unintended deletions

I’m using the term loosely here, but we could submit an extra form field that acts as a “checksum“, indicating how many menu items are being sent to the server for processing. WordPress’s menu save process could then check this value to make sure the number of menu items that it has received in the $_POST array is equivalent to the number of items it expects to receive. If it finds a discrepancy, it could avoid deleting missing menu items; however, it may be too late to save newly submitted menu items that were previously unknown.

Option 4: Native Nested Menus

Another thought would be to provide a native nesting/import functionality in WordPress. Essentially, each menu item would have an option to nest a separate menu as its submenu. This would allow users to divide up their menu items among multiple menu trees, to be dynamically assembled when the menu is printed. There are some existing plugin solutions out there that already do this, I believe. This would also enhance the reusability of the menu system, as users could potentially use the same menu subtree fragments in multiple menus.

Note that UberMenu 3 has a feature called “Menu Segments” that allows you to do this

Option 5: Provide a Warning

I think this is really the best option, at least in the short term. Simply detect the potential issue and alert the user to it. Providing explanations and solutions (or links to solutions) within the interface is generally the most efficient way to inform a user of what they need to be aware of and resolve.

And that brings us to…

The Menu Item Limit Detector Plugin

As a first step toward this, I’ve written a rudimentary plugin that attempts to detect impending menu item limits by roughly (and conservatively) estimating the remaining POST variables based on the prior save and the current variable limits. It adds an alert in the Appearance > Menus screen when the user approaches the limit, and explains the issue.

Menu Item Limit Warning

Note that I’ve already included a very similar piece of code within my UberMenu plugin to detect this scenario for UberMenu customers. Available in UberMenu 2.3+

The obvious downside to the plugin is that users need to be aware of the issue in order to install it in the first place… and the whole point of the plugin is to provide that awareness. Chicken and egg much? This’d be far more useful in WordPress Core.

Download the Plugin Contribute on Github

Please try out the plugin and let me know if it helps! If it’s useful, I’ll add it to the WordPress plugin repository.

And let me know if you have any creative suggestions for solving this problem! I highly doubt the options I’ve presented are comprehensive, but I hope they start the conversation going in the right direction.

71 thoughts on “The WordPress Menu Item Limit or: Help! Half my menu items just disappeared!

  1. I am using Ubermenu plugin.

    I can add only 80 menu items.
    I want to add mre that 110 menu items.

    Please help us for this problem.

  2. I have increase the values of below variables
    max_input_vars = 5000
    suhosin.post.max_vars = 5000
    suhosin.request.max_vars = 5000

    but still i can not add too many menus

    i am using 5.3.23. is it possible to add menus without changing my php version ??

    • Did you restart apache and check phpinfo() to ensure that your settings have been changed?

      • Yes i have check the phpinfo().this show the exact values
        max_input_vars = 5000
        suhosin.post.max_vars = 5000
        suhosin.request.max_vars = 5000
        but i am still unable to add the menus ๐Ÿ™

          • Hi,

            We increased max_input_vars 2000. I checked in phpinfo.php file but still i am not able to add more than 90.

            And i checked the Post data in Firebug. It has total of 1049 indexes.
            Still the new menu items are not adding.

            Thanks,
            Bhargav

  3. Hi Chris,

    I just wanted to complement you on an excellently written and informative article.

    If everyone took the time to be as detailed in their information posts, the web would be a much better place.

    Thank you,

    Carl.

  4. Been having this menu issue for some time. and this has been the clearest explanation of this problem I have read to date.

    The plugin works great too!

    I tried to implement your fix to resolve the issue currently by adding …

    max_input_vars = 3000

    It registers in the phpinfo() but not in your plugin readout presumably because the server needs to be rebooted. On the shared hosting I’m on I have access to php.ini but don’t think I’m able to reboot the server (can I?) so would I have to wait for the host to reboot the server for these changes to take effect?

    suhosin isn’t appearing in phpinfo() so I’m assuming it isn’t installed on the server

    • Hey Mike,

      Glad to hear you found it useful!

      It may be that you need to restart the server, or it may be that you have multiple PHP config files – if you take a look at the phpinfo() readout, it should show exactly where the configuration settings are loaded from. You can check each of those files.

      On shared hosting, you’re unlikely to have access to restart apache, so you’d generally have to ask your host to do that for you (though you may have an option in your server admin panel).

      Hope that helps!

      Chris

  5. Hi Chris,
    Thanks for your article, helpt a lot.
    My hoster solves the problem by increasing the limit.

    But, to prevent unwanted surprises, I’ve downloaded your plugin to one of my other websites, but it does not appear in the menu page either in the options of that particular page. I’m using wordpress version 3.5.2
    Any idea?

    • Hi Ruud,

      Glad it was helpful!

      The plugin is designed to only display when you approach the menu item limit. If you’re not in danger of going over the limit, the plugin won’t display anything. This way it is unobtrusive.

      Hope that helps!

      Chris

  6. Hi Chris, great article!
    Bizarre that wordpress have not released any way of fixing this issue, or at least provides a warning!

    Anyway, I have installed your plugin (while I wait for my server admin people to increase the limit), however I noticed when I add a menu item, there is still no warning. Perhaps I have a completely seperate issue?

    • Hi Simon,

      Yeah, I saw in one f the WordPress trac tickets that they are looking into solutions, and may be revamping the entire menu system (I think using backbone.js perhaps?) to avoid the issue. But a complete overhaul takes time so I wouldn’t expect that for several versions.

      The way the plugin works is that it’ll give you an alert when you’re getting close to reaching the limit (it’ll compare your PHP limit to the number of menu items you have upon save). So you’ll only get a message if you’re closing in on the limit. Perhaps you’re not close enough, or the server admin already increased the max post vars? It’s possible it’s a separate issue – easiest way to tell is to look at that post vars number and compare it to the number of menu items you have.

      Hope that helps! ๐Ÿ™‚

      Chris

  7. Do your other menu plugins include the alert feature as well? (Menu Management Enhancer)

    • Hi Eric,

      Only UberMenu includes this functionality built-in. If you’re using the Menu Management Enhancer, you’ll want to add the stand-alone plugin available above ๐Ÿ™‚

      Best,

      Chris

  8. Do I understand you correctly that you have (at least temporarily) solved this problem with the Ubermenu plugin? That is, when I install and activate Ubermenu, will it stave off the menu limit problem?

    Is there any special setting I need to accomplish within Ubermenu to enable the way the menus are saved. It seems like you’ve stated above the Ubermenu implements Option 1 so if I was having the problem previously, is it likely to resolve this issue?

    • Hi Rich,

      No, UberMenu won’t solve the issue on its own. If you have this issue with your server configuration, it will still occur with UberMenu. What UberMenu does is compresses the UberMenu-specific fields into a single variable, in order to minimize the amount of extra POST vars sent to the server; it does not however reduce the amount sent by the standard WordPress menu item fields (messing with standard WordPress functionality via a plugin would be asking for trouble).

      The solution for WordPress users at this point is to setup the PHP configuration file properly, as described above.

      Hope that helps!

      Chris

  9. I am strucked as my menu items including submenus is strucked at 84.i want to take this to 130.how can do it??
    I did following-
    adding this to my php.ini file and restarting my server.

    max_input_vars = 5000
    didint work
    set the follow line in “.htaccess” on the server
    php_value max_input_vars 5000
    didnt work
    any help pl

    • You should check your phpinfo() output to see if the values are actually set or if they are being overridden in another config file. Also, your host may be able to help you configure things properly.

      Hope that helps!

      Chris

  10. I am using host with PHP Version 5.3.23, Build Date Mar 22 2013 14:03:13, where I canยดt declare max_input_vars but my last menu items missing after adding some new items anywhere in menu. Is there a other variables, which can affect this in older versions of php as 5.3.9 ?

    in phpinfo () I was found this declaration:
    max_input_vars 1000 1000

    and I donยดt understand why this have affect when older version of php doesnยดt recognize this

    • Could be Suhosin then – that has been in place for a long time and isn’t related to the PHP version.

      It’s also possible that the max_input_vars directive was already available in earlier version, but 5.3.9 just created the default 1000, whereas prior to that the default was infinite. If the value is set to 1000, try increasing it.

      It’s also possible you have two versions of PHP installed and the one you’re inspecting is different than the one apache is using.

      Good luck and have a great weekend!

      Chris

  11. Thanks for the extremely well written article.

    Unfortunately, none of these “fixes” have worked for a particular site I’m developing. Anyone else in my boat? Really, REALLY frustrating.

    • Any chance you didn’t restart apache? And print out phpinfo() to double check that your settings have updated and that you’re changing them in the right config file.

      Good luck! ๐Ÿ™‚

  12. Pingback: Help! ik kan geen menu-items meer toevoegen!

  13. (NSFW)
    Hi Chris,
    Good morning.

    This article is very informative.

    Under thirteen headings on the nav menu bar on homepage I have average seven menus per heading.

    All menus and posts are intact on the homepage. However, on the ‘Appearance’ under ‘Menu’ section of the admin panel I don’t see any posts listed at all. (That means I cannot add any post as a menu item.)

    The PHP version of my shared Linux hosting server is 5.3.25 and not 5.3.9. So, is my issue due to the max_input_vars default that you have discussed in this article or something else?

    I re-installed with FTP WP 3.6 believing I might have lost some files. I deactivated all plugins and shifted to twentythirteen theme. The issue persists.

    I am sure you will be able to throw some light on this. Thanks for the article.

    Best wishes,
    Dr. Ashok Koparday

    • Hi Ashok,

      Could be the Suhosin issue rather than the max_post_vars if that is your PHP version. Though, based on your description is sounds like you may have some other sort of error – I’ve never seen this issue manifest as “no posts listed at all” in Appearance > Menus. You might want to enable debugging to see if you’re encountering any PHP errors in your admin panel.

      Best of luck!

      Chris

  14. Thank you Chris!

    I was struggling to find out why a menu had partially dissappeared from a rather large website and tried a few things that didn’t work before I came across your post.

    Your post explained the problem clearly (in my case, a PHP upgrade on the server must have triggered it) and gave a solution that instantly worked.

    Many thanks! I really appreciate the time you took to write it all up.

    Ian

  15. Have you had any issues dealing with sub menus. I am creating a huge menu, with a bunch of submenus, and I have hit a point where I cant move the submenus under there menu item. When I save, they go back out to the top level menu. ? I have already raised my vars to 5000 successfully

    • Hi John,

      That’s pretty weird. I haven’t ever heard of that before, and I don’t think this menu item limit would be likely to manifest in that way (I suppose it’s possible if ONLY the parent data was lost, but it seems really unlikely).

      Any chance it’s just a javascript issue? I found things really slowed down in WordPress 3.6 with a lot of menu items. If you’re using WordPress 3.6, it’s possible that this might help.

      Best,

      Chris

  16. Works like a charm (on localhost), now all i have to do is get my host to change the value for me… downside of being on a shared host ๐Ÿ™

    Thanx for taking the time to write this.

  17. Thank you for this very thorough solution to a vexing problem. I used your article to talk my web host liquidweb through changing the server settings on a web site that had hit this menu limit. Your article allowed me to become a tech support expert and teach their tech support how to fix the problem! Ironic, but hey, it solved the problem and I’m grateful.

    • Hi Lee,

      You’re welcome! Yeah, this issue is a bit complex and I’ve seen a lot of hosts’ techs fail to understand and therefore refuse to deal with it. Glad to hear they were able to make the changes for you in the end! ๐Ÿ™‚

      Best,

      Chris

  18. Chris! I would like to thank you from deep within my heart man! Indeed lot of so called experts / techs miss out on this thing and thankgod you made that plugin and wrote such a elaborate article. I really thank you man!

    Web is such a good place becuz of people like you!
    God bless you!

  19. I guess I’m among the unfortunates whose situation is worse.

    None of the PHP tweaks worked despite restarting the server several times. No other php.ini is in existence in the space of the hosting.

    My only refuge is this nested menu plugin you’re talking about. Can you point me to the right direction?

    • Sorry, O_H, the nested menu idea is just a theoretical solution, not an existing plugin. I’d recommend installing the Limit Detector plugin and outputting your phpinfo() to see what the actual configured value is an whether that is truly your issue, so you know which avenue to pursue.

      Good luck! ๐Ÿ™‚

      Chris

  20. Hi Chris,

    I’m working on a site that has this problem. To top it off, the host won’t honor the request of increasing the max_input_vars directive. He says that doing so could compromise security. Does this mean I have to ditch the plugin or find another host? Do I have any chance of convincing him to approve the request?

    Looking forward to your answer. Thanks!

    • Hi Anthony,

      I have never heard of max_input_vars being a security risk. The reason it exists is to minimize the effect of DoS attacks – while that is a nice thing to have, DoS attacks don’t represent a security risk to my knowledge, just server overload downtime problems.

      I would ask them exactly how it creates a security risk – perhaps they can point you to articles on the subject (I’d be interested if this is the case). It’s certainly possible there is something I’m not aware of… but it’s also possible they’re giving you the “oh it’s a security risk” line, banking on you taking them at their word to avoid making a change they don’t truly understand the ramifications of. Some support techs know their stuff; but there are also support techs who are clueless and try to give you the runaround to hide it.

      I’m not sure who your host is, but if they are reputable, I would try respectfully explaining to them that by imposing this limit on the max_input_vars they are limiting the number of menu items their customers who use WordPress can create. I suspect WordPress makes up a significant percentage of their userbase, so hopefully someone at the company will recognize it as something worthy of their attention.

      You may also be able to convince them to raise the limit temporarily so that you can add your items, then lower it again when you’re done. Just keep in mind that if you ever try to save your menu again without first increasing that limit, you will lose all menu items over the limit.

      As for your options – you mentioned “ditching the plugin” – this isn’t a plugin issue, as explained in the article, so removing plugins isn’t going to help (it may buy you a few extra menu items, but you’ll run into the limit shortly regardless).

      If they refuse to change it and you need more menu items, it sounds like switching hosts may be your only option.

      Hope that helps! Best of luck,

      Chris

      • Thank you! I’ll try your suggestions and hopefully we can work something out. I’ll keep you posted once I get more info from the host.

  21. Hi Chris,

    I’m building a site with 60+ menu items and am experiencing errors while the plugin is activated.

    When trying to save/edit the menu, I get the 404 page:
    <>/wp-admin/nav-menus.php

    When I disable the plugin, I can get in and continue loading more items.

    I thought the problem might be related to this max_input_vars and thus set it to 5000 in my php.ini

    I’m building the site in a sandbox on a WordPress MU. Wondering whether this might be causing conflicts?

    Do you have any ideas as to what might be causing this 404 error problem?

    Have no other plugins activated and have tried with the twenty thirteen theme with no luck either.

    Cheers
    Adrian

    • Hi Adrian,

      I’m not sure which plugin you’re referring to, as this article isn’t about a specific plugin. If you are getting a 404, I would recommend enabling debugging on your site and checking the debug log for errors. Note that a 404 is not a symptom that I have ever encountered due to the issue discussed in this article.

      I’m currently on vacation, but if you have a question about one of my premium plugins, feel free to post in the Support Forum and my support team will assist.

      Have a good one,

      Chris

  22. Hello,

    Thanks for the useful info. I am also having this problem & I’m on shared hosting. I have created a php.ini on my site root & set variable to 3000. When I test it with phpinfo, I can see that site is using this php.ini & variable is set to 3000.

    But when I save my menu, your plugin gives the warning message that variable is set to 2000 & half of my menu is gone again.

    I also added suhosin variables, but I think it is not installed, I don’t see suhosin at phpinfo.

    I’d really appreciate any ideas. Thanks

    • Hi gezginrocker,

      It’s unclear which plugin you’re referring to, but when my plugins print the warning message, they pull the value reported from PHP using ini_get(), whereas phpinfo() may only report the value from the initialization files. So for example, your max_input_vars value might be changed in the code or in the .htaccess, etc. It’s also possible to have two versions of PHP running on a server with different ini files, or multiple ini files for the same PHP instance.

      Currently on vacation, so can’t really dig in any deeper than that at the moment. Best of luck!

      Chris

  23. Hi Chris,

    First of all thanks for your reply. Finally I solved the problem. This time I used “PHP Variables Manager” at cPanel. After adding the variables to my site folder, I checked “Apply changes to all sub-directories”. And that did the trick! Now I can add more items to my menu without a problem.

    Thanks a lot again for all the info and have a nice holiday! ๐Ÿ™‚

  24. Nice article, Chris, but unfortunately the fix doesn’t work for me. I verified that the change to max_input_vars showed up in phpinfo (I increased the value to 5000), but I still can’t have more than 84 menu items. I also checked and found that suhosin is not installed. Any other ideas?

    • I’d suggest checking other locations where the directive may be altered, perhaps in a .htaccess file.

      • What’s really weird is that I tried your plugin, but it doesn’t report having hit any limits. The Appearance > Menu section just looks normal.

        The .htaccess file for the WP site doesn’t have anything like that in it.

      • In fact, to try to force the plugin to trip, I tried setting Max_input_vars to 500, but I still didn’t get any message in Appearance > Menus!

      • I’m wondering if my issue really is the same as the one you’re addressing. In your article, you wrote that the last item in the list drops off. The symptom I experience is that not only does the last item drop off, but also the entire menu structure gets decoupled from its assignment as the primary navigation menu for my theme. I have to go to Appearance > Menus > Manage Locations to reassign the menu back to being the primary navigation menu, which causes the menu to reappear (minus the item I tried to add). Is this consistent with what you’ve seen?

        • I suppose that could happen as well, since in WordPress 3.6 the assignment was added at the end of the menu items, so I suspect those form elements are also dropped. It’s not something I have experienced, but it makes sense.

  25. hello,
    I was searching for same problem on wamp server . I have found the solution.I have change the max_input_nesting_level = 64 to 80. It work out for me.

  26. Hey, great article, very informative. Unfortunately I asked my host about this and they said that as I’m on shared hosting it will adversely affect others BUT I can “modify your htaccess file to to use a unique php.ini file and specify the exact variables you need”.
    I don’t suppose you would know how to do this? It might help your readers who are in the same position. I’m assuming there is a line of code to put in the htaccess file and then the php.ini file contains only the modification (according to WP forums, that’s as far as I have got!). Thanks in advance!

    • I believe it’d be something like

      php_value max_input_vars 3000

      But I’m not sure as I haven’t tried it that way. If the host is making that recommendation, I would expect they can provide you with the proper code. Though I’m not sure the idea that this would “adversely affect others” actually makes any sense.

  27. Pingback: WordPress: Benutzerdefinierte Menรผs werden beim Speichern zerstรถrt – Die Lรถsung! | Huwis Achterbahn

Comments are closed.