WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 2 weeks ago

#14134 reviewing defect (bug)

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

Reported by: jaanfx Owned by: filosofo
Milestone: Future Release Priority: high
Severity: major Version: 3.0
Component: Menus Keywords: has-patch needs-refresh needs-testing
Focuses: Cc:

Description

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...

Attachments (5)

save-menu-item-ajax.png (92.3 KB) - added by garyc40 3 years ago.
save-menu-item-nojs.png (86.5 KB) - added by garyc40 3 years ago.
wordpress-menuitem.patch (41.0 KB) - added by okax 18 months ago.
With this patch only changed menuitems will be transmitted
wordpress-menuitem-unittest.patch (6.6 KB) - added by okax 18 months ago.
unittest for the menu item patch
nav-menus.21383.diff (1.8 KB) - added by Sverigedemokraterna IT 16 months ago.
Convert the tabs to a select if there are more than 5 menus

Download all attachments as: .zip

Change History (136)

comment:1 filosofo4 years ago

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."

comment:2 jaanfx4 years ago

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.

comment:3 jaanfx4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:4 nacin4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:5 nacin4 years ago

  • Keywords menus disappear limited item removed
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

comment:6 follow-up: nacin4 years ago

  • Milestone set to Awaiting Review
  • Priority changed from normal to lowest
  • Resolution worksforme deleted
  • Severity changed from major to minor
  • Status changed from closed to reopened

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?

comment:7 nacin4 years ago

  • Keywords 2nd-opinion added

comment:8 in reply to: ↑ 6 filosofo4 years ago

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?

comment:9 vteixeira4 years ago

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.

comment:10 gazouteast4 years ago

  • Cc gazouteast added

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

comment:11 garubi4 years ago

  • Cc garubi added

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

