$node not set in hook_node_api

subscribing

subscribing

subscribing because I got the same problem

upgraded from D5 > D6.16
6 times this error each time cron runs
3 languages

I can confirm this error. $node is not always set it seems?

Still applies in 6.13 and it doesn't happen only when cron runs, but also when using the Diff module to view changes between two revisions.

subscribe, although I don't believe I have more than 1 language.

Hmm... after some debugging I think I found the (or at least my) error. I enabled all my own modules and that solved the problem. So I re-enabled them one by one until I found the broken module.

After some testing, I discovered that I made two mistakes in my hook_view() function. First, I send $node by reference. This is not correct, it should be passed as normal object.

So instead of:
MYFUNCTION_view(&$node, $teaser = FALSE, $page = FALSE)
you should do:
MYFUNCTION_view($node, $teaser = FALSE, $page = FALSE)

Second, I forgot to return $node at the end of the function, because $node was passed by reference. The second mistake was the biggest problem, since this was the problem that $node is not an object (anymore) in i18ntaxonomy_nodeapi.

So PieterDC and joemurray, you might have a look at your own modules to see if you have related errors!

From the PHP manual:

5.3.0 This function doesn't work with objects anymore, property_exists() should be used in this case.

Is this the case? you guys using PHP 5.3.0?

I'm not, I'm using PHP 5.2.6
And, as far as I could check, no custom module with a hook_view implementation.

Could be something else, similar, though.

PHP 5.2.8

subscribing

I put some hacking debugging printing in and printed out a stack trace from this line on a cron run.

The module that was calling 'from above' in my case was the search module. I've found that the error goes away when I disable the search module.

When the search module is in place, the $node value is this:

&object(stdClass)#9 (4) {
["build_mode"]=>
int(2)
["body"]=>
NULL
["readmore"]=>
bool(false)
["content"]=>
array(4) {
["body"]=>
array(5) {
["#weight"]=>
int(0)
["#value"]=>
string(0) ""
["#title"]=>
NULL
["#description"]=>
NULL
["#printed"]=>
bool(true)
}
["#title"]=>
NULL
["#description"]=>
NULL
["#printed"]=>
bool(true)
}

The trouble seems to be that it's lacking a "taxonomy" array member.

Does this error go away when anyone else disables the search module? (sorry about this, but i18n is not enabled on my site!)

wow, thanks for this tip, i was wracking my brains disabling contrib modules left and right till i saw this post....sure enough after disabling the search module the errors went away....i sorta need search enabled though, is there a fix for this?

sorry if this is not appropriate to post here as i am not using i18n either, but was experiencing the same error and happened upon this thread after searching around a bit.

subscribing

warning: Invalid argument supplied for foreach() in .../modules/taxonomy/taxonomy.module on line 1226.

Same issue here. Subscribing.

Disabling search causes the error to go away here too so guessing it's the same thing, subscribing

Seems the cause to this error not the search, taxonomy or any other module, but orphan nodes, which for any reason are left without uid attributed to them. (I guess I deleted a user, who authored some nodes, directly on phpMyAdmin and not in Drupal user administration. That was how in my case orphan nodes appeared.) Solution is here:

1. Run this in MySQL:

SELECT uid FROM node WHERE uid NOT IN (SELECT DISTINCT uid FROM users);

2. Attribute all found orphan nodes to existing uid, delete them or add a user with uid gone into users table (in this case, first you have to turn AUTO_INCREMENT value of users table off and after adding a new user to turn it back on).

3. Repeat the same steps with node_revisions table to make user you don't have more orphans:

 SELECT nid FROM node WHERE nid NOT IN (SELECT DISTINCT nid FROM node_revisions)

@liocer: disabling (core) search fixed it, I think. I could only do this because I had ApacheSolr to cover the search functionality. But still, it's a workaround rather than a real solution.

@yngens:
1. no results
2. not needed
3. Resulted in as many node id's as the number of errors I got with every cron run. Deleted those nodes from the node table.

Thanks for your hints.

I've changed that code adding some checks. This should prevent the issue.