WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] [closed] RC3.2 Menus still crippled (28 posts)

  1. manicolaus
    Member
    Posted 2 years ago #

    Very disappointing that the long-standing bug that cripples the menu structure has not been fixed in RC3.2. When the number of nodes in the menu exceeds 24 or thereabouts, saving the menu structure starts to crash the server with "500" errors occasionally, and as the number of menu items increases, the crashes become more frequent. By the time you hit 40 menu items it crashes 90 per cent of the time, effectively crippling site development. This bug has been reported in the trac system for many months but apparently isn't considered important enough to fix. I guess people who want to develop larger and more complex sites than the average blog shouldn't be looking to do it in WordPress, or?

  2. What items are you putting in the menu?

    Just pages or ...what? I've seen issues where the tags menu item can do this.

  3. sareiodata
    Member
    Posted 2 years ago #

    I used to get an out of memory issue with menus. Could this relate to it? Have you tried it on a different host?

  4. Curtiss Grymala
    Member
    Posted 2 years ago #

    Have you tried this on only one server, or have you tried it in multiple, different environments? Have you tried this from multiple different computers? Have you tried different browsers? Is the result always the same? Have you filed a bug report, or at least searched to see if one already exists?

    When you say that it begins to crash around 24 items, are those all top-level menu items, or are some nested hierarchically? Does it make a difference if the structure of the menu changes?

  5. manicolaus
    Member
    Posted 2 years ago #

    Ipstenu: All of my menu items at this point are pages.

    Sareiodata: There are several threads on this forum and on trac from people having this issue on different ISPs. See below.

    Curtiss: I've had this issue on different shared servers on godaddy.com. I've tried all the various .htaccess fixes and php.ini switches that have been contributed on this forum as attempted solutions. It's not related to my computer platform. It occurs with Chrome, IE, FF. The result is 95% the same, but sometimes, exceptionally, unpredictably, a menu will save. I filed my first bug report over a year ago while developing with the then new twentyten theme. There are half a dozen other reports on this forum about it.

    Removing all plugins, every last one, and optimizing the database, makes no difference.

    The crash occurs regardless of whether the menu items are top level or nested. The key thing is the number of items. The crash can occur even when saving a menu structure that has not changed. It definitely occurs when there is any change in the menu, either addition or subtraction or change of position. Removing a large number of menu items restores the ability to save, although that may take several tries. I have also experienced a crash where half my menu disappeared.

    There is a bug report and extensive discussion in the trac system at
    http://core.trac.wordpress.org/ticket/14134 The development team is completely aware of the issue but apparently feels that the crippled menu functionality is adequate for the great majority of WordPress users, and that development of sites with larger and more complex menu structures is not a high enough priority for the WordPress platform.

    Necessity being the mother of invention, I have discovered some workarounds. The excellent Graphene theme allows two menus in the header and an apparently unlimited number of additional menus as widgets in the widget areas. Additional menus save OK if they remain small. By breaking out and widgetizing portions of the main menu, it's possible to put up an operational -- though not a convincingly professional -- site. Graphene also displays sub-page teasers in an array below a parent page, creating a kind of drop-down non-menu menu.

  6. I've had this issue on different shared servers on godaddy.com.

    In that case, I think it's actually pretty likely that the problem is your host. :/ GoDaddy is pretty notorious for overselling their shared hosting.

  7. Curtiss Grymala
    Member
    Posted 2 years ago #

    I was just able to successfully add 65 items to a menu on my WordPress site. When I tried to go to 70, I experienced a PHP script timeout error, but it seemed to successfully save the menu anyway. I got all the way up to 85 items on my menu (experiencing the timeout errors as mentioned above) before I decided to stop testing.

    I'm assuming, as one of the workarounds you discussed, you modified the max_execution_time setting in your php.ini (if you have the ability to do so on a GoDaddy server)?

    Out of curiosity, what is the reason that you're trying to use custom menus to organize such a large number of entries, rather than using one of the built-in functions to output menus or lists of pages? There is more than likely a much more elegant solution to the issue you're experiencing. Just as you probably wouldn't try to display 100 or more posts on a single page, you probably shouldn't use the custom menus to try to manage 100 or more navigation items.

  8. manicolaus
    Member
    Posted 2 years ago #

    The menu consists of pages grouped into several topic areas, similar to books or catalogs, each having a number of chapters and subchapters. Menus are simple, easy and familiar to the user, and they give an overview of the structure of the content. There are alternatives but they're not as good for my purpose.

    I realize that moving to a dedicated or "virtual dedicated" server could be a solution to what appears to be a memory and/or timeout issue (and yes, I've changed all the mem and time limits in php.ini) but that's at a considerably higher price point. The issue here is that a large complex menu structure runs fine on the shared server at my ISP in Drupal, where I built this same site originally (and would probably run as well in Joomla or DNN, but I haven't tried large menus in those platforms), but it doesn't run in WP. The WP programming team has known about this limitation for over a year -- see http://core.trac.wordpress.org/ticket/14134 -- but hasn't prioritized it. I and a number of other users who have bumped their head into the low menu ceiling would like to see the issue escalated and fixed in the next build.

  9. I realize that moving to a dedicated or "virtual dedicated" server could be a solution to what appears to be a memory and/or timeout issue (and yes, I've changed all the mem and time limits in php.ini) but that's at a considerably higher price point.

    We're suggesting you try a different shared host. I help out on other support forums and I have seen things like switching themes cause sites on godaddy shared accounts to timeout.

    Not all shared hosts are equal. Not all servers at one shared host is the same. That's the main reason it hasn't had attention. If you can replicate this issue on a different host, then it will get escalated.

    But if everything points to it only happening on godaddy, then it's an issue with them.

  10. manicolaus
    Member
    Posted 2 years ago #

    I guess I'm not making myself clear. "Everything" points to it NOT being a godaddy.com problem.

    (1) There are several other posts on this topic in this forum (different threads) of the same thing happening on different hosts.

    (2) The core.trac thread http://core.trac.wordpress.org/ticket/14134 shows that it's a recognized WordPress code problem.

    (3) Long complex menu structures run fine on the same godaddy.com shared account in other CMS platforms, e.g. Drupal 6.x.

    I've been with half a dozen different hosting companies over the years and frankly I like GD better than any of the others because they have an excellent dashboard interface, in a league by itself, and their tech support is fast, always there, and generally very knowledgeable.

  11. Comparing one function of one CMS to another is never an exact science (they work entirely differently). Let's leave that alone for now ;)

    (1) Yes some people have that problem, but more do not. Which is why it's complicated to resolve. In MANY cases it has turned out to be due to shared hosting (which is why I said it's LIKELY that it's GoDaddy). You can ask them, or look at the php error logs yourself, and see what's being recorded when you crash WP. If it's memory, then there you are. But without an ERROR message, we're guessing and using experience.

    (2) That trac ticket actually shows you exactly how frustrating the issue is. vdhamer got up to 90 (or 140) before having any issues. filosofo is working on a fix, but hasn't got one yet.

    We're not saying it's NOT a problem with WP, but we are saying that certain configurations of servers make it worse. Does that make sense?

    See if you can bump your memory allocation in PHP, it may help for the time being. By commenting in trac you did the right thing, thank you :)

  12. manicolaus
    Member
    Posted 2 years ago #

    To say that a code problem doesn't need to be addressed because it only happens on GoDaddy.com is like saying that a cell phone radio doesn't need to be upgraded because it only goes dead in the United States. GoDaddy probably hosts as many WordPress sites as the next five web hosts put together. GD has a very easy WP install and upgrade script and contributes tremendously to the popularity of the WP platform. No, I don't own any stock in GD (besides it's privately held) and I have a string of complaints about it -- including that they oversubscribe their shared servers -- but I'm a bit surprised by the readiness with which some of the commenters are prepared to flip off the WP users on GD. The fact that other CMSes are quite able to play on the field that GD offers suggests to me, at least, that there's room for improvement in the WP platform.

  13. No one said it didn't need to be addressed, manicolaus. In fact, no one said it's NOT being addressed. It's a problem, it shows up sometimes, and when it does, it shows up more often on some hosts than others. I got up to 100 menus before my site crapped out, and it was a busy site on a busy day.

    I'm a bit surprised by the readiness with which some of the commenters are prepared to flip off the WP users on GD

    There's a historical reason for it, sadly. The number of people (whom I trust in these things) that have had GOOD experiences with GoDaddy, I can count on one hand. And we're not flipping off the GD users (or at least I'm not), I'm telling you that GD is a prime example of a host where things go wrong more often than on other hosts.

    If you wanted me to pick on a host for arcane and inane mod_security rules, I'd pick my own. Drives me up the wall. Having weird issues with domain mapping/wildcard subdomains and you're using Plesk? Plesk is probably why. Can't make wildcard subdomains on GD? You need a dedicated IP for that.

    EVERY app and host has its quirks; GD's happens to be that they often oversell servers and run low on memory, which causes issues like you're seeing with more frequency than other hosts. We're keeping our experience in perspective. It looks like slagging, but it's not, and I'm sorry if you can't see it as otherwise.

    So. Back on TOPIC.

    1) Yes it's an issue, trac is flagged as major. We have a dev working on the patch. He's not done. Unless you've got the know-how, we kinda have to wait. Sucks, but we can't magically fix things.

    2) Many of us feel YOUR host is probably making it worse, based on what we've seen before.

    3) Thank you for adding your notes to Trac :) They really are appreciated!

  14. manicolaus
    Member
    Posted 2 years ago #

    Ip: Those are good points, and I don't mean to overheat the debate. It's perfectly clear that a shared hosting user like me is going to get a lower allotment of memory and time ticks, no matter what my php.ini file says, than the owner of a dedicated server. That's the reality for huge numbers of people on the web. The question is, what should software developers do about it? Should they write for the elite who can afford dedicated hardware, where memory allocation and timeouts are not an issue? Or would it be worthwhile to write for the average user who has to operate under the constraints of limited shared resources? On the whole, I think the WordPress developers have done a brilliant job of writing software that works under the real-life conditions prevalent today. That's a big reason why WP is so vastly popular. But with that popularity also come challenges. People start looking to WP not only for the basic blog and the basic website with its four basic menu items (Home, About Me, My Content, Contact Me) but for bigger and more complex projects. And at that point the code gets stretched and you begin to see cracks. That's what's happening here, and all I'm saying is that the time has come, please, to endow WordPress with a menu structure that's up to those challenges.

  15. Mark Jaquith
    WordPress Lead Dev
    Posted 2 years ago #

    manicolaus

    The WordPress core team is quite aware of this issue, and it is absolutely something that needs to be solved. It is an issue with how the menus are saved. Too much data is passed back. It takes a lot of memory and computation time, and many servers are configured to have limits on the number of vars you can POST in one request. Unfortunately, we just couldn't reach a consensus on the best way to solve it in time for WordPress 3.2. So for this release, it will have to remain a known issue that menu saving performance degrades or generates errors beyond a certain point (which may vary from server to server).

    The Trac ticket has been tagged as 3.3-early, which means we'll put it as high priority early in the 3.3 development cycle.

    I appreciate your feedback and for holding us to a high standard! This is how things get better.

  16. manicolaus
    Member
    Posted 2 years ago #

    Thank you, and good luck.

  17. Jen Mylo
    Key Master
    Posted 2 years ago #

    For the sake of 3.2 beta feedback tracking, marking this thread resolved, as Mark has made it clear it's being worked on for 3.3.

  18. Laxmidi
    Member
    Posted 2 years ago #

    Hi,

    I'm running into this bug as well. I've got a dedicated server with HostGator and I use WordPress 3.2.1. At a certain point after having added many menu items, I can't save the menu and I get a 500 Internal Server Error. I've tried switching themes and turning off all plugins. I contacted HostGator and they increased the PHP memory allocated to WordPress and increased the PHP time out limit. HostGator doesn't use suhosin. Unfortunately, nothing has worked. It's a complete nightmare. I don't know what to try next. I've been struggling with this issue for a week. Any suggestions or advice? Thank you.

  19. webgirlie
    Member
    Posted 2 years ago #

    One of my clients is moving their site to WordPress – about 200-300 pages (not posts) and I showed them how to use the new custom Appearance/Menu.

    Once they’d added 100 pages, the Menu refused to ‘save’ and they kept losing work.

    They contacted their hosting company Hostgator who did all kinds of tests, were extremely helpful, and discovered that the Custom Menu Save script takes way too long because of the number of pages they’ve added, and is then ‘killed’ by the hosting company script which stops this kind of high bandwidth.

    My client’s been advised they need to move their site to VPS (Virtual Private Server) at an additional cost of about $1 per day (so approx $40/month), which is quite a shock to them and to me.

    I'm interested that others have found other solutions e.g. the Graphene them, so I'm going to mention this to my client today. Perhaps there's a plugin which will make it easy to make sidebar menus, and just leave the top-level names in the Custom Menu. If I work this out, I'll post back here. Thanks.

  20. esmi
    Theme Diva & Forum Moderator
    Posted 2 years ago #

    Known issue: http://core.trac.wordpress.org/ticket/14134

    Although how anyone could think that a 100+ item menu is usable is beyond me.

  21. webgirlie
    Member
    Posted 2 years ago #

    Hi Esmi,

    These are not top level menu items.

    I'm talking about Pages using categories and sub-categories like the majority of websites. Perhaps you can help, as a Theme Diva?

    I believe we can put all the top level pages in the new Custom Menu, and would then list sub-category pages available by seeing the list for that one category in the sidebar (widget?). (as mentioned above for the Graphene theme)

    Would you be so kind as to share any suggestion for a solution like this? Plugins? How to create the menu 'group' of pages for each category?

    Many thanks in advance

  22. I'd not use the WP menu system for this, and instead use wp_list_pages

    http://codex.wordpress.org/Function_Reference/wp_list_pages

    But as Esmi said, it's a known issue, people are working on it.

  23. webgirlie
    Member
    Posted 2 years ago #

    Many thanks Ipstenu for your quick response, much appreciated. It's terrific to receive assistance from those with much more WP experience.

  24. msaizan
    Member
    Posted 2 years ago #

    I am in process of building a rather complex regional portal on WordPress multi-site 3.2.1 - There are 16 metropolitan statistical areas in the geographic region - and each msa has a newswire (is a news aggregator) I need a complex sub menu (horizontal menu) for the newswires- 3 Top level menu items : 1. A-Z clickable list of all the city newswires in each msa, 2. organized by geographic/urban areas 3. List of news sources - Underneath the three top levels there are about 40 nested items a piece two/three levels deep... All the nodes, top level, children and grandchildren are category pages. As far as why I would want to handle the navigation this way...the menu as built really works visually, organizationally and functionally - but alas seems wordpress isn't currently up for the task? My menu just crashed at about 70 items -prior to the crash I was timing out on every save...getting lots of 404's, rolling 500 internal server errors... finally...half the menu items just went poof - totally disappeared - this issue is putting stress on my server and rendering the whole site unstable. I am very disappointed - not just about this particular menu challenge, but I too want to think that WordPress can be a platform for the complex site developer. FYI, I am hosted by Hostgator and I am on a VPS - level 5 ( rather generous amount of resources) ...consulted with Hostgator - At their suggestion, I have increased my memory/time limits in my php.ini file - but I am not confident yet that this will do it for what I am trying to create here. And my advisor at Hostgator didn't feel confident that a move to a dedicated server would accommodate. So Yes, I do hope the team will make this fix a priority.

  25. msaizan
    Member
    Posted 2 years ago #

    thought: I think I would like to have the menu items save in a similar way as the widgets - one by one - instead of rolling the whole page. that's it. over and out.

  26. msaizan
    Member
    Posted 2 years ago #

    This menu issue has turned into a nightmare. The memory and time output increases didn't do the trick. In fact, I can no longer create a working menu at all - the situation is so unpredictable that the menu crashes sometimes after as little as three nodes have been added - and my host is fresh out of ideas. I am having to hire a programmer to see if we can't figure out a patch or work around - and if not - I will have have to abandon six months of work and rebuild the site on another platform. very distraught.

  27. webgirlie
    Member
    Posted 2 years ago #

    Hi msaizan, Sorry you're still experiencing problems.

    Evidently the Menu feature isn't meant to be used for massive amounts of pages, but is excellent for Categories or for sections on a website.

    My client's travel website is now working properly with the menus - here's what we did:

    Changed Theme:

    - now using Graphene which provides multi-level control for pages being listed in widgets in the sidebar. Thanks to manicolaus for this tip:
    "Necessity being the mother of invention, I have discovered some workarounds. The excellent Graphene theme allows two menus in the header and an apparently unlimited number of additional menus as widgets in the widget areas. Additional menus save OK if they remain small. By breaking out and widgetizing portions of the main menu, it's possible to put up an operational -- though not a convincingly professional -- site. Graphene also displays sub-page teasers in an array below a parent page, creating a kind of drop-down non-menu menu"

    In Appearance/Menus:

    - we trimmed down the number of pages which appeared in the Main Menu (to Countries and top level Cities)
    - originally all countries AND sub-pages were being displayed in the main menu, but that kept 'breaking' WP.

    Plugin:

    - added "CMS Tree Page View" to easily manage a couple of hundred pages and keep them in order
    - once installed this plugin appears under the "Pages" menu in left sidebar.

    So far so good. I do hope there is no need to abandon 6 months of work or move to another platform, there are some excellent work-arounds mentioned here and other WP places on the internet. I have my fingers' crossed you find a solution like we did.

    Best of luck!

  28. wlindley
    Member
    Posted 2 years ago #

    The "Menus" system is rather broken, in that you have to manually add each page; and if you change the page order on the page's admin screen, that has no effect on a "Menu".

    I tend to use two plugins: AutoNav, and Hierarchical Pages which together give a graphical navigation system; and a widget that lists pages "above and below" the current page. That way, WordPress's built-in page handling is respected, without the user having to see hundreds of pages in the sidebar.

    Fisher Shotcrete is the classical example of a WordPress site done this way.

Topic Closed

This topic has been closed to new replies.

About this Topic