Menus item are limited to 16 item and will not save more than that

[jaanfx]

I've installed a fresh copy of the WP 3.0 about 4 days ago. Using default twentyten theme. I modified the menus from the admin panel with new pages and some custom links and hierchy... now everytime I modify the menu and click "Save Menu" it only saves the first 16 items listed on the menus.

The problem is.. I have about 8 main menu with some of them have about 5 or 6 items below it, it cuts off at the 16th item and does not save anything beyond that.

I deleted the first item and added two more at the end, same thing, it only saves the first 16 items on the menus.

I been sturggling on my own to figure this out, did search here and google yet to find a solution..

I am shocked no one else is having this problem. I tried in IE7, IE8, Firefox, Chrome, Safari and Opera - I have the same problem no matter which browser I use.

in function.php I am using

register_nav_menus( array(
		'primary' => __( 'Primary Navigation', 'MainNav' ),
	) );//-------------------

and the page I want the nav on has thise code:

wp_nav_menu( array( 'container_class' => 'menu-header', 'theme_location' => 'primary' ) );

Any help is appriciated...

I'm guessing you have Suhosin or the like installed on your server and it's limiting the number of posted variables. You might need to increase the suhosin.post.max_vars and suhosin.request.max_vars settings.

You can confirm this error by checking your server's error logs, where you might see something like "ALERT - configured POST variable limit exceeded."

Thanks for the reply. I've looked into the error report, unfortunately there was no error log at all. Normally my server keeps record of any errors including 404's.

I've just contacted the server company to make the changes for me, i'll confirm once they increase the limit. I asked them to make max_vars to 300.

That solves the problem, great, thank you so much.

Reopening for consideration. Could we re-tool how the POST data is structured on the menus page to possibly get under the max_vars, max_array_depth and max_array_index_length defaults, for a reasonable number of menu items?

Replying to nacin:

Reopening for consideration. Could we re-tool how the POST data is structured on the menus page to possibly get under the max_vars, max_array_depth and max_array_index_length defaults, for a reasonable number of menu items?

In my experience it is max_vars, which at 200 by default limits you to fewer than 20 menu items.

We could boost to about 50 the number of menu items allowed by default Suhosin were we to save each menu item's properties separately and therefore limit the overall requested variables to a few necessary properties: item id, order, and depth.

So the questions seem to be:

• Is the current harm worth reworking the system? I'm ambivalent. It might be good for other reasons, such as reducing network latency and unnecessary CPU and DB work. But it doesn't seem like there's been too much complaining so far.
• Does Jane or someone else with say-so in the UI department sign off on the idea of saving individual menu items separately from each other and from the item order/depth?

I think that the menus should be saved just like the widgets screen: through Ajax, without the need for the Save button and the page refresh. One by one.

When I drag a widget on a sidebar it gets saved automatically. If I make changes to the widget itself I just click on the Save button inside the widget and it gets saved without refresh.

I really don't understand why the menu management screen doesn't already inherit all the good stuff that's available on the widgets screen.

I really think that's an inconsistent behavior on the WordPress UX.

That's the same thing on the Themes page: it has a tab with the link to add new themes but it doesn't behave like a tab, all the other screens have a button like "Add new" on the plugins screen.

Hi Team

