#14134 closed defect (bug) (fixed)
Menus item are limited to 16 item and will not save more than that
Reported by: | jaanfx | Owned by: | ericlewis |
---|---|---|---|
Milestone: | 4.5 | Priority: | high |
Severity: | major | Version: | 3.0 |
Component: | Menus | Keywords: | |
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 (13)
Change History (228)
#2
@
14 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.
#3
@
14 years ago
- Resolution set to fixed
- Status changed from new to closed
That solves the problem, great, thank you so much.
#5
@
14 years ago
- Keywords menus disappear limited item removed
- Milestone Awaiting Review deleted
- Resolution set to worksforme
- Status changed from reopened to closed
#6
follow-up:
↓ 8
@
14 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?
#8
in reply to:
↑ 6
@
14 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?
#9
@
14 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.
#10
@
14 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
#11
@
14 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
#12
@
14 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'''
#13
follow-up:
↓ 14
@
14 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.
#14
in reply to:
↑ 13
;
follow-up:
↓ 15
@
14 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.
#15
in reply to:
↑ 14
@
14 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.
#17
@
14 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.
#18
@
14 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.
#19
follow-up:
↓ 20
@
14 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.
#20
in reply to:
↑ 19
@
14 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.
#21
@
14 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.
#22
@
14 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.
#24
@
14 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.
#25
@
14 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.
#27
@
14 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.
#28
@
14 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.
#30
in reply to:
↑ 29
@
14 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.
#31
follow-up:
↓ 32
@
14 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.
#32
in reply to:
↑ 31
@
14 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.
#33
follow-up:
↓ 34
@
14 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.
#34
in reply to:
↑ 33
@
14 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.
#35
@
14 years ago
- Milestone changed from 3.2 to Future Release
No patch since filosofo's comment 6 weeks ago. Past freeze, punting.
#38
@
14 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:
- it sometimes occurs for very modest-sized menus
- many self-hosted users are not in a position to analyze this far
- 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.
#39
@
13 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!
#40
@
13 years ago
FYI - this came up again here: http://wordpress.org/support/topic/rc32-menus-still-crippled
Have we lost traction?
#42
@
13 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.
#47
@
13 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
#50
@
13 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.
#51
@
13 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!
#53
@
13 years ago
- Severity changed from critical to normal
This should already be improved in 3.3 thanks to #16799.
#54
@
13 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.
#55
@
13 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.
#56
@
13 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.
#57
@
13 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?
#58
@
13 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.
#59
@
13 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.
#60
@
13 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.
#61
@
13 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?
#63
follow-up:
↓ 104
@
13 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.
#67
@
12 years 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...
#68
@
12 years 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:
- Is it this unbelievable amount of variables getting posted?
- Is it the resulting array getting processed?
Solutions at hand:
- Try to submit just the difference (will fix a., but may increase b.), not easy as a no-js version is hard to do
- Paginate menus, not that elegant for UX
- 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).
#69
@
12 years 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.
#70
@
12 years 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.
#71
@
12 years 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.
#72
@
12 years 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
#73
@
12 years 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.
#76
@
12 years 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.
#78
follow-up:
↓ 79
@
12 years 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?
#79
in reply to:
↑ 78
@
12 years 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.
#80
@
12 years 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.
#81
@
12 years 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?
#82
@
12 years 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.
#83
@
12 years 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.
#84
@
12 years 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.
#85
follow-up:
↓ 91
@
12 years 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?
#86
@
12 years 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?
#88
follow-up:
↓ 89
@
12 years 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?
#90
@
12 years 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.
#91
in reply to:
↑ 85
;
follow-up:
↓ 92
@
12 years 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?
#92
in reply to:
↑ 91
@
12 years 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!
#93
follow-up:
↓ 94
@
12 years 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.
#94
in reply to:
↑ 93
@
12 years 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.
#95
@
12 years 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.
#97
@
12 years 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.
#98
@
12 years ago
- Keywords needs-refresh needs-testing added
Looks like wordpress-menuitem.patch needs a refresh and testing.
#104
in reply to:
↑ 63
@
11 years 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.
#106
@
11 years 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.
#107
@
11 years 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.
#108
@
11 years 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.
#109
@
11 years 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.
#110
follow-up:
↓ 180
@
11 years 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..
#111
follow-up:
↓ 112
@
11 years 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.
#112
in reply to:
↑ 111
;
follow-up:
↓ 113
@
11 years 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.
#113
in reply to:
↑ 112
@
11 years 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.
#114
follow-up:
↓ 126
@
11 years 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.
#115
@
11 years ago
19.01.2014.
Wordpress 3.8
The problem is not solved.
We will try to edit the server settings.
#116
@
11 years 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.
#117
follow-up:
↓ 118
@
11 years 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!
#118
in reply to:
↑ 117
;
follow-ups:
↓ 120
↓ 122
@
11 years 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.
#120
in reply to:
↑ 118
;
follow-up:
↓ 121
@
11 years 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
#121
in reply to:
↑ 120
@
11 years 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.
#122
in reply to:
↑ 118
;
follow-up:
↓ 123
@
11 years 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.
#123
in reply to:
↑ 122
@
11 years 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.
#124
follow-up:
↓ 125
@
11 years 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!
#125
in reply to:
↑ 124
@
11 years ago
Tone10lite: That's a support question. Please post in the forums.
#126
in reply to:
↑ 114
@
11 years 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.
This ticket was mentioned in IRC in #wordpress-dev by ipstenu. View the logs.
11 years ago
#128
@
11 years 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?
#129
@
11 years 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.
#130
@
11 years 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/
#132
follow-up:
↓ 133
@
11 years ago
I have had the same menu item limitation at 90 on WP3.9 just like others. I followed ronnieg's advice for a workaround, but ran into a problem with a new install of CMS Page Tree View on 3.9 where the ability to drag and change elements in the tree is lost. It seems to have happened to others recently and there may be a workaround for that, but I am now on a workaround for my workaround. Is there significant risk in depending on a plugin workaround if the plugins are not updated/supported in the future? Or am I better redesigning my navigation to stay within 90 pages...possible, but more work and maybe not ideal for my site.
#133
in reply to:
↑ 132
@
11 years ago
Replying to Cristiano_Ronaldo:
I am running WP 3.9 and CMS Tree Page View on several sites, with no issues or problems dragging menu items. I have found that you need to click and hold the page item for a couple of seconds, then drag it to its new location in the structure, and do not release the mouse button until you get a green check mark on the dragged item at its new location.
Since I sometimes have as many as 200 child pages under one parent page (subdivisions of a particular city in my case), I have also developed a function, implemented as a shortcode, that when the parent page with that shortcode is accessed by a logged-on admin, it will automatically sort all of its child pages alphabetically by title and assign new page_order values to each child page. This minimizes the need to manually drag child pages into alphabetical order, which is how I order mine.
#134
@
11 years ago
I resolved the issue at somebody's recommendation to install an old version and then use 3.9 to update. It works fine now. I set up menus of pages...works great. I am having trouble replacing my menu of Categories that link to posts. I see CMS Tree Page View organizes posts, but since my WP menu uses Categories to organize posts how do I create the same menu for my posts on the front end the way I did for Pages? Hopefully it is more simple than I expect.
#135
@
11 years ago
Not sure if any of the following is possible, but just typing "aloud"...
What if the $_POST was split into pieces anytime the $_POST approached the limit. If these chunks could be stashed (in a transient or something?) then when the page reloads it checks for the presence of additional chunks to process?
What about preparing the chunks via ajax and then processing that when the form posts?
Can unchanged items not be posted?
#136
@
11 years ago
I updated my patch to work with wordpress version 3.9. With this patch only changed menu items will be transmitted in the post to the server so that the post vars limit of the server will not be reached as long as not all menu items will be changed at the same time. Furthermore, menu entries will only be deleted on the server, when they were explicitly deleted in the GUI so reaching the post vars limit will not delete menu entries.
Maybe there is someone who can review this patch.
#138
@
11 years ago
In my case Suhosin is core of problem. Plugin Uebermenu get me alert:
"
Menu Item Limit Warning
Your server is running Suhosin, and your current maxvars settings may limit the number of menu items you can save.
max_input_vars :: 10000
suhosin.post.max_vars :: 800
suhosin.request.max_vars :: 800
Menu Item Post variable count on last save :: 0
Approximate remaining menu items :: 666
Loaded configuration file: .../php.ini
"
So I ask server admin change Suhosin script on "extended" and now works saving much faster on the page as on the other blogs too
#139
@
11 years ago
What exactly is the status of this ticket?
- Is someone from the core team supposed to review the provided patch and provide feedback?
- Is the provided patch something that may be accepted or do we need to provide alternative solutions?
- Is there another feature or change that is coming down the pipes that we are waiting on?
- Should we focus on writing unit tests that fail when the limitations are reached?
I'd be glad to work on this ticket, but don't want to do so without understanding where we are in the process and what work will actually get the ball rolling.
#140
@
11 years ago
Problem because its not only core wordpress problem. In my case was solution in the value of Suhosin (Max Vars extended works).
#141
follow-up:
↓ 142
@
11 years ago
It is a WordPress problem because the menus have such a huge $_POSt data that it runs into the max vars. I like the idea of the patch only saving changed items but haven't tested it.
#142
in reply to:
↑ 141
@
11 years ago
Replying to helgatheviking:
It is a WordPress problem because the menus have such a huge $_POSt data that it runs into the max vars. I like the idea of the patch only saving changed items but haven't tested it.
Agreed. WordPress needs to work within the context of standard server configurations. The 5 minute install claim won't really apply if we require additional server configurations. So, the question is will the current patch work or do we need to get more creative?
It seems to me that this solution probably wouldn't work when initially creating a large menu.
#143
@
11 years ago
I ran into this problem last night at around 56 menu items.
In looking into the DB, any new items added were added to the Table wp_posts with a draft status.
Manually changing it to publish didn't work. Adding a term relationship between the menu id and the object id for the new menu item did work temporarily. Upon visiting the UI screen, hitting save deleted all the changes I had made in my DB.
Is there any sane explanation as to how the DB is structured so people can make changes on the backend?
#145
@
11 years ago
Aha - for me the culprit was developing in PhpStorm and listening for bug connections!
Was pulling my hair out for hours over this. Turning it off and all seems to be back to normal. Good thing I backed up my DB :)
#147
@
10 years ago
Idea - add a nonce or other hidden form field at the end for validation, and bail with a notice if it's not present. That won't solve this issue, but it should be preferable to having menu entries deleted.
This ticket was mentioned in IRC in #wordpress-dev by celloexpressions. View the logs.
10 years ago
#149
@
10 years ago
- Milestone changed from 4.0 to Future Release
Unfortunately, this is nowhere near being ready for 4.0.
The only way to fully solve this and make the menus admin fully scalable is to save menu items individually via ajax as they're changed. This can be done without immediately publishing those changes, but doing so within the current framework would be tricky.
My Menu Customizer GSoC Project now does this, implementing Menus in a scalable way. That project is a few releases from being ready from core but will most likely make it into core in some form at some point. The plugin cannot be used to work around this bug just yet, but it most likely will be able to do so in the next couple months, as the internals are cleaned up and its development shifts focus to UI. Since that project aims to replace the existing Menus screen entirely (where the Customizer is supported), I don't think refactoring the existing Menus screen to do things on an item-by-item basis, and using Backbone.js, is a good use of time.
There are some things we can do here to make things work better:
- wordpress-menuitem-3.9.patch is a good idea, if it does what it says, but it needs extensive review and testing. This can come from anyone, at least initially, not just core committers, so if you'd like to help move this ticket please jump in here.
wp_update_nav_menu_items()
is a mess, and is responsible for a lot of the issues that trickle down to the UI and this ticket. It could use a major overhaul, or, at the very least, #28138.- Menu items each have 13 fields that are inputs on nav-menus.php. Several hidden inputs have values that never change, and those could be removed if we do #28138.
We could get to a reasonable improvement here with a combination of the above, but that'll take a good amount of work from several people patching, reviewing, and testing here.
See also: https://plugins.trac.wordpress.org/changeset/946618/menu-customizer
#150
follow-up:
↓ 154
@
10 years ago
So, 4 years later, the problem persists.
Here's what worked for me (after a couple of days of hair pulling, with a client presentation tomorrow morning, and most of the above discussion above my head...) -
Add
max_input_vars = 4000
php_value max_input_vars = 5000
to
php.ini
I'm using Wordpress 3.9.1 and the Avada theme, hosting with MediaTemple.
Maybe this will help somebody.
This ticket was mentioned in IRC in #wordpress-dev by johnbillion. View the logs.
10 years ago
#153
@
10 years ago
I am thoroughly confused by the behavior I am getting from WordPress around my menus. I have three installs of WordPress on one MediaTemple (dv) server. It was running PHP 5.3.5 but has now been upgraded to PHP 5.5.18, I've added the max_input_vars
settings to the configuration and am still getting this issue. The problem is that I am only getting the issue on one of the three installs - the production server. The other two (with identical plugins) have no problem saving the menu or adding new menu items. All are running WP 3.8.4.
Hopefully this can be easily explained, and the current concepts for a patch are sufficient. Happy to get more data if someone will point me in the right direction of what would be helpful.
UPDATE: Completely disregard this, found an unrelated issue causing the error. For anyone interested: Global Translator was causing the error, I assume because of it's caching engine. Also because it is old.
#154
in reply to:
↑ 150
;
follow-up:
↓ 155
@
10 years ago
Replying to RNAstudio:
So, 4 years later, the problem persists.
Here's what worked for me (after a couple of days of hair pulling, with a client presentation tomorrow morning, and most of the above discussion above my head...) -
Add
max_input_vars = 4000
php_value max_input_vars = 5000
to
php.ini
I'm using Wordpress 3.9.1 and the Avada theme, hosting with MediaTemple.
Maybe this will help somebody.
And help it did, I added it to php.ini as you said and it works smoothly now.
I am on shared hosting and the ini file was in the main html folder. The host said it was not the real php.ini file because it contained mostly information about the Zend Optimizer. I took a chance and added your info and it worked regardless.
Smooth as silk, thanx for posting the fix.
#155
in reply to:
↑ 154
@
10 years ago
Replying to mnmca:
I'm having the SAME exact issues. Post_vars too low in php.ini, etc. Of course the whole menu building process needs GRAVE improvement. We have a sit with 7 main menu items, each having a dozen or so sub-menu items. And the more menu items I add, the slower and slower it all gets. And dragging/dropping the menu items to their proper place is tedious, especially if I'm adding a new menu item to the TOP have to drag it all the way up.
My suggestions is that each parent menu group can be collapsed.
Also, the list of pages on the left doesn't seem to follow a recognizable order. I've setup our pages hierarchically, but they don't show up that way.
Finally, the actual menu update should occur as follows:
1) The page/menu is dragged to the proper location.
2) A "Save" button for the respective menu that's been added/updated appears in the menu's block
3) Clicking "Save" saves the menu's position (with as few post_vars as possible) and the "Save" button hides.
This way the whole menu doesn't have to be saved each time, but only the affected menu item, and the items around it.
The other issue I'm running into (which I assume is part of the same post_vars issue) is that the checkbox which enables the theme's menu doesn't stay on. That's annoying.
Please, this has been an ongoing issue for over 4 years...it's time to get this resolved.
Replying to RNAstudio:
So, 4 years later, the problem persists.
Here's what worked for me (after a couple of days of hair pulling, with a client presentation tomorrow morning, and most of the above discussion above my head...) -
Add
max_input_vars = 4000
php_value max_input_vars = 5000
to
php.ini
I'm using Wordpress 3.9.1 and the Avada theme, hosting with MediaTemple.
Maybe this will help somebody.
And help it did, I added it to php.ini as you said and it works smoothly now.
I am on shared hosting and the ini file was in the main html folder. The host said it was not the real php.ini file because it contained mostly information about the Zend Optimizer. I took a chance and added your info and it worked regardless.
Smooth as silk, thanx for posting the fix.
#156
@
10 years ago
- Keywords needs-unit-tests added
[spoiler alert: this is just another report with more details for this issue, not a solution or fix]
Hello everybody,
I ran into this bug a couple of days ago, and after all I tried so far to fix it / workaround it I am feeling really helpless.
Here is my situation:
I am running on WP 4.1 "Dinah", a multisite (network) with a handful of pages - all of them quite small in scale (from the perspective of an end user, the overall scale / numbers of my menus should BY NO MEANS be a problem). Themes include "decode theme", "minimal", of course "twentyfifteen" and others. More on themes below...
suhosin.post.max_vars = 64000 suhosin.request.max_vars = 64000
is what I put into .htaccess
- 64000 is the number, that I got emailed from my provider support guys as their standard setting on all of their servers - so I am using this number now.
- I tried some other numbers suggested elsewhere, but it did not seem to make a difference at all.
but adding those numbers to .htaccess within /htdocs/wordpress had NO effect.
--> wrong line in file?
--> wrong location for ".htaccess"?
--> wrong configuration of .htaccess elsewehere?
- in addition I created a php.ini from scratch in /htdocs/wordpress with two lines reading:
max_input_vars = 64000 php_value max_input_vars = 64000
- but this did not change the situation either.
Status quo:
- ALL of my plugins are deactivated (throughout the multisite network)
- I could reproduce the bug using DIFFERENT super admin USERS in the network
- I switched themes to twelvefifteen (same issue)
- I overwrote the filesystem from a fresh WP 4.1 download and all of my contents from a backup I did BEFORE the problem occured
- I configured WP to access a sql database version PRIOR to the first appearance of the problem
The behaviour of appearance-->menus (...) is still as follows:
"[mysite]/nav-menus.php"
- i can NOT add new items (pages/posts...) to ANY menu, the interface does not show the single items (the "boxes"), nor is any new item saved.
- As soon as I choose "Add to menu", all I get is a sentence saying
"Drag each item into the order you prefer. Click the arrow on the right of the item to reveal additional configuration options."
- there are NO ITEMS to drag around (under "menu structure")
- when I hit "Save Menu", nothing changes.
- creating a new menu, OR deleting existing menus is possible though, but can not commit edits
- top level pages are added automatically (if I choose this option) but I can NOT manipulate this manually, such as sort order, etc. The order seems to be sort of random
- the location of the menu is saved, but not reliably: through the theme customizer ("navigation" panel), it will preview / save the correct location of an existing menu, but I cannot save this information through the location-tab in the menu
#160
@
10 years ago
So the current status of this issue is that Okax's patch is pending review, but we really want a solution that uses ajax to save the menu instead.
Seems like this has been unfixed for too long. Anything I can do to help?
+1 on okax's patch. Seems to still work on 4.3-dev. The logic is solid.
This ticket was mentioned in Slack in #core by helen. View the logs.
10 years ago
This ticket was mentioned in Slack in #core by jorbin. View the logs.
10 years ago
#163
follow-up:
↓ 165
@
10 years ago
Menu Customizer should now be 100% scalable and is being proposed as a replacement for the current menus administration screen for WordPress 4.3. While the plugin may work on WordPress 4.2, it's best to test with 4.3-alpha on a test site.
If people facing this issue could confirm that they're able to manage their menus with the UI introduced in the Customizer via the Menu Customizer plugin, without running into scaling issues, that will allow us to move forward with the new approach, as well as enabling the various tickets that this ticket blocks to move forward.
A couple of specifics on the approach to scaling:
- Menu items are saved to the database whenever they're changed, added, or updated on an individual basis with ajax. However, they're draft items that aren't fully published until save. On save, the menu item data is not re-sent to the server, instead, only the final menu ids, in order, are sent.
- Menu items are loaded from json data passed on load. Menu items are rendered into the DOM only when their containing menu section is opened for the first time, using a single Underscore.js template for all items.
See the make/core posts or the plugin code for more details.
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
#165
in reply to:
↑ 163
;
follow-up:
↓ 166
@
9 years ago
Replying to celloexpressions:
Menu Customizer should now be 100% scalable and is being proposed as a replacement for the current menus administration screen for WordPress 4.3.
Is there any way to port the fix back into wp-admin as well? Would be great to get this fixed in both places to make way for #18271.
#166
in reply to:
↑ 165
@
9 years ago
Replying to melchoyce:
Replying to celloexpressions:
Menu Customizer should now be 100% scalable and is being proposed as a replacement for the current menus administration screen for WordPress 4.3.
Is there any way to port the fix back into wp-admin as well? Would be great to get this fixed in both places to make way for #18271.
Unfortunately, no, it's deeply, deeply integrated with and dependent on the Customizer API and heavily JS-dependent (and unfortunately this screen needs to support no-js and will always have to be around for no-js users at least). That's not to say that it couldn't be done, but it would require building out a framework like the Customizer API and redoing all of the JS to be structured accordingly. There are much better things we should spend our time doing, like fixing #18271 and all the other issues blocked by this in the Customizer at least.
That would be to really fix the scaling problems to the extent that Menu Customizer does; there could be other solutions as I outlined in a comment here long ago. #28138 would be a good first step, and we're planning on fixing that in the Menu Customizer merge patch as it currently wraps the function to do that. But again, I don't think it's worth spending all of the time it would take to fix this issue, and if we did fix it here we'd want to do it right with a fully JS-driven solution. Which the Customizer lets us do.
This ticket was mentioned in Slack in #core by celloexpressions. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
9 years ago
#171
@
9 years ago
I'm told this is the correct thread to ask my question(s):
I have a Woo Commerce website with very large menu structure for the nav bar. Recently when I tried to add to the menu structure under appearances...Menu and press update the page...the page processes and then crashes and gives me a 404 page cannot be found error even though it is the same page.
My server provider informs me that the postmeta_wp table has 2 million rows.
I went to Woo Commerce…System Status…Tools and cleared the following:
WC Transients
Expired Transients
Customer Sessions
Still not resolved.
I have run 2 optimization plugins to no avail to clean out the 2 million rows.
I have added this line to php.ini, which resolved another menu problem, but it does not resolve this: max_input_vars = 3000
Question: Are there things we can do to the settings under PHP Configuration editor on the server or php.ini to resolve this?
#173
@
9 years ago
Since the decision was made (or, not really made either way) to not close this as fixed with menus in the customizer fixing this issue, I'd like to propose closing this as either maybelater or wontfix.
I don't see any interest in doing the work that would be required to fix this, and this is no longer critical to potential future menus roadmaps now that we have a more technically functional implementation in the customizer. That doesn't mean that this issue couldn't be addressed in the future, but I don't think it will be. By nature of the fix (making it more JS-oriented) we won't be able to fix it in the situations where the admin screen must continue to be used because the customizer can't be (JS).
#174
@
9 years ago
- Keywords close added
I was about to suggest that we close this ticket, and then I saw my comment doing just that from 3 months ago.
Reiterating my thoughts, a significant amount of work would be required to refactor the menus screen in the admin to be properly performant. This work has already been done in the context of the customizer, along with a UX redesign, taking thousands of hours and over a year of work. I haven't seen any interest in applying a similar effort here, but that could be done in the future if someone is compelled to do so.
The biggest issue that this fixes is unblocking things like the ability to add custom fields to nav menu items; however, that is already unblocked for the customizer UI and can be addressed in #18584 when those that need said hooks are able to provide input there.
#175
follow-up:
↓ 179
@
9 years ago
Reiterating my thoughts, a significant amount of work would be required to refactor the menus screen in the admin to be properly performant.
Does it have to be completely refactored to be "performant"? Knowing that the primary work is being done in the customizer, couldn't we aim for a patch that was more like "good enough" or "better than what we have"?
The biggest issue that this fixes is unblocking things like the ability to add custom fields to nav menu items; however, that is already unblocked for the customizer UI and can be addressed in #18584 when those that need said hooks are able to provide input there.
This isn't unblocked in the Customizer, unless I'm misinterpreting what you mean by unblocked. Currently the admin is the only way for users to add post meta to menu items via plugin. So my plugin's UI doesn't work at all in the Customizer. Myself and a few other plugin authors have taken to implementing our own common action hook as a work around for the lack of a core action hook, but users are still at risk for running into the $_POST limit described by this issue.
#176
@
9 years ago
This issue with menus getting cut off has plagued me for a long time now, but I just want to make sure I understand correctly: if I'm running WordPress version 4.4, then I'm all set, is that right? I won't have menus getting cut off any more?
In my opinion, since the Menu Customizer plug-in was merged into WordPress 4.3, this issue can be closed. I'm not sure that I understand why this bug is still open. Is it just for people who don't want to upgrade to WordPress 4.3 and later?
https://wordpress.org/plugins/menu-customizer/
EDIT: Disregard. I now see that the proper way to edit menus is NOT to use nav-menus.php, but instead to click the Manage in Customizer link.
Cheers,
Trevor Sullivan
http://trevorsullivan.net
#177
follow-up:
↓ 178
@
9 years ago
Trevor, if I understand it is only solved in the Customizer. If you edit and save your menu on the admin side you are still at risk of getting the menu cut off.
#178
in reply to:
↑ 177
@
9 years ago
Replying to helgatheviking:
Trevor, if I understand it is only solved in the Customizer. If you edit and save your menu on the admin side you are still at risk of getting the menu cut off.
Thanks, Viking. I totally missed the "Manage in Customizer" link at the top. This is a new feature to me, but VERY welcome.
Cheers,
Trevor Sullivan
#179
in reply to:
↑ 175
@
9 years ago
Replying to helgatheviking:
Does it have to be completely refactored to be "performant"? Knowing that the primary work is being done in the customizer, couldn't we aim for a patch that was more like "good enough" or "better than what we have"?
There are things that could make it better. And as someone who has never actually run into this bug myself, I could argue that it doesn't matter and we might as well go ahead with adding an action here and letting sites that do run into this issue deal with the consequences. But the bigger question is what percentage of sites have this issue - based on this ticket, it seems like quite a few.
This isn't unblocked in the Customizer, unless I'm misinterpreting what you mean by unblocked.
By "unblocked" I mean that there are no technical issues that need to be resolved before code adding support for custom fields in nav menu item controls in the Customizer can be implemented. As of right now, as soon as someone can come up with a working solution to add the customizer equivalent of a hook within a nav menu item control, that can be iterated on and committed to core. In the admin, we need to address these scaling problems before we can even get to the step of implementing hooks for plugin developers, hence the idea of hooks being blocked.
#180
in reply to:
↑ 110
@
9 years ago
- Keywords close removed
Replying to dd32:
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..
@celloexpressions, what do you think of this approach, or something not far off? This fix, although it sounds hacky, doesn't sound like a complete overhaul.
#181
@
9 years ago
Well, one of the issues is that we also need to maintain no-JS support on this screen. That could work if a no-js fallback was maintained, but like I said I don't personally have any interest in working on this, especially considering that this UI will probably be de-emphasized over time in favor of one that was built from the ground up to avoid have this issue. If someone is interested in picking it up, go for it.
#182
@
9 years ago
And as someone who has never actually run into this bug myself, I could argue that it doesn't matter and we might as well go ahead with adding an action here and letting sites that do run into this issue deal with the consequences. But the bigger question is what percentage of sites have this issue - based on this ticket, it seems like quite a few.
I would support that. In 5 years, I ran in to it once when a client was creating a monster, mega-menu for a fabrics store that listed every fabric color and material. But, I'm more concerned about this ticket because it has always been cited as the reason for *not* adding an admin hook for plugins to add custom meta data.
we also need to maintain no-JS support on this screen
I thought that JS was a requirement in the admin?
But, if we serialized the data into a JSON object, and added the action hook, then while perhaps not resolving the issue entirely, we're making it better for more people. The proposed change would reduce the issue to non-JS admins with huge menus, a seemingly much smaller demographic than is currently effected.
#183
@
9 years ago
In attachment:14134.diff, create a JSON representation of the edit menu form and shove it into an input variable. Expand it in the PHP form submission handler to avoid max_input_vars
.
Previously I was limited to a menu with 83 items. I'm now able to create a menu with 427 items, haven't found an upper limit here.
#184
@
9 years ago
Can anybody walk me through testing this diff? Or point me to the appropriate resource? I failed miserably at #WCUS to get VVV installed on my Win 10 machine, *but* I finally figured it out. (Hello enabling virtualization in the BIOS for anyone wondering).
#185
@
9 years ago
@helgatheviking We have some documentation on applying patches in the handbook, but if you have vvv you can use the grunt patch:14134
command. I'll message you in Slack to avoid adding noise to this conversation :)
#186
@
9 years ago
@ericlewis thanks for the help! I have tested 14134.diff.... I've added over 500 items in the menu (with my Nav Menu Roles plugin adding extra fields) and the menu items don't get cut off. Switching back to the unmodified files, the menu is cut off at 71 items.
I did find that the primary menu location gets deleted/unset. If the menu is set as the "primary" location:
on save, this box becomes unchecked. I have to click over to the "manage locations" tab in order to reset the menu locations. Actually it looks like this is the case using the attached diff or not, so it is probably not related to the diff at all.
#187
@
9 years ago
- Keywords dev-feedback added; needs-refresh removed
- Milestone changed from Future Release to 4.5
Moving this to 4.5 for consideration.
This ticket currently has needs-unit-tests
. I don't see a way to create unit tests for the approach we've taken. Testing it seems more like a functional test. Anyone else have a thought here?
This ticket was mentioned in Slack in #core by eric. View the logs.
9 years ago
#189
follow-up:
↓ 191
@
9 years ago
- Keywords needs-patch added; has-patch removed
Had a good chat with @chriscct7 about unit test approach here.
Let's try to unit test this by spoofing the HTML form submit request. We can set the number of menu items in relation to the max_input_vars
setting.
Also from @chriscct7:
is you might want to check json_last_error() or something after json decoding it. If you don't have an array you're iterating the for loop to back insert the data into $_POST on what could be NULL
so we should consider an updated patch with that in mind.
#190
@
9 years ago
In attachment:14134.2.diff, add a guard in case JSON decoding fails.
#191
in reply to:
↑ 189
@
9 years ago
Replying to ericlewis:
Let's try to unit test this
Is it possible to write a unit test that makes an HTTP request to WP? I can't find another unit test that does this, and it seems site_url is set to example.org
in the unit test suite config.
This unit test will take ~5 seconds because of the amount of stub data needed.
#192
@
9 years ago
I've run into this problem on a several sites over the years (thought I commented multiple times on this thread) but I gave up hope for a patch years ago though when core committers started saying "Use the customizer" and "wontfix" to the various tickets on this topic.
What I've been doing on sites with large menu systems is to split every top level menu item into it's own menu. That's crummy, but it's reliable and doesn't require hacking core on a production site and frankly works better for users than trying to navigate those same menus in the customizer.
FWIW, I tested the last patch, it works for me.
My hope has been that WP API V2 would bring a new foundation upon which a non-customizer fix to this could be built. There is a menus extension in testing for the API https://github.com/unfulvio/wp-api-menus but I haven't tried working with it yet myself.
This ticket was mentioned in Slack in #core by eric. View the logs.
9 years ago
#194
@
9 years ago
- Keywords has-patch added; needs-unit-tests dev-feedback needs-patch removed
- Owner set to ericlewis
- Status changed from reviewing to accepted
As I've understood from other developers, we can't create a bonafide HTTP POST form submission request to the nav menus save handler in a unit test. This blocks our ability to add unit test coverage here, so I'm going to remove needs-unit-tests
.
#197
@
9 years ago
Some thoughts about this approach:
- It should support other form fields too, like text fields or select boxes. Keep in mind that you can replace the default walker via
wp_edit_nav_menu_walker
. - While this seems a bit unlikely to me, but we have to make sure that we don't run into any issues with
post_max_size
. - The
nav-menus
script should get thejson2
dependency.
#198
follow-up:
↓ 200
@
9 years ago
- utilize
jQuery.serializeArray()
which will package form data into JSON in a linearly scalable manner. This ensures any form element that#update-nav-menu
contains will be slurped up (textareas and inputs) - move
$_POST
array path expansion into the PHP form submission handler. Could use a review here and if anybody knows a more declarative approach.
This ticket was mentioned in Slack in #core by eric. View the logs.
9 years ago
#200
in reply to:
↑ 198
@
9 years ago
Replying to ericlewis:
Great approach - smart! thanks for keeping on this when nearly everyone else had give up hope :)
#201
@
9 years ago
- fine-tune docs.
- Make
json2
a dependency of thenav-menu
script to polyfill JSON support in old clients.
#203
@
9 years ago
@ericlewis I noticed a regression introduced by [36510], namely where the Nav Menus admin page will drop any backslashes used on any input fields (e.g. menu name, item label, item description, etc). For example, try providing “\o/” for a nav menu item label. It will get saved as “o/”. The fix is simple (albeit tragic): it needs to re-slash the values being populated into $_POST
that are parsed out of the JSON. See 14134.re-slash.diff.
#205
follow-up:
↓ 206
@
9 years ago
So is this solution satisfactory enough to make it into an upcoming release? It would go a long way to unblocking https://core.trac.wordpress.org/ticket/18584
#206
in reply to:
↑ 205
@
9 years ago
- Keywords needs-testing has-patch removed
- Resolution set to fixed
- Status changed from accepted to closed
Replying to helgatheviking:
So is this solution satisfactory enough to make it into an upcoming release?
Yes, it is currently slated for 4.5. I'm going to close out this ticket as fixed. If any bugs come up, please report them here.
#207
@
9 years ago
I am currently running 4.5-beta2 and it seems the problem is still there, is that correct? In which build will this be fixed so I can test?
Thanks!
EDIT: Checked the files and it seems your sollutions was allready in this build. Also, I can constantly add menu items, this works ok, but my selection for the menu locations keeps de-selecting after a sertain amount.
#208
@
9 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
@ericlewis
I think I have found my problem and solution.
Changed code: starting from line 61 in wp-admin/nav-menus.php
<?php if ( preg_match( '#(.*)(?:\[(\w+)\])#', $post_input_data->name, $matches ) ) { if ( empty( $_POST[ $matches[1] ] ) ) { $_POST[ $matches[1] ] = array(); } if ( is_numeric( $matches[2] ) ) { $matches[2] = intval( $matches[2] ); } $_POST[ $matches[1] ][ $matches[2] ] = wp_slash( $post_input_data->value ); } else { $_POST[ $post_input_data->name ] = wp_slash( $post_input_data->value ); }
The menu locations are associative arrays and the preg_match you've made ( '#(.*)(?:\[(\d+)\])#' ) targeted only digits. Changed "d+" to "w+" to solve this.
After that, if $matched[2] is a numeric I've still made it an integer like before with (int).
With these changes both integers and strings can be used as array keys.
Can you please review this code? I really like to see this working 100% in the 4.5 release.
#211
@
9 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Re-closing as fixed.
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
andsuhosin.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."