Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
See: http://drupal.org/node/237585 for background.
That bug was fixed, but a nearly identical one has cropped up. I'm now experiencing the exact same issue in content.module and in the content permissions module, having removed and reinstalled a load of content types. The code highlighted by the error, when it occurs with either module, looks like this:
$type = content_types($node->type);
foreach ($type['fields'] as $field_name => $field) {
...
}
Comments
Comment #1
greg.harveyTo follow on, when the issue occurs it is because
$type
is an array of content types, not a single one, as usually expected, which tallies with Karen's explanation of what she did to fix the last issue. Seems the same problem occurs again in a subtly different way/place.Comment #2
greg.harveyFurther investigation reveals this is caused because somehow a node with no type or any other sort of data exists - the offending node object causing nodeapi to be invoked in the content permissions module looks like this:
So it's clear why the error is occurring. What's not clear is how this node came to exist. I'm not sure if you want to fix CCK so it handles this case, but I think CCK was also the cause, since it happened straight after uninstalling and reinstalling content. Whatever the cause though, this phantom node does not appear in admin/content/node, so I can't delete it that way. =(
Comment #3
greg.harveyDug deeper - the *real* issue seems to be the node no longer appears for deletion because the user was deleted! There is a join when loading nodes which causes node_load() to fail if the joined user is not available, from what I can tell.
So I leave it to you as to whether you want CCK to handle this possibility more elegantly. At the moment it just spits out a load of warnings. =(
Comment #4
yched CreditAttribution: yched commentedThks for investigating, Greg.
So far we intentionally left the code unshielded, precisely because it detects that some code somewhere (either in core or in 3rd party contrib) is doing something wrong. However, while CCK is not the source of the bug, those issues end up polluting the our issue queue, generating threads that quickly become flooded with unrelated 'me too's because such problems can come from many different sources. Enough with this.
I added code in the few places I could spot that could get broken to babysit invalid incoming data.
Comment #5
greg.harveyIndeed, my first thought was "hmmm, buggy CCK rc?" but further investigation revealed CCK was only the whistle blower! It would be *really* useful if CCK set a Drupal error or wrote to the watchdog saying something like "You may have orphan nodes - please check your node table." - but I understand that's well beyond what CCK should be doing.
Orrrr, maybe *I* should write a node_warning module that checks for orphaned content on cron and writes it to the watchdog?
There's an idea...
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.