Apparently someone decided to "improve" my site's performance under 5.x, without asking me if I liked the idea. When a "page not found" (404) occurs, the menu is not shown, so users can be lost and not realize how to get back into my site (yes, this has happened), and not just to me: http://drupal.org/node/140452

Someone suggested a simple hack to common.inc, but it seems to me that it would be better to rectify the whole "you didn't ask me" question. This patch adds two check boxes to the error-reporting settings page (system.module) to indicate whether the blocks should be shown. Then it modifies common.inc to check those values when displaying the error pages.

I have looked over the much larger patch to this area (http://drupal.org/node/77514), and I think this would be a valuable addition to that if someone wants to merge it.

Files: 
CommentFileSizeAuthor
#28 141162.patch4.3 KBNancyDru
patch_403_404.txt2.6 KBNancyDru

Comments

Morbus Iff’s picture

Status:Needs review» Closed (works as designed)

Nancyw: the proper way to do this, without adding yet more configuration variables, is to create a new node, fill it with whatever "page isn't found!" content you want (which could be nothing at all, of course), then set the "Default 404 (not found) page" (in admin/settings/error-reporting) to that node. This is actually a lot more powerful than what you propose because, as a site creator, you can customize the message and/or include links to the latest features of your site (more entrypoints to shepard the lost sheep home).

Setting to "by design".

Morbus Iff’s picture

Incidentally, this would be a great tip for your cookbook.

NancyDru’s picture

Status:Closed (works as designed)» Active

I have custom 404 and 403 pages, and my cookbook tells people to make them right off the bat. The problem is that a page not found suppresses the menus, making it disorienting for users to get back into the site. Note, the 404 is the only one where this decision was made by some unknown person without asking me. I much prefer having the menus show up, but I can see where some people might not. Hence this patch, which I firmly believe is needed. If not stand alone then rolled into that other proposed solution.

Michelle’s picture

+1 from me. This is one feature of 5.x that I really hate. I had intended to make a custom 404 page to take care of the problem and now it sounds like that won't do it? If that's the case, then we definitely need an option here. Losing all navigation when you hit a bad page is no good at all.

Michelle

NancyDru’s picture

Michelle, I would still encourage you to create both a 404 and a 403 page.

Crell’s picture

Is this something that could be handled by or in the customerror module?

NancyDru’s picture

Myabe, but the main issue is that the 404 routine deliberately turns off menus and blocks in the display (see the 5.0 changelog - it was a conscious, albeit is dumb) decision).

Morbus Iff’s picture

Nancyw: you really need to stop taking this change as a personal affront to your needs. Is it far-fetched to presume that you have never personally run a site that gets more than a million hits a day, and where fully processed 404s cause a huge hit in performance at the database and processing level? This IS NOT TO SAY that your concerns are not accurate: I /heartily agree that having entrypoints to your site on a 404 page is important/. However, you're just spouting that the recent change is dumb, dumb, dumb without much thought as to why this has occurred. And, if you notice my comment on the other issue, you'll note that I support this feature if that one goes in. I'd spend more of your effort over on that issue, in a positive manner, as opposed to "dumb, dumb, dumb"ing everything.

Morbus Iff’s picture

Crell - I don't think customerror would help. It appears to still depend on drupal_not_found().

NancyDru’s picture

No, I don't get anywhere near that kind of traffic, which is why I'm not happy with this decision. I estimate that the total impact to my site is on the order of one second of MySql time. That's why the change that was made to 5.x makes no sense to my sites. Clearly the performance impact is insignificant compared to the impact on my users. I would be happy keeping the change as a hack on my sites, but was trying to do this right and make it more applicable to the community as a whole - and to discourage hacks.

My last post was the only one that I can recall using the word "dumb" - and only once. I was much more affronted by the way this was off-handedly dismissed without understanding the issue.

And, no I haven't read what you put on the other post because, for whatever reason, it has not appeared on my recent posts list, but I will go look now.

forngren’s picture

Version:5.1» 5.x-dev

+1 from me. This has been bugging me to. I think it would be preffered to keep this in a separate patch though. The other patch is far to large for it's own good and needs to be split up.

Morbus Iff’s picture

nancyw: use of "improve" in quotes, "without asking me if I liked the idea", "you didn't ask me question", "made by some unknown person without asking me", are all indications that the Drupal planet rotates around your sun, which is incredibly far from the truth, and are all negative and passive aggressive comments that I helpfully rolled into the "dumb" collective. And, no, I don't think the Drupal planet revolves around me either ;)

Could you do me a favor and send me, via email, a list of last week's 404s as reported by your web site's log analysis program? After checking three or four different sites that I have access to, I found that about 80% of the 404s were caused by search engine robots or crawlers, idiotic browsers (requests for favicon.ico time and time again), worms (requests for formmail.cgi, various Frontpage or IIS signatures, known security holes, etc.), or user error (the inability of a web master to never allow linkrot to happen in the first place) - ie., 80% of the time, a 404 error is given to a non-human. Even on a lowly trafficked website, I guarantee that (for example, on one of my smaller sites) 1215 favicon.icos (browser error), 335 images/pixel.gifs (site design errors), and 186 db/zone.htmls (no idea what that is, but has never existed on my site) definitely equate to more than 1 second of savings.

