When trying to view/edit nodes of Content Type X, drupal returns a 404 - Not Found. All other content on the site (content of other node types) seems unaffected.

To eliminate other issues with clean URLs, path or path auto, I'm using the q param to access the nodes (example.com?q=node/123, example.com?q=node/123/edit), so it's not something silly like that (not likely anyway since all of the other site content renders fine at the expected URLS).

To be clear, drupal seems completely unaware of these nodes. Filtering by this content type on the admin/content/node page returns "No posts available". However, I happen to have a Views Bulk Operation view that modifies a CCK field for these nodes and that page does show all of them with the proper titles and everything. Trying to modify that CCK field with the VBO has no effect though (the field is not updated).

What I was doing before this happened:
I recently installed a new theme. Unfortunately, I can't confirm or deny that this started happening as a direct result of the theme. I would expect any error caused by this to result in 500 errors anyway. Or possibly 403 errors because I do use drupal_access_denied() in some custom modules - but not drupal_not_found().

What I have looked into while troubleshooting:

  • The node table looks fine. The rows referring to these nodes remain and appear unchanged.
  • All of the CCK tables (content_type_x, content_node_field, content_field_abc, etc) look fine.
  • The menu_router table rows for node/%, and node/%/edit are fine (but like I said, this is just one content type and I would think that something wrong with those rows would break all content types). (All of these database checks seem unlikely anyway since I haven't touched the DB directly or modified much of anything recently.)
  • I have rebuilt the permissions on site content (/admin/content/node-settings/rebuild).
  • The watchdog table records the 404, but nothing else.
  • The Status Report page is all green.

I realize that this is a pretty esoteric question, but I'm hoping something in the above rings a bell with someone.

This site is (still) running on Drupal 6.

  • What user roles are getting the 404? Does the superadmin (uid==1)?
    – mpdonadio
    Oct 31, 2013 at 17:52
  • Yeah. User1 (and everyone else). Oct 31, 2013 at 17:52
  • If you switch to Garland, do you have the problem?
    – mpdonadio
    Oct 31, 2013 at 19:29
  • Don't know why I didn't try that before, but yes, the problem still exists with Garland. Oct 31, 2013 at 19:40
  • do you have custom display or template for the content type? Nov 1, 2013 at 1:46

1 Answer 1


The author of the nodes in question (just happened to be the same author for all of the nodes in this content type) was missing from the user table. To be clear, the user was not properly deleted - the row was simply removed from the database.

I'm guessing that this caused the db_fetch_object() function to fail within node_load() when it tried to JOIN the user table on the nonexistant uid:

$node = db_fetch_object(db_query('SELECT ' . $fields . ' FROM {node} n INNER JOIN {users} u ON u.uid = n.uid INNER JOIN {node_revisions} r ON r.vid = n.vid WHERE ' . $cond, $arguments));

But it failed completely silently - I that's guess because this scenario would never happen if the user had been deleted properly (Drupal 6 automatically sets the Author of all content created by a deleted user to Anonymous (uid == 0).

Lot's of red herrings while troubleshooting, but maybe this will help someone in the future that doesn't realize they're using a half-sanitized database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.