in drupal 4.x, if you request a node id that does not exist (http://example.com/node/9999) you get a 404.
in drupal 5.1, you get the top level node/ page.
this is not a terrible thing if you've got content promoted to the front page. but if you *don't* have content posted to the front page (which is the case for me on a couple of sites) you get the welcome page.
the welcome page is not something that should ever be displayed on a production website. furthermore, pages that don't exist should return a 404.
this is especially true in the case the a custom 404 with helpful content (a site map, a contact form) is in place to help users out.
can we revert to the previous functionality, or add an option to disable the welcome page (returning a 404 instead) for production web sites?
it's possible that this bug is related to:
both of which complain about unexpected display of the welcome page.
there's a forum post on this topic as well:
http://drupal.org/node/129570
thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 130604.patch | 1.19 KB | firebus |
| #2 | welcome-setting.node_.module.patch | 1.18 KB | firebus |
Comments
Comment #1
RobRoy commentedDupe of http://drupal.org/node/82764.
Comment #2
firebus commentedi added a field in node_configure named node_welcome.
it's a radio button that defaults to "enabled".
i added logic in node_page_default to check this variable and call drupal_not_found if the welcome page is set to disabled.
Comment #3
firebus commentedsorry, i didn't reload before uploading my patch. i'll check the dupe and upload the patch there if it's helpful.
thanks for pointing me to the duplicate.
Comment #4
firebus commentedactually, this is not quite a dupe.
i've got production sites with nothing promoted to the front page (front page is set to a different node)
if you go to /node, you see the welcome page, which IMO should never be displayed on a production site.
that's not fixed by fixing the 404 behavior for /node/asfssfdsfafs.
renaming this bug and resetting patch status.
Comment #5
firebus commentedprevious patch was against HEAD this is against DRUPAL-5
Comment #6
drummThis new setting would not go into the stable Drupal 5.x.
Code style needs fixing, particularly the indentation. See http://drupal.org/coding-standards
This setting only applies to a small use case; is there any way it could be made automatic to avoid it?
Comment #7
firebus commentedyes. i've been thinking about this and the database settings security problem (if drupal has a database connection problem it displays private details like the database name and database username which is A Bad Thing)
it seems to me that both cases could use the existing error behavior setting (the exact name escapes me) and suppress this info if 'write errors to screen' is disabled.
if you think that's a good idea, i'll take another run at this. i have set up my editor correctly since i submitted this patch initially so i won't have indentation and other style issues anymore :)
does it make sense to only submit this to 6.x-dev, is there any sense in submitting to 5.x-dev?
is it possible to submit patches to two branches in the same issue or do i need a separate issue?
thanks for your comments!
Comment #8
drummThe general strategy is to get it into the development version, 6.x, and then to back port for the stable version, 5.x, if appropriate.
I do think this is good functionality, but have not reviewed your implementation.
Comment #9
dpearcefl commentedIs this even a valid issue any more?