comment:12 zsero4 years ago

  • Cc zsero added

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'''

comment:13 follow-up: Otto424 years ago

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.

comment:14 in reply to: ↑ 13 ; follow-up: filosofo4 years ago

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.

comment:15 in reply to: ↑ 14 zsero4 years ago

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.

comment:16 nacin3 years ago

  • Type changed from defect (bug) to enhancement

comment:17 garyc403 years ago

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.

garyc403 years ago

garyc403 years ago

comment:18 filosofo3 years ago

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.

comment:19 follow-up: garyc403 years ago

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.

comment:20 in reply to: ↑ 19 filosofo3 years ago

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.

comment:21 garyc403 years ago

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.

comment:22 markjaquith3 years ago

  • Owner set to filosofo
  • Status changed from reopened to reviewing

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.

comment:23 nacin3 years ago

  • Milestone changed from Awaiting Review to Future Release

comment:24 Otto423 years ago

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.

comment:25 markjaquith3 years ago

  • Priority changed from lowest to high
  • Severity changed from minor to major

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.

comment:27 jane3 years ago

@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.

comment:28 jane3 years ago

@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.

comment:29 follow-up: filosofo3 years ago

I'll work on making a patch for 3.2.

comment:30 in reply to: ↑ 29 nacin3 years ago

  • Milestone changed from Future Release to 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.

comment:31 follow-up: magblogapi3 years ago

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.

comment:32 in reply to: ↑ 31 filosofo3 years ago

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.

comment:33 follow-up: magblogapi3 years ago

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.

comment:34 in reply to: ↑ 33 filosofo3 years ago

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.

comment:35 jane3 years ago

  • Milestone changed from 3.2 to Future Release

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

comment:36 scribu3 years ago

  • Cc scribu added

comment:37 vdhamer3 years ago

  • Cc wordpress@… added

comment:38 vdhamer3 years ago

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.

comment:39 manicolaus3 years ago

  • Cc manicolaus added

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!

comment:40 Ipstenu3 years ago

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

Have we lost traction?

comment:41 scribu3 years ago

  • Keywords needs-patch 3.3-early added; 2nd-opinion removed

comment:42 scribu3 years ago

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.

comment:43 nacin3 years ago

  • Milestone changed from Future Release to 3.3

Let's figure it out.

comment:44 goto103 years ago

  • Cc dromsey@… added

comment:45 nacin3 years ago

  • Type changed from enhancement to task (blessed)

comment:46 sbressler3 years ago

  • Cc sbressler@… added

comment:47 scribu3 years ago

  • Keywords 3.3-early removed
  • Summary changed from WP3 - Menus item are limited to 16 item and will not save more than that to Menus item are limited to 16 item and will not save more than that

comment:48 chacha1023 years ago

  • Cc chacha102 added

comment:49 ryanberry3 years ago

  • Cc ryanberry added

comment:50 jane3 years ago

  • Milestone changed from 3.3 to Future Release

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.

comment:51 mikehuangsd3 years ago

  • Severity changed from major to critical

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!

comment:52 mikehuangsd3 years ago

  • Cc mikehuangsd added

comment:53 scribu3 years ago

  • Severity changed from critical to normal

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

comment:54 ronnieg3 years ago

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.

comment:55 raweiss2 years ago

  • Severity changed from normal to major
  • Version changed from 3.0 to 3.3

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.

comment:56 Otto422 years ago

  • Version changed from 3.3 to 3.0

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

comment:57 raweiss2 years ago

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?

comment:58 zipzap562 years ago

  • Version changed from 3.0 to 3.3.1

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.

comment:59 sbressler2 years ago

  • Version changed from 3.3.1 to 3.0

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.

comment:60 zipzap562 years ago

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

comment:61 phbrowne2 years ago

  • Cc phbrowne added
  • Type changed from task (blessed) to defect (bug)

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?

comment:62 rootix2 years ago

  • Cc rootix added

comment:63 follow-up: ronnieg2 years ago

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.

Last edited 2 years ago by ronnieg (previous) (diff)

comment:64 jemjabella2 years ago

  • Cc jemjabella added

comment:65 ruud@…2 years ago

  • Cc ruud@… added

comment:66 boonebgorges2 years ago

  • Cc boonebgorges@… added

comment:67 ianboo22 months ago

  • Cc ianboo added

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...

comment:68 ianboo22 months ago

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).

comment:69 ianboo22 months ago

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.

comment:70 ruud@…22 months ago

@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.

comment:71 wonderboymusic20 months ago

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.

Last edited 20 months ago by wonderboymusic (previous) (diff)

comment:72 xzoom19 months ago

  • Cc xzoom added

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

comment:73 Otto4219 months ago

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.

comment:74 DrewAPicture19 months ago

  • Cc xoodrew@… added

okax18 months ago

With this patch only changed menuitems will be transmitted

okax18 months ago

unittest for the menu item patch

comment:76 okax18 months ago

  • Cc okax added
  • Keywords has-patch added; needs-patch removed

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.

comment:77 SergeyBiryukov18 months ago

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

comment:78 follow-up: JulianHadlow17 months ago

  • Cc JulianHadlow added

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?

Last edited 17 months ago by JulianHadlow (previous) (diff)

comment:79 in reply to: ↑ 78 nacin17 months ago

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.

comment:80 ronnieg17 months ago

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.

comment:81 JulianHadlow17 months ago

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?

comment:82 ronnieg17 months ago

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.

comment:83 JulianHadlow17 months ago

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.

comment:84 IAmediaworks17 months ago

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.

comment:85 follow-up: davidsarver17 months ago

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?

comment:86 edward mindreantre17 months ago

  • Cc edward@… added

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?

comment:87 Ipstenu17 months ago

#22939 was marked as a duplicate.

Sverigedemokraterna IT16 months ago

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

comment:88 follow-up: Sverigedemokraterna IT16 months ago

  • Cc Sverigedemokraterna IT added

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?

comment:89 in reply to: ↑ 88 SergeyBiryukov16 months ago

Replying to Sverigedemokraterna IT:

Maybe the patch should have its own ticket?

Yes, please.

comment:90 orders@…16 months ago

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.


comment:91 in reply to: ↑ 85 ; follow-up: Rene Michaels15 months ago

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?

comment:92 in reply to: ↑ 91 ronnieg15 months ago

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!

comment:93 follow-up: orders@…15 months ago

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 by going to the contact us menu item on the site and click on webmaster. I use this system on all of my websites.

Last edited 15 months ago by orders@… (previous) (diff)

comment:94 in reply to: ↑ 93 Ipstenu15 months ago

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.

comment:95 orders@…15 months ago

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.

comment:96 SergeyBiryukov15 months ago

#23404 was marked as a duplicate.

comment:97 mgmirkin14 months ago

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.

Last edited 14 months ago by mgmirkin (previous) (diff)

comment:98 SergeyBiryukov14 months ago

  • Keywords needs-refresh needs-testing added

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

comment:99 shawnkhall12 months ago

  • Cc shawnkhall added

comment:100 vegasgeek11 months ago

  • Cc john@… added

comment:101 jb51011 months ago

  • Cc jbrown510@… added

comment:102 blobaugh11 months ago

  • Cc ben@… added

comment:103 birgire10 months ago

  • Cc birgire added

comment:104 in reply to: ↑ 63 tadousay10 months ago

Replying to ronnieg:

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.

This is simply brilliant. THANK YOU!

I'm another victim of this limitation. A site I'm converting from DWT to WP was previously built on a server running PHP 5.1.6 and ported to a new host running 5.3. More than half our menu was lost when we tried to add one menu item.

I did want to add for others who follow ronnieg's workaround that, if you're like us and have external links as a child menu item, I've found that the Page Links To plug-in works beautifully with this solution.

comment:105 keith139 months ago

  • Cc keith@… added

comment:106 keith138 months ago

Finally, a simple solution to this problem from the WordPress forum.

Simply add the following:

php_value max_input_vars 5000

to your .htaccess file.

After being stuck with limit of 89 menu items for over a year, I now have 95 and increasing. I have no idea what, if any, is the new upper limit.

comment:107 WraithKenny8 months ago

This bug has new behavior since the last release, since "Menu Settings" is now at the bottom. When adding too many items, the menu is effectively removed from the "Theme Location."

Of the solutions on the ticket, posting only what items change seems to be the only sane way forward... Or use Ajax.

P.S. php_value max_input_vars 5000 works fine.

Last edited 8 months ago by WraithKenny (previous) (diff)

comment:108 jasonheffner7 months ago

For those still having problems I'd recommend putting your site into debug mode and use save queries. The Debug Bar plugin helped to track the issue to the WordPress MU Sitewide Tags Pages plugin. With this plugin enabled a site with 60 menu items took 53.4123 seconds to update, disabled it only took 574 milliseconds.

I wanted to post this in case it helps anyone else.

comment:109 nielsvanrenselaar5 months ago

This really needs to get fixed. Maybe switching the saving to AJAX to bypass the limit? With sites getting bigger and bigger, and so do the menu's its getting a real issue here on hosting environments we don't manage.

comment:110 dd325 months ago

It seems like we might be able to serialize the form data into a JSON object, POST that instead, and overwrite $_POST server-side with that data..

comment:111 follow-up: nielsvanrenselaar5 months ago

That will not solve the issue where the most shared hosting packages will limit the POST vars to 1000, so it should also be seperated in multiple parts when the limit is reached.

comment:112 in reply to: ↑ 111 ; follow-up: dd325 months ago

Replying to nielsvanrenselaar:

That will not solve the issue where the most shared hosting packages will limit the POST vars to 1000, so it should also be seperated in multiple parts when the limit is reached.

It would if the shared host only saw 5 post vars, one of which, just so happens to contain a large JSON object.

comment:113 in reply to: ↑ 112 nielsvanrenselaar5 months ago

Replying to dd32:

Replying to nielsvanrenselaar:

That will not solve the issue where the most shared hosting packages will limit the POST vars to 1000, so it should also be seperated in multiple parts when the limit is reached.

It would if the shared host only saw 5 post vars, one of which, just so happens to contain a large JSON object.

Ah yes, I stand corrected. That would solve this issue and also the issue that the location is reset when the limit is reached.

comment:114 follow-up: jakerichey4 months ago

We spent a crap load of time with this. After trying everything, nothing seemed to work. We modified the php.ini in the root public_html folder. We tried adding it to the WP theme folder itself. We tried adding to .htaccess. We could even see the changes reflected in phpinfo.php in all folders.

I called up Bluehost to explain, and he told me we had to set the max_input_vars 5000 to the root php.ini Since we are on a VPS, I didn't know there was a difference. Im not savvy with SSH, but he walked me through it.

Lastly, make sure you RESET the server. Once we did this, it now works and we can add 100+ menus, sub-menus etc.

Hope this helps someone.

comment:115 DimentR3 months ago

19.01.2014.
Wordpress 3.8
The problem is not solved.
We will try to edit the server settings.

comment:116 DimentR3 months ago

php_value max_input_vars 5000 in .htaccess - seems to be helped

ps
Thank Sergei Biryukov (link found in his subject) and to all who have tried to solve this problem and wrote about the results.
But of course, this is not the case that the problem is still not solved.

comment:117 follow-up: Tone10lite3 months ago

Hey so I just read through most of this thread because I believe I'm having the same problem. I Had a menu without 10 items and each had submenus. A few days ago i tried adding a new one and it ended up disappearing. I took a few days to just work on pages and leave the menu side of things alone. Today I tried to add the menus again and this time half of menus have disappeared. At first they all disappeared but I went to the "Manage Locations" settings a rechecked my original menu which brought back half of them.

I honestly am lost after reading through these responses as I am not a computer programmer and I am a week into building my first website. I kind of got the part about changing the max input vars thing but I have no idea how I would go about doing that. I would really appreciate it if there was someone who can put this into easier terms for me and help me out. I currently use "HostGator" as my server and my theme is the "Pictorial" theme. Thanks guys!

comment:118 in reply to: ↑ 117 ; follow-ups: ronnieg3 months ago

Replying to Tone10lite:

See my earlier reply and work-around at reply:63 in this thread.

Newer WP versions do handle this a little better. Make sure you are on WP 3.8 or later.

Installing the two plugins mentioned ("CMS Tree Page View" and "Add Descendants as Submenu Items") and using them should be all you need to do, regardless of the server or hosting environment your site is on.

After installing them:

Use the new "CMS Tree Page View" in the Dashboard Pages menu to get your parent/child page structures organized as they needs to be for your menu.

Edit your main menu and delete all manually added sub-menu items under the top level entries, and instead, use the new check box in each top level menu item to "Automatically add all descendants as submenu items". Save the menu. Be sure to specify that menu as your theme's primary navigation menu.

Then, in future, as long as you use the CMS Tree Page View to add all new pages under existing top level menu items and in the desired order, and you don't need to re-arrange or add to the top level pages, you should never have to edit the top menu again.

Using these plugins and processes, my main menu is over 80 main and sub-menu items, of which only 19 are defined in the WP custom menu, and that is not a problem for WP 3.8. My site has over 700 WP pages. So I have to go even further and use the other plugins and processes I describe in my earlier reply to build and display additional sidebar menus on applicable pages. But unless you have a huge and complex site like mine, the simplest solution is to use the two plugins I describe here.

comment:119 Tone10lite3 months ago

Thanks so much man, really appreciate it.

comment:120 in reply to: ↑ 118 ; follow-up: freakybusiness3 months ago

I just wanted to second that "THANKS SO MUCH!" Ronnieg and ask an additional related question please.

In my old menu, I added "null" menu items using the "Links box" in the wp edit menus / menu structure page.

These menu items were null as the url I entered was "http://#". These null links were used to sub-divide my client's products into sub-menus.

EG:
Product menu

  • SQUARE (http://#) null link
  • - product 1
  • - product 2
  • RECTANGLE (http://#) null link
  • - product 1
  • - product 2
  • CIRCLE (http://#) null link
  • - product 1
  • - product 2

Is there a way to re-implement this approach using the CMS Tree Page View and Add Descendants as Submenu Items?

Thankyou in advance and I do not mean to hijack the thread.

Regards

Michael

comment:121 in reply to: ↑ 120 ronnieg3 months ago

Replying to freakybusiness:

No way to do that because menu links that are not pages do not have a post_id, so they cannot be parent pages.

I use your technique for some of my sidebar menus, where the sub-menu items are a small, selected subset of a larger parent group, and I don't want all of the child pages of that group in that menu. Or when the sub-pages may be a few selected pages from several different parent groups.

But I generally create actual parent pages and use another plugin "Subpages Extended" to list that page's child pages on the parent page so it isn't totally blank if the user opens it. The parent page then becomes a small menu or "Nav Helper" page that opens when clicked from the top menu. I think that is more user friendly and consistent than a null menu item that does nothing when the user clicks it.

comment:122 in reply to: ↑ 118 ; follow-up: Robertmolloy9993 months ago

Replying to ronnieg:

Hi Ronnie,

I am trying to adjust the max vars setting in suhosin for wp_nav_menu limit since an upgrade from php 5.3 to 5.4. It seems that suhosin is not included in php 5.4 due to compatibility issues as suhosin will not compile on this version of php. Sorry to sound thick but is your above comment cover what issues I have? i.e. how to get round the wp_nav_menu limit settings if suhosin is not installed?

Thanks

Replying to Tone10lite:

See my earlier reply and work-around at reply:63 in this thread.

Newer WP versions do handle this a little better. Make sure you are on WP 3.8 or later.

Installing the two plugins mentioned ("CMS Tree Page View" and "Add Descendants as Submenu Items") and using them should be all you need to do, regardless of the server or hosting environment your site is on.

After installing them:

Use the new "CMS Tree Page View" in the Dashboard Pages menu to get your parent/child page structures organized as they needs to be for your menu.

Edit your main menu and delete all manually added sub-menu items under the top level entries, and instead, use the new check box in each top level menu item to "Automatically add all descendants as submenu items". Save the menu. Be sure to specify that menu as your theme's primary navigation menu.

Then, in future, as long as you use the CMS Tree Page View to add all new pages under existing top level menu items and in the desired order, and you don't need to re-arrange or add to the top level pages, you should never have to edit the top menu again.

Using these plugins and processes, my main menu is over 80 main and sub-menu items, of which only 19 are defined in the WP custom menu, and that is not a problem for WP 3.8. My site has over 700 WP pages. So I have to go even further and use the other plugins and processes I describe in my earlier reply to build and display additional sidebar menus on applicable pages. But unless you have a huge and complex site like mine, the simplest solution is to use the two plugins I describe here.

comment:123 in reply to: ↑ 122 ronnieg3 months ago

Replying to Robertmolloy999:
Correct. Using the plugins and work-arounds I described avoids (does not fix) the issue for any platform or hosting service or combination of server and php settings, including Godaddy, where I use those techniques for a site with 60+ main menu items. However, I have also seen that some users are reporting that the issue my not be in WP at all, but possibly conflicts in certain plugins. So you may want to try disabling plugins to see if that may be the issue in your case. I don't know or remember which plugins were suspects.

comment:124 follow-up: Tone10lite3 months ago

Hey I have one more question you may be able to help me out with. Is there any way to add one page to multiple parent pages? So I have one page that fits under multiple categories so I would like to add it to more then one parent page. Thanks!

comment:125 in reply to: ↑ 124 Ipstenu3 months ago

Tone10lite: That's a support question. Please post in the forums.

https://wordpress.org/support/

comment:126 in reply to: ↑ 114 hartsook2 months ago

Replying to jakerichey:

Client has Bluehost shared hosting. Tries to add 91st menu item, WP 3.8.1 adds to the active menu, but on Save Menu screen refreshes and the added menu item is no longer there. Happens with all plugins disabled and Twenty Eleven Theme active.

Edited php.ini to max_input_vars = 5000. Problem is still there. Unable to request server RESET since it is shared hosting.

Any other suggestions other than the ("CMS Tree Page View" and "Add Descendants as Submenu Items") plugin work-around?

We spent a crap load of time with this. After trying everything, nothing seemed to work. We modified the php.ini in the root public_html folder. We tried adding it to the WP theme folder itself. We tried adding to .htaccess. We could even see the changes reflected in phpinfo.php in all folders.

I called up Bluehost to explain, and he told me we had to set the max_input_vars 5000 to the root php.ini Since we are on a VPS, I didn't know there was a difference. Im not savvy with SSH, but he walked me through it.

Lastly, make sure you RESET the server. Once we did this, it now works and we can add 100+ menus, sub-menus etc.

Hope this helps someone.

comment:127 ircbot2 months ago

This ticket was mentioned in IRC in #wordpress-dev by ipstenu. View the logs.

comment:128 rimmllc8 weeks ago

I also was experiencing this very frustrating situation. I tried all the above suggestions except for the plugin route. The following combination solved my menu limitation problem.

Upgraded to PHP v5.5 and max_input_vars = 4000.

For me this worked. I also tried PHP v5.4 but did not work either. Maybe something in 5.5?

comment:129 helgatheviking8 weeks ago

How the menu data is saving is limiting us from ever adding hooks in the admin.. which is another ticket that I am interested in. I would be interested in working on this, but I don't really know where to start. So if anyone wants to throw some ideas around, email me... my username @gmail.

comment:130 kheld7 weeks ago

For anyone running WP under IIS 7+. You may need to configure the FASTCGI requestTimeout in your web.config file in addition to your php.ini settings. See this link for more information

http://www.bokko.nl/increase-fastcgi-php-activitytimeout-in-iis7/

comment:131 DrewAPicture2 weeks ago

#27707 was marked as a duplicate.

Note: See TracTickets for help on using tickets.