Drupal 6: Anonymously created nodes result in 404

Nodes of this certain types can be created by an开发者_StackOverflow中文版onymous or registered users. If a registered user creates it, everything works fine. If an anon creates it, going to that node's page results in a 404 error.

The node clearly exists, however. If I edit its entry in the node table and set its uid to be something other than 0, everything works fine.

Why is this?

This rule holds throughout all node types, CCK generated and otherwise. If I set uid = 0, it breaks. If I set uid = 2 (or any other number not 0), it works fine.

debug_print_backtrace() results in this:

#0 drupal_not_found() called at [/home/sitename/public_html/sitename2/index.php:24]

I got the exact same error:

user uid = 0 was missing from the users table

the error was happening inside the node.module node_load() function, as you have a join query between node and users table

It also appears that if user 0 (anonymous) had previously created a node of a certain content type, and later the permissions for that content type were limited to a logged-in user, then Drupal may not recognize the node. This will also cause a 404 error.

Upon first glance, it seemed that Drupal simply wasn't picking up or indexing the nodes... that they were simply gone. However, when looking at the database, the nodes were indeed there.

In my case, user 0 existed in the user table, but the offending nodes had an user id of 0. Using phpMyAdmin, I manually changed the uid to a valid user (other than 0), and Drupal recognized the nodes once again.

I second googletorps assumption that this is most likely caused by some custom/contributed module.

You could pinpoint the offending code by temporarily putting $backtrace = debug_backtrace() at the top of the drupal_not_found() function in common.inc and inspect the result using a debugger. (Alternatively, you could use debug_print_backtrace() to simply print the trace instead of the Drupal 404 page.)

The trace will list the function calls (along with their arguments) that lead to the call of drupal_not_found().

Edit after question update (404 issued in index.php):

This is pretty weird/irritating, as it means that menu_execute_active_handler() could not determine a matching drupal menu/path entry (by calling menu_get_item() in turn). The path/menu determination logic should not depend on the node author at all (except maybe concerning access rights, but that should only lead to a 403, not 404).

So I have absolutely no idea on what might cause this :/

Have you tried turning off the contributed modules to see if this changes the behavior and maybe pinpoint an offender?

This is a few months old, so I'm sure you've figured something out by now. But, since I just came across the same problem, I'm posting this for the next person that comes looking for an answer:

Check that the users table has an entry for the anonymous user - that is, where the uid field is 0.

When loading a node to display, the node_load() function uses an INNER JOIN to join the node table to the users table. If node.uid is 0 and there is no matching user record with uid = 0, it returns an empty set.

I think I messed mine up when copying the DB from one server to another. I wasn't able to replicate it just now, but I know I've seen issues before where MySQL doesn't take kindly to a 0 in an auto_increment field. In this case, my anonymous user record was uid = 5, so I just changed it back to 0 and all was right with the world.