RC3.2 Menus still crippled
-
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?
-
What items are you putting in the menu?
Just pages or …what? I’ve seen issues where the tags menu item can do this.
I used to get an out of memory issue with menus. Could this relate to it? Have you tried it on a different host?
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?
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.
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.
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_timesetting 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.
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.
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.
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.
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 🙂
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.
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!
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.
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.
Thank you, and good luck.
- The topic ‘RC3.2 Menus still crippled’ is closed to new replies.