Michelle’s picture

Thanks for clarifying why this was done. I didn't like the feature but didn't know the reasoning behind it. Now that you've explained, that makes sense. I think I'll look into putting some sort of navigation into the custom error pages so I don't leave real users stranded.

Thanks,

Michelle

NancyDru’s picture

I agree with putting a real custom error page in the site, if for no other reason than to maintain the look and feel of the site. However, menus and blocks are part of the look, aren't they?

In my case, the 404's (from whatever cause) are occurring, on average, 5 times a day. Is it really necessary to worry about my CPU and bandwidth? I don't think so. I am much more concerned that the real user feel like he/she is still on my site and be able to easily return to using it, even if that only occurs twice a week.

Michelle’s picture

That's true. Maybe a compromise would be to select which blocks appear? Along the lines of throttle... If you have blocks of images, for example, you may not want them coming up every time a search engine hits a bad page. But you'd want things like your navigation menu just in case it's a real person.

Michelle

NancyDru’s picture

I would think that would be easy with the visibility settings.

njwood60’s picture

I think the "visibilty" setting is a great idea, and have just implemented it for my 404 page where (after enabling block display via Nancy's patch) I hide all blocks except a custom one with minimal menu options to get the user back to the home page (and also to preserve my page layout). (www.cerocaustralia.com.au/champs if you want to see)
As I'm not very familiar with the code, it would be interesting to know if setting "visible" to off for most of the blocks does reduce the server load and bandwidth - ie where does the actual "visibilty processing" occur
Thanks everyone for your help

bradlis7’s picture

Version:5.x-dev» 7.x-dev

As comment #15 seems to suggest, a good solution would be to roll back the feature, and let the throttle module be in charge of hiding the menus during high traffic times.

greg.harvey’s picture

Nice patch, thanks Nancy!

@ Morbus Iff: making the 404 page useless is *not* a smart way to handle millions of hits. I can only presume you don't have this problem yourself, or rather than muttering about fully rendered 404 pages you'd be looking in to serious caching solutions like we use.

With our Query Cache module you could just place the whole 404 page on a memcache server, tell it to update itself once a day and forget about it. If I don't want blocks on *my* 404 page, that's *my* choice. Can't imagine why anyone would think it is a good idea to disable this in the core.

Do you also go around people's houses when you're at parties putting corks on all the knives, just in case someone cuts themselves?? ;-)

wmostrey’s picture

This issue is handled in great extent in Display blocks on error pages with a core-free fix at comment #27 by chx. This issue should probably be marked as a duplicate for that one.

johnmcgeechan’s picture

Would have to agree with wmostrey on this one.

This is also a general rule, for theming changes that you don't like in the core, simply overide the function within template.php and absoloutely never,never hack core code.

Also Nancy, I originally found the removal of blocks irksome as you did as it too removed navigation from my error page, but after reading the explanation why I think this is completely reasonable. As the solution to the problem is so simple I really can't see what the complaining is all about, with the potential devastating overheads it seems more than reasonable to have the default processing to not process the blocks.

I do have one slight issue though. I would be nice to have had the option to create a completely seperate 404 page (which yes I know I could do via apache) than to have to either do the change as listed above or to have a 404 sans navigation. The reason being that I would simply create an error page as a normal page and then cut and pasted the html it produced into my bespoke 404 page.

Crell’s picture

Many many designs break without blocks. The login box is also a block, so you can't log in nicely on such a page if they're disabled. With block caching, the performance hit is not as bad as it used to be. A theme-level option to toggle blocks on 403 and 404 pages (independently of each other, too) makes the most sense, IMO.

Michelle’s picture

@Crell - I like that idea. I have low traffic sites and I would much rather have error pages with navigation on them even if it's mostly bots. When I goof up and hit one on my own site it annoys me to have no easy way to just click on the menu. If it annoys me, I can only imagine how the users feel.

Michelle

drewish’s picture

subscribing... i'm totally in favor of making this an option that's off by default with a warning that it has performance implications.

TfR75’s picture

subscribing. this would be a useful feature

bmherold’s picture

Can we get this into drupal5 as well? This seems like a complete oversight =/

NancyDru’s picture

Status:Active» Needs review

@bmherold: we'll be lucky to get it into D7. It is highly unlikely you will see it in 5 or 6.

NancyDru’s picture

Assigned:Unassigned» NancyDru
StatusFileSize
new4.3 KB

Patch updated for 7.x-dev

catch’s picture

Status:Needs review» Closed (duplicate)

This is a duplicate of #116895: Show regions at 404 page.

Alan D.’s picture

I've posted a solution for a non-core hack for Drupal 6 here,

http://drupal.org/node/129762#comment-1013470