I can give you a live example similar to the original error above, that happened to me today. At least, I think this is similar, and it may help you. It might qualify as 2nd opinion of symptoms (sorry it's a bit verbose).

The blog in question is at gazlannathai.com/eye and since way back around WP 2.5-ish has used the current Wynton Magazine theme from Michael Oesser in Germany. Unfortunately Michael has finally decided to go full cost Premium with his themes after upgrading them for WP 3.0, thus I decided to have a hack at it myself, having already heavily modified Wynton over the years for the "Eye".

First thing I tried was a straight "convert to child theme of twentyten" in the style.css to see what that got me - it sort of worked but the typography went all crazy and the normal horizontal nav menus in the header became a vertical list-out

Within 2 to 3 minutes of messing around in the CSS to reset font sizes (and that's all I was touching at that point) I hit a server 500 error, then moments later had the account suspended for query flooding. Part of the error log is here -

[Sat Sep 18 05:39:02 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:03 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:03 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:03 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:04 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:04 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:05 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:05 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:05 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:06 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:06 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:06 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:07 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request
[Sat Sep 18 05:39:07 2010] [notice] mod_fcgid: too much /var/www/vhosts/gazlannathai.com/httpdocs/eye/index.php process(current:8, max:8), skip the spawn request

That went on for hundreds of lines in the space of just a couple of minutes.

Luckily I have a good relationship with the techs at this host, ticketed them I was live-developing and knew exactly where the error triggered from. They unsuspended me and I knocked out the child theme lines in css = end of problem immediately.

During the brief period it was active and "sorta" working, I did notice the header menu list was heavily truncated, compared to the full categories list - I didn't count it, but I think it was probably around 20-25 categories showing from the 6-7 pages of categories in admin (however many cats that is).

--
Now here's the thing - On another site (longrangelogistics.com) I have another of Michaels themes (Branford Magazine - also tweaked and customised, a little) that uses the same header-nav horizontal menus scripts, and it has a hundred or so multi-tiered child categories under a narrow top level of 8 or 10. With both the Branford and the Wynton themes, I've never had issues coming from those nav scripts like the issue at the top of this ticket.

The themes (pre WP 3.0 versions) are GPL. If you want copies for evaluation of how he did the nav menus, let me know.
In my book they run perfect, but I'm now sweating at the thought of upgrading those themes the long & hard way to WP 3.0 full compatibility.

Hope it helps with something
Gaz

I have the menu truncated at 16 items too, same problem of the first reporter.
16 items is a very limiting number if you have some nested one you reach the limit very quickly.
If it's decided to not fix this issue (as I understand that it's not strictly a WP issue) we shold at least document this problem in the wiki and maybe in the admin screen too: it took me nearly an hour to isolate it.

Stefano

Luckily I found this page from a link in the top 3 pages of google search "wordpress menu limit", so I quickly found a solution. I wrote a letter to my ISP to set the limit to 5000 and now it's solved. I just asked them to set the following two values in PHP.

suhosin.post.max_vars = 5000
suhosin.request.max_vars = 5000

But I think Wordpress with it's millions of downloads should really think about a different structure for the menu data, as I think not all users go as far as this and really look after the problem. And something as popular as Wordpress really shouldn't work in a "ask you ISP to set these values for you" way'''

Having not looked at how the data is sent at all, I don't know if this is feasible... but why not just store the list of menus in an array, json it, then send it to the server as one post variable? WordPress 3.0 has json_decode, it can pull that trick, get a PHP array, then save the thing as needed.

Replying to Otto42:

Having not looked at how the data is sent at all, I don't know if this is feasible... but why not just store the list of menus in an array, json it, then send it to the server as one post variable? WordPress 3.0 has json_decode, it can pull that trick, get a PHP array, then save the thing as needed.

There are a number of issues with that approach, the first of which is that it requires JavaScript to work; if you're going to require JavaScript you may as well save each menu item ajaxily and seriatim, sidestepping the issue altogether.

Replying to filosofo:

Replying to Otto42:

Having not looked at how the data is sent at all, I don't know if this is feasible... but why not just store the list of menus in an array, json it, then send it to the server as one post variable? WordPress 3.0 has json_decode, it can pull that trick, get a PHP array, then save the thing as needed.

There are a number of issues with that approach, the first of which is that it requires JavaScript to work; if you're going to require JavaScript you may as well save each menu item ajaxily and seriatim, sidestepping the issue altogether.

I don't know how these things work, but doesn't the widget page work in a similar way? (I mean auto saving) As far as I understand that's AJAX, so that requires JS already. I think an AJAX based approach would be perfect, given I think that the population who uses NoScript or something similar would be mostly the site-admins itself, so you can just _ask_ the user to enable JS on WP admin page.

How about instead of saving the whole menu, we only let user update each menu item instead (just like saving widget)? Everything is ajaxified when JS is enabled, otherwise it still works fine as POST data is smaller.

Attached are two quick mock-ups, in which I deleted the bottom "Save Menu" button (since saving menu configuration is separated from saving menu items, there's no need to repeat the button at the bottom of the form). There's also a "Save Item" button for each menu item.

I don't think the approach of saving each menu item individually really addresses the problem for those users who are experiencing this issue. Most of the time they will just add all the menu items and click save; they won't bother to expand and save each menu item individually, especially if they have more than 15 menu items.

And truly forcing users to update menu items only individually is much too annoying; it certainly isn't warranted by the very tiny number of people running into this issue.

When the user add a bunch of items, if JS is enabled, the menu is saved automatically by sending an ajax request, without requiring the user to go to each item and click Save.

Your point about having to update individually is annoying is valid, though. Perhaps only enable this method when the menu items exceed 15? But of course that would be a twisty situation.

Replying to garyc40:

When the user add a bunch of items, if JS is enabled, the menu is saved automatically by sending an ajax request, without requiring the user to go to each item and click Save.

But the problem is that was explicitly unwanted for menu items; we want there to be a draft state in which the user can manipulate the menus without their showing up on the front end, unlike widgets which appear inchoate.

Well, seems like there's no perfect solution for these edge cases. Perhaps we should just document this somewhere, in case some other suhosin users are clueless abt this. wontfix?

Ajaxifying the menu UI should be put in a separate ticket, if sb's still interested in that.

I'd be okay with some sort of JS-enabled enhancement. Saving every form field on every menu item is really inefficient. filosofo is probably in the best place to think of an alternate method.

Ran square into this one last night at a WP meetup. Problem setup stopped working at 12 menu items, due to the server's configuration.

Let's make this a priority for 3.2. One proposed solution was to use JS to only send changed items, and then the item ordering.

Related: #16799

@vteixeira: re not having the same behavior as widgets, it was an intentional decision so we could compare the workflows, as there have been issues with widgets since we made them auto-publish.... people don't like it that the sidebars/widgets publish before they've had time to configure to them to their liking, and an explicit save was introduced in the menus ui (despite most other thigns being similar) to see if it would solve this problem. It is more likely that we'll eventually add an explicit save/publish to widgets rather than removing it from menus.

@garyc40: It is a UI standard to have save buttons at top and bottom for things like this. If the list of menus is very long, the user shouldn't have to scroll back up to save.

I'll work on making a patch for 3.2.

Replying to filosofo:

I'll work on making a patch for 3.2.

Moving to 3.2 based on that. Hopefully this makes freeze.

Just wanted to mention.

​http://wordpress.org/support/topic/using-get-when-you-need-to-post

That post indicates an issue I had. It was suggested I share it here.

In my experience using GET for big data transfers can be problematic.

Replying to magblogapi:

Just wanted to mention.

​http://wordpress.org/support/topic/using-get-when-you-need-to-post

That post indicates an issue I had. It was suggested I share it here.

In my experience using GET for big data transfers can be problematic.

Why do you think that applies here? Menu values are posted currently.

It was suggested by the chap I was discussing the issue with.

I don't spend a whole lot of time in here, so I was assuming I was doing a favor. I apologize if that was not the case, and feel free to delete my post.

Replying to magblogapi:

so I was assuming I was doing a favor. I apologize if that was not the case, and feel free to delete my post.

Bug reports are welcome. I was just trying to figure out if there was something I was misunderstanding.

No patch since filosofo's comment 6 weeks ago. Past freeze, punting.

I have a WordPress menu with 90 nodes (and will ultimately need maybe 150).
Saving any menu takes a while, but saving this menu now fails after about 40 seconds. I get a blank screen and the following PHP error message:

May 28 21:45:38 <hostname> apache2: PHP Fatal error:  Maximum execution time of 30 seconds exceeded in <path>/wp-includes/wp-db.php on line 1005

It was indeed due to the PHP execution timeout.

Solving this is IMO urgent because:

1. it sometimes occurs for very modest-sized menus
2. many self-hosted users are not in a position to analyze this far
3. I suspect these timeout may leave orphaned records in the database:

SELECT `ID` , `post_date` , `post_modified` , `post_parent` , `post_content` , `post_name` , `post_status` , `menu_order`
FROM `test1_posts`
WHERE `post_type` = 'nav_menu_item' AND `post_status` = 'draft'
ORDER BY `test1_posts`.`post_parent` DESC

shows a few orphaned records in my database that were created during the timeouts and that have ‘menu_order’=1. I can't manually analyze the entire menu structure for 'post_status'='publish' because the menus are large and I happen to have multiple menus (argggh) for multiple languages (running the WPML plugin).

I incidentally understand that solving this is non-trivial.

I want to second vdhamer and others' urgings to escalate this in priority. I've wasted hours doggedly trying to update a menu structure and watching it crash 9 times out of 10. My menu now has 43 items and I'll need about 70 before I'm done with the site, and it just isn't possible in WP, the way it stands. And in the process I've had major parts of the menu get wiped out and have to be rebuilt, so that the table is probably full of garbage now. Please, if WP is going to be useful for more complex sites, do something! Thank you!

FYI - this came up again here: ​http://wordpress.org/support/topic/rc32-menus-still-crippled

Have we lost traction?

How about splitting the requests another way:

• one for the menu item hierarchy (the order of the items and the nesting)
• one for each menu item's details

When JavaScript is not enabled, clicking on the expand link on a menu item will cause a page refresh with just that menu item expanded.

With JavaScript, there can just be several AJAX requests when the user clicks Save.

In both cases however, we will probably need to introduce some mechanism of displaying the old version of the menu.

This could be done by creating a new, working-copy menu, which would replace the old one when the user is done editing.

Let's figure it out.

This ticket sat for 3 months with no new patch. Punting due to freeze. If it's going to happen in 3.4 it needs to be assigned to someone.

My menu starts getting unreliable ('save menu' starts hanging) at around 45 menu items. At about 50, menu never saves. No suhosin on server - Troubleshooting for days directly with the web server administrator hasn't helped. No errors logged anywhere. I'm nearly out of options - Please optimize the menu system in 3.3 or 3.4!

This should already be improved in 3.3 thanks to #16799.

I am also encountering this problem as I convert a large Joomla real estate site to WP. The main top menu is a total of 50+ items, and one other sidebar menu could be as many as 80 items. The 3.3 improvement (#16799) should help a lot, but for the longer term, I like scribu's earlier suggestion:

"This could be done by creating a new, working-copy menu, which would replace the old one when the user is done editing. "

This approach would/should be more consistent with how page/post drafts work. The working menu would be in "Draft" status until "Published".

In conjunction with this paradigm, it should also be possible for a user with Administrator role, when adding a custom menu widget, to see active draft custom menus in the list of available menus, and to select an active draft menu for that widget. This would allow them to review the actual draft menu in action on the site, and on whatever pages/posts and widget positions it would be displayed on. If an active widget contains a draft menu, it would be displayed only if a user in Admin role is logged in. This would allow other admins to review the new draft menu as well, without impacting a normal user's view of the production site.

I was truly hoping that this issue would be resolved in 3.3. I have a site with a large number of menus and a lot of items per menu. The client is no longer able to edit their menus.

The host server is not using suhosin - so this is not the source of the issue.

Please do not change the version of the ticket. The version should be the version at which the problem was reported.

Sorry - didn't know that rule. Not very helpful in terms of solving the issue - which is major for us.

The site has a lot of menu items, and nothing can be done now to add to, delete or change them.

I have expanded the time allowed for scripts to load to a ridiculously high number in php.ini - to no avail.

Is there some fix that someone can help us with?

I too am developing a site that consist of 200 categories, and the customer wants all 200 in a menu. It is a Real Estate site and has a category for all cities they serve, and for each city they have real estate, vacation rentals, annual rentals, and land for sale.

Tonight, I am hitting this issue, and can not even delete menu items or add.

As stated by Otto above:
Please do not change the version of the ticket. The version should be the version at which the problem was reported.

Oops sorry, thought that I was assigning which Wordpress Version I am using. This ticket and the current Wordpress version are closely related.

Upgraded to 3.3.1 and still having timeout issues. I have WP Multisite with about 33 subfolder sites installed. We started having the problem shortly after install in September 2011 on WP 3.2.1. Each site has a menu structure. Most sites have about 10 menu items, but some have more (one site has approx 30). Shortly after install, on the large menu site, they could no longer edit their menu, so I created 5 separate menus and stacked them in the sidebar using widgets. Fast forward a couple of months and we can't edit any menu item. Everything times out after exactly 3 minutes. Error message is as follows:

[Wed Jan 25 18:26:54 2012] [error] [client 66.249.67.239] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

The only thing that varies is the client IP address - there seems to be 3-4 different ones that pop over over the course of 60+ pages of error logs.

Now, we are also getting timeouts when we try to create a post. The post will timeout (after 3 minutes) and it appears to fail. But when you go back and view the list of posts, it's there.

Hosted on GoDaddy (please don't throw rocks...)

Here is copy of .htaccess pretty vanilla WP MS install version

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule  ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]
RewriteRule  ^[_0-9a-zA-Z-]+/(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
# END WordPress

And here is a copy of PHP.ini which I modified to add time and memory per different online posts about solving this problem.

register_globals = off
allow_url_fopen = off

expose_php = Off
max_execution_time = 600
max_input_time = 600
memory = 20MB
memory_limit = 256M
variables_order = "EGPCS"
extension_dir = ./
upload_tmp_dir = /tmp
precision = 12
SMTP = relay-hosting.secureserver.net
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="


; Only uncomment zend optimizer lines if your application requires Zend Optimizer support

;[Zend]
;zend_optimizer.optimization_level=15
;zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3
;zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3
;zend_extension=/usr/local/Zend/lib/Optimizer-3.3.3/ZendExtensionManager.so
;zend_extension_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3/ZendExtensionManager_TS.so


; -- Be very careful to not to disable a function which might be needed!
; -- Uncomment the following lines to increase the security of your PHP site.

;disable_functions = "highlight_file,ini_alter,ini_restore,openlog,passthru,
;		      phpinfo, exec, system, dl, fsockopen, set_time_limit,
;                     popen, proc_open, proc_nice,shell_exec,show_source,symlink"

I don't consider my site anything that exotic - and even the one long menu isn't completely outrageous. Where is WP with a fix on this? Any thoughts?

Here is the work-around that is working great for me and my large (450+ pages and growing) real estate site and menus:

• Installed Alex Mills "Add Descendants As Submenu Items" plugin. This plugin minimizes WP custom menu item counts significantly when the pages / posts are well organized by assigning assigned appropriate parent/child relationships and putting child pages in the same order as you want them to show in the menus.
• Installed "CMS Tree Page View" plugin to better show and organize (drag/drop) complex parent/child page relationships, especially on larger sites like mine with 450+ static pages.
• Installed "Widget Logic" plugin to be able to manage which pages have sidebar sub-menu widgets.
• In my theme's functions.php, installed a special function I found somewhere: is_child_of('postid').
• Built smaller sub-menus (~20) for sidebars, for key pages that have lots of additional child/grandchild pages, and then used Widget Logic and the is_child_of function to have those menu widgets appear only on the appropriate parent and sub-pages, not in the top menu.

FYI for the other large RE site webmaster who posted to in this thread: IMO, putting absolutely everything in the top menu makes the top menu too large to effectively manage, increases page load time, and may be a major SEO problem because of so many links. My top menu only has about 60 links, and with the sidebar sub-menus controlled by Widget Logic, no page ever has more than about 120 on-page internal links.

We ran into this issue just last week and tried to fix it since then. The newest PHP versions seem to have the 1000 variable limit as default?! Thereby limiting any menu to less than 84 items, since every item has 12 input variables.

Furthermore several timeouts can and will be reached if one increases the max_input_vars, on our server not more than 250 items can reside in a menu. In our case we ran into the timeout between Apache and mod_fcgi, which is not that easy to find out. Not to speak of timeouts in PHP, which there a quite a few for posting, processing and so on. Increasing these is a race to the top, but remember: they exist for security concerns.

Solutions are decreasing security in increasing timeouts or increasing the complexity of the setup when trying to narrow these timeout to just wp-admin, as some of them cannot be set in the context of a script.

Conclusion: We should work on the performance of this component.

If anyone has a good idea, I would try to provide a patch, although I never done anything like that before. But I guess we will need it in the near future...

One reason for not fixing this for two years may be there is no easy solution?!

I am now rather unsure what the problem is:

1. Is it this unbelievable amount of variables getting posted?
2. Is it the resulting array getting processed?

Solutions at hand:

1. Try to submit just the difference (will fix a., but may increase b.), not easy as a no-js version is hard to do
2. Paginate menus, not that elegant for UX
3. Make menus able to include other menus (See http://core.trac.wordpress.org/ticket/17031#comment:9)

So 3. as provided by ruud in 17031 is clearly a hack, but we could institutionalize it and provide another menu-item named "embed menu", similar to the individual menu widget.

This would make it possible to simply break down menus in smaller chunks, not only circumventing the max_post_vars problem, but also the increased processing time (which clearly occurs, at least on my machine).

I may quote the hack mentioned above (minor correction made, as theme_location should be 'menu'):

   $output .= apply_filters( 'walker_nav_menu_start_el', $item_output, $item, $depth, $args );
   if ( !empty( $item->xfn ) ) {
	$submenu = wp_nav_menu( array(
		'echo' => 0,
		'fallback_cb' => '',
		'menu' => $item->xfn,
		'menu_class' => 'sub-menu',
		'container' => false )
	);
	$output .= $submenu;
   }

This will display the included submenu correctly, but the classes set are wrong (ancestor relation f.e. will not be made across the two menus). I am unsure wether this is a critical modification, as some themes are extending the walker in question.

@ianboo, I always use 'theme-location' instead of 'menu' because i want to be sure of which menu I display (set with register_nav_menu(s)), and not rely on some coincidental match between the id,name or slug of the menu. Using 'menu' should work, though in my experience it sometimes unexpectedly failed on me, so I switched to 'theme-location' instead.

Nowadays I'm not having that much of a problem with the menu's anymore (using WP3.4.1 and lower). At the time I was having problems with the WP_Search plugin interfering with the save action of the menu.

However: for larger sites (with long (sub)menu's) I still use the above mentioned hack. The search plugin just made things even worse.

I would say that the fact some themes make their own walker is nice for the users of these themes, but probably not for the majority of the users. Then again the majority of the users is not going to build a website with very long menu's either...

For larger menu structures the current menu UX and saving of menu-items etc. is not very well suited. Changing it probably isn't that easy.

The 1000 variable limit applies only to each nesting level of a multi-dimensional input array - so a more clever collection of fields would probably solve that.

Something like:

<input name="menu[0]items[6][url]"/>

I have a recent scenario where I ran into max_input_vars - the problem turned out to be uncached database calls being made in a hierarchy loop on clean_post_cache in combination with a Google Sitemap generator running too often. Not saying that's the case here, just saying that monitoring SQL queries can often point to a piece of the software running out of control.

I thought the form was the main culprit because I had 3 post types acting like a hierarchy Post > Section > Items and had tons of sections and items. When I turned off cache invalidation (not a solution), almost every problem went away. clean_post_cache can end up making an absurd number of database calls.

I get the following error after php security update, in a multisite blog that uses many submenus and now doesn't let to add anymore:

PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini.

I wouldn't like to change php.ini. What I should do?

Thanks

If you have a very large number of menu items, then you will have a very large number of input vars. There's no working around that at present. In which case, yes, you will have to edit the PHP.INI or reduce the number of menu items.

Related: #22070

With this patch only changed menuitems will be transmitted

unittest for the menu item patch

I have the same problem with Suhosin and too much submit fields and there is no good work around. So I decided to change the implementation of menu editor to only transmit changed menu items.

For this to work each menu item get the flag "menu-item-unchanged" on load. When a menu item is changed in the web the flag will be removed. Only menu items without the flag will be transmitted to the server.

The deletion of menu item will now be done explicitly with a hidden "menu-item-delete" field and not with the absence of an item as before.

The tricky part was the transmission of the order of the menu items because they are totally ordered. That means when a new menu item is inserted at position "1" the position of all items of the menu have to be updated. In the old implementation the position was calculated in JavaScript and all items were transmitted. Now, only new items or items with a change are transmitted and the correct position of the other items are calculated in PHP.

I wrote also an unit test for the new PHP function wp_update_menu_item_positions.

There's no need to patch minified files, a post-commit bot takes care of it.

I'm having the same problem. I am transferring a 1,000 page site from Drupal 6, and have got up to just 75 pages with a custom menu structure before it times out - now giving me white pages when I update the menu structure.

It looks like WordPress 3.4.2 is not man enough for the job. Having said that, I see that there is a patch above. How do I implement that?

Or will next upcoming version correct this?

Replying to JulianHadlow:

I'm having the same problem. I am transferring a 1,000 page site from Drupal 6, and have got up to just 75 pages with a custom menu structure before it times out - now giving me white pages when I update the menu structure.

It looks like WordPress 3.4.2 is not man enough for the job. Having said that, I see that there is a patch above. How do I implement that?

Or will next upcoming version correct this?

WordPress 3.5 greatly improves performance for saving a menu. See #22189.

This ticket is about working around Suhosin limitations. As a workaround, simply make sure that Suhosin is not limiting your POST max variables. (See above.) Really, this is an "enhancement", not a bug. But the performance was, and that will be fixed in 3.5. Please test and see how it works for you.

The big thing to keep in mind about the custom menu builder is that it is a builder. If you have 1,000 pages, you *don't* want to be managing it through this. It wasn't designed for that use case. Something like wp_list_pages() is probably more what you are looking for.

See my workarounds as posted in my reply on this thread 8 months ago, about 20 up from here. My real estate site (converted from Joomla) is now over 750 pages and growing, and with the combination of plugins and workarounds I described earlier, no more menu maintenance or performance problems whatsoever on WP 3.3. I think the real issue lots of folks may be having is trying to put too many pages into one massive menu structure. That's why I use multiple small sidebar sub-menus controlled by the widget logic plugin, and only display a couple of them on any one page. My users love the ease of navigation this provides. It is not at all confusing to them because the sidebar sub-menus are always appropriate to the specific page they are displayed on, and they are not presented with too many choices. I think the SEs also like this because it keeps the number of hyperlinks on any one page to a reasonable number.

Thanks nacin, apart from the performance issues, WP desperately needs a proper tree view to organize menus for pages. I'm using a plug-in that does the job in the mean time. Let's hope the up-coming WP 3.5 sorts that one out.

ronnieg, I saw your comment above, and in fact I have installed the plugins you recommended, and now it is just fine. Because I cut my main menu down considerably, it now works with no problems. And like you, I now have menus displaying on sub-pages in my hierarchical structure, so I have menus on three levels now. Thanks for the tip!

My main concern now is that I'm creating a few dozen sub-menus, so I wonder what issues I will come across later as the site fills out?

Julian,
I have at least 40 small page specific menus, with no real problems. The only aggravating factor now is that all the menus flash along the horizontal menu list line when the menu builder initially loads, slowing that process significantly, and scrolling right and left to find the one I need to work on can be a real pain sometimes. It seems that whoever develops these things needs to think less about the flashy stuff and focus more on usability and friendly UI for sites of all sizes, including very large ones like ours, not just the minimal sites that may be used for development and testing. In this case, opening a separate "Open Menu" dialog page for selecting from a large list of menus would be easier than loading the left/right scrolling list.

The many issues and bugs I see when selecting individual pages/posts from the hundreds of available pages and posts, especially the unreliable search process, is a whole other topic.

Hi ronnieg,
I had a problem with conflicts between plugins, so I had to try out the suhosin timeout fix in comment 13 above. I haven't populated my menus fully again as yet, so no idea if it works for me so far...

I will end up waiting until WP 3.5 surfaces by the look of it until this is fixed.

Just wanted to chime in here, and say that we're experiencing this issue as well. No Suhosin on the server, plenty of memory allocated to PHP, no server timeouts or errors. Upgraded to 3.5 - still no dice.

On this particular site, there are about 135 pages for the menu - top level of 7. (Very well organized and laid out, so I kinda reject the "too many pages for a menu" argument.)

But once we get past about 100, adding them appears to work fine - 'til you save the menu - then they just disappear. No error, no lag.

Hope this gets fixed in the near future.

We've upgraded to 3.5 as well, there's no Suhosin, but a 1000 PHP variable limit on the server limits the menu size to 90 items. Items can be added to the menu, but they won't save. The last one doesn't save its parent and is set to "custom" rather than "page". Was this supposed to be resolved by #22189?

I have run into a "too many menus" problem that some people have encountered: it's just way too hard to find the menu you want if you have a whole bunch.

If no-one else is busy with it, does anyone mind me displaying a select when there are more than x menus?

#22939 was marked as a duplicate.

Convert the tabs to a select if there are more than 5 menus

The above patch doesn't really solve the problem of too many menu items, but it definitely does help if the user has several menus.

Maybe the patch should have its own ticket?

Replying to Sverigedemokraterna IT:

Maybe the patch should have its own ticket?

Yes, please.

I hit the menu item number barrier about a week and a half ago when I tried to add an additional item to my menus system. My site already had over 340 menu items on it at the time, and when I added that last item it all came down like a house of cards. Now I can't get but about 10% of my menu back.

I went into lengthy phone calls with my provider, and hours of research on the internet and could not come up with a solution to the problem. As this is a high school hockey web site (www.anokatornadoeshockey.com)the timing for it to go down was not good.

Whhile searching for a plugin that might solve the problem I tripped upon a plugin that led to the solution to my problem.

The plugin is called AllWebMenus (AllWebMenus WordPress Menu Plugin v1.1.16).

T
his plugin is a bridge to a stand alone desktop called AllWebMenus Pro. This program is a cross platform menu maker program that works with WordPress, Joomla, Drupal, Dreamweaver,Microsoft Expression and many other.

One of the things that this program allowed me to do was create menus that I could assign to specific page or pages and not show on any others. This allowed me to breakdown my main menu to a much smaller size without loosing any functionality.

I am now over 350 pages and growing. If you are curious as to what I did, check out the ​http://www.anokatornadoeshockey.com. I can be reached through the contact us page of the site if you have any questions about this.

Replying to davidsarver:

We've upgraded to 3.5 as well, there's no Suhosin, but a 1000 PHP variable limit on the server limits the menu size to 90 items. Items can be added to the menu, but they won't save. The last one doesn't save its parent and is set to "custom" rather than "page". Was this supposed to be resolved by #22189?

I just ran into the same issue with a site I am building. I am on latest WordPress 3.5.1 I am limited to a maximum of 90 items in the custom menu. If I try to add more, the last item listed at the bottom of a menu just disappears.

I have 19 parent categories and the rest (up to 90) are child categories.

Any resolution to this?

Replying to Rene Michaels:

Any resolution to this?

Don't hold your breath.

Read the entire thread here and see the posts on work-arounds that have solved this issue for me and others with large sites. These include plugins for managing large and complex page menu structures, automatically including sub-pages under a menu item so they do not have to be manually added to the parent page menu item, and taking advantage of multiple smaller menus that are displayed only on appropriate pages. Once you install and start working with these plugins, or others like them, you will want to have them on every site you work on, as I do.

Part of the resolution is that you have to be very diligent and structured in how you build and manage your page tree structures. Once you get that down, not only will menu management be easier, but if you also structure your page titles carefully, since they are included in the final url structure, you could see significant SEO benefits as well.

See one of my pages at: ​http://www.denverhomevalue.com/city/highlands-ranch-colorado.html

The top menu contains almost 80 entries, but was built with only the 10 main parent pages defined in the WP menu. The two left sidebar sub-menus are created with only one item each in their respective WP menu setups, the main parent page. Then all sub-pages are automatically included. The first sidebar menu is on every page, but the second sidebar menu occurs only on this page and all of its descendent pages, which you see in the menu.

This site now includes over 800 individual WP pages and is growing at a rate of 20-30 pages per month. It would never work with just the standard WP custom menu maintenance processes. Judicious use of page and menu management plugins is the only way I was able to make WP work for this site and many others I have built for real estate agents around the country.

Good luck!

If you go to

www.anokatornadoeshockey.com

you will see how I resolved this problem I have more than 350 menu items on that site. If you want to know how it is done, contact me at orders@…. I use this system on all of my websites.

Replying to orders@…:

If you want to know how it is done, contact me by going to the contact us menu item on the site and click on webmaster. I use this system on all of my websites.

Can't you just post here, in the interests of open source and making this all better? If we can fix this for everyone, that would be awesome.

Actually I did explain how it was done in the post just before your original post. I assumed that you had read it and had additional questions.

#23404 was marked as a duplicate.

So, 3 years later & still no fix for this??

Kinda' sad...

Insofar as an end user is concerned, one should be able to make arbitrarily large and arbitrarily deep menus and not have to worry about having their entire menu structure destroyed by some arbitrary limit... *Frustration*

There's got to be some better way.

I just lost several hours worth of work because of this bug... One that still doesn't appear to be documented anywhere (here for instance? ​http://codex.wordpress.org/Appearance_Menus_Screen), even though it's been a known issue for ~3 years. I was rather enjoying designing this new site, right up until the point where half my menu system just arbitrarily vaporized.

I've currently got about 91 menu items (basically, one section of a 'reference'/educational site I'm working on is split up into sectional pages, so I have a menu with 3 tutorials, one of which has ~11 sections, each section of which has about 5-10 sub-sections). I should have... Well I don't know exactly how many total menu items I should have 'cause I have no idea which menu items just got randomly lopped off my menu structure. Though, I can tell you a goodly portion of my top-level menu items have now disappeared. This is completely unacceptable, in my opinion, from an end-user / site admin standpoint. We rely on the CMS to have its act together and know what it's doing. Clearly, in this case, it seems not to if it's this brittle out-of-the-box... And nobody seems to know how to fix it once-and-for-all?

Do we know whether this is a data loss issue, or a playback issue? That is, are my menu items now gone forever, never to be seen again unless I recreate them, or is it simply an issue that prevents existing items (still saved in the database somewhere) from being displayed properly? I should hate to think that known data loss bug wasn't being properly addressed. So, I'm hoping it's merely a display bug??

Are there no creative thoughts about this fixing bug completely for everyone in a reasonably future-proof sort of way? Surely, if a new admin like me is already running across this bug a day or two into setting up a new site, there have to be a bunch more people running across it too and complete dumbfounded by it...?

Anyway, I'm not a programmer, so I'm not sure why the menu structure can't be arbitrarily large/deep. Seems like there must be some systematic way around this issue that can work for everyone?

Sorry if my questions have been answered somewhere else in this thread. I don't have the hours it would take to read it studiously from beginning to end...

Can we get some kind of a final solution for this?

P.S. Some have said in various fora something to the effect of modifying .htaccess with:

php_value max_input_vars 2000

-or-

suhosin.post.max_vars = 5000
suhosin.request.max_vars = 5000

-or-

php_value suhosin.post.max_vars 7000
php_value suhosin.request.max_vars 7000

Others have said maybe it goes in php.ini.

In any case they weren't overly specific on where in the files such things needed to go.

I've tried it in various places in both and gotten nowhere towards fixing this issue, in a few cases, editing .htaccess caused internal server error 500, so I had to back that out right quick...

Currently running WP 3.5.1, theme Mosaic, in case it matters.

Anybody know at least a workaround that reliably works? I'm using GoDaddy for domains & hosting, if that helps.

P.P.S. I just tried removing several menu items to see whether any prior menu items come back. They do not. So it sounds like this is data-lossy? Am I wrong? That's no bueno!

For now I'm killing my menu system and going with a page containing a hierarchical list of links to the different sectional pages of the tutorial and only listing a few of the top-level pages in he menu structure.

But don't take that as a free pass not to fix this issue in a reasonable and robust way. I still want to utilize my menu for easy access to certain of my pages from any page, via the menu system.

As we should all well know, people want to find things in as few clicks as possible and will only stay at if a few pages deep. If we can circumvent that transience by including pages in a simple menu system (the menu is only ~3 levels deep & simple to navigate), that's what we'd prefer to do. But if doing that causes some inexcusable nuking of a large portion of the menu structure in a lossy way (that is, the lost items DON'T come back after deleting the newer menu items), that's no bueno and needs to be fixed. Period.

Looks like wordpress-menuitem.patch​ needs a refresh and testing.