Error: Invalid argument supplied for foreach() .... taxonomy.module on line 1242

same here, but not related to cron
Appears randomly when viewing my frontpage

Same problem here. Appears randomly on various pages.

Ditto. This started appearing when I upgraded core to 6.17.

Poormanscon simply invokes cron, it doesn't do anything specific with taxonomy.module, so your questions are better off in the general Drupal core support queue. Please search around though. I'm very sure there are some issues already about this error message.

Subscribing

sub

Search brings you this: http://drupal.org/node/842044

Does this help?

That makes sense.

I have the same problem with the new Drupal release!

I have been trying to figure this one out. I am assuming this is the same problem, though mine appears on line 1242. I tried debugging with the linked module above, but no errors were discovered that way. This came about with the update to the newest version.

A possible easy solution is there:
http://drupal.org/node/842044
(#7)

I cannot find a solution at http://drupal.org/node/842044. There is only posted a helper module "node_debug_info.module" which may help to identify taxonomy related problems in the database. I ran it but it didn't report any problems. When running cron, though I still get the error message.

Same here. Ran the module and no errors. Are there any modules to "clean" up tables?

I had the same problem someday after using cron job.
The solution for me took a long time but it was very simple!
I had a nice try & error with my database.
Finally I found out, that there was only one node, that confused the search index routine while doing the cron job.

I found a node in my db (node table) that had an uid of 0 (zero).
Never know how it came there in, but erased it and build a new search index via cron.

No more error messages. huh!

Fertig! Done!

ANSWER PLEASE
i install Drupal nearly (lesser than 1 month) and i destroyed by this problem
some of modules not work properly and i dont know that they have Relevancy with this problem or not
i waited and waited but no answer
i check my site with http://drupal.org/node/842044 and no problem

Folks,

there is nothing that can be done for you in this issue. All you can and have to do is work through the thread linked in #7. Additionally look for similar problems as stated in #15.

This is something that only can be solved by yourselves and NOT within this issue. Sorry.

I SAY THAT "i check my site with http://drupal.org/node/842044 and no problem"
i install the node/842044 modules and my site is clear

node/842044 ANSWER :
"The following is a report that queries various tables: node, node_revisions, term_data, term_node, users and vocabulary. This report does not offer "solutions"; it just provides results that you need to interpret. Most of these can be resolved by modifying rows within specific tables. This report does not tell you which rows within the tables to modify.
No errors were found using this script, but that doesn't mean there are some."

WHY THIS HAPPENED ?
HOW WE CAN REPAIR IT ?
ANY BOOK OR ARTICLE NOT EXIST ABOUT THAT ?
I INSTALLED FOR LESSER THAN 1 MONTH AND WORKED ON THIS SITE MORE Than 300 hours
i changed my site from cpanel to directadmin may be this problem have Relevancy with this matter ?

This problem come from feeds modules
http://stream.zerolab.org/post/2419224606/invalid-argument-supplied-for-...
helped me to find that
please add this patch to drupal core

function _node_index_node($node) {
+ $nid = $node->nid;

$node = node_load($node->nid);

+ if (!isset($node->nid)) {
+ watchdog('debug', 'Problem node: '.$nid);
+ }

subscribe

Thanks, this helped me to solve my issue.

May be worth to mention that
- the patch applies to node.module in the module/node core directory
- it generates a meaningful "debug" log that identifies the faulty node.
- then, go the the node table and delete the row (also check other tables if this node is referenced elsewere)

At our site this started approx. a week ago, when I made some routine updates to modules.

For some reason, don't know why, (and unfortunately cannot trace it,) 6 nodes were marked as posted by user 0. Of course, there is no such user, and those 6 nodes were actually posted by myself, as main administrator (user 1). The nodes in question were created in September 2009, and had not caused any problems until the updates I made this spring.

Our software developers that fortunately are very experienced with databases, did a search in database (looking for "uid" having value 0), and found these ghostly nodes. After that the uids of these nodes were changed back to 1, and we no longer get the "Invalid argument supplied for foreach()...taxonomy.module on line 1242" when running cron manually.

If anyone ever finds a reason why this had happened in the first place, I'd be interested to know.

Thanks & regards,
MerjaS

I have run into this issue as well on 6.22. Finding nodes with uid = 0 is more likely a symptom than a cause. I think the issue is more likely a problem with the core node module not properly loading the node object, possibly due to some inconsistency with the node module's tables. I was able to find the offending node by entering the following code into taxonomy.module at line 1241, then running cron.

If you're going to try this, please back your stuff up and/or try it on a development server first.

if (!is_array($node->taxonomy)) {
  debug_print_backtrace();
  exit;
}

This will show you all functions called on the way to where the error took place. You will be able to identify the node by its nid in one of the previous function calls, then remove its record from the node table. You may have to repeat this process several times if there are multiple nodes with problems.

Revert your edits when you've found all of the offending nodes.

In my case the data was created by a 1-time import through Feeds from a CSV into content types set up via CCK. Navigating to mysite.com/node/123 brought up a 404 and it's likely that the node never really worked in the site.

We are circling around this issue, but I dont thing there is a good fix -- all I see is debug methods.

Quitting cron (exit if node->nid fails) is not a good option, unless you are happy with ghost nodes in your system, besides, you are hacking core in a silly way.

I think the issue has to do with the user that owns the "bad" node, as many suggested with user 0 (anonymous). Yes - placing the debug as #19 says, you can trace the offending node - see the "reports/recent log entries", then you can remove the node or fix it and and then the nodes can be reindexed (and hence, visible).

But what if all your nodes (thousands) have the same problem? You think Im going to go in the backend tables and change the UID or delete them all? no, we need an actual fix.

I do not have the foggiest idea of where the problem is in the code, but I know a fix in the case you are importing nodes using feeds:

I imported a "feed importer" via "features" in a staging server. The feed that was configured in other drupal instance, a sandbox, was set to set the node owner to a particular user that was not a user in the stage server. I ingested a load of nodes using the feed, it all looked fine. However, the nodes were invisible at node/content/list. After looking at the feed settings, I saw that the imported nodes would be owned by Anonymous --Im guessing the system reverted the user that was set to anonymous (0?). Then mayhem ensued.

I bet that last paragraph sounded cryptic. So here is the skinny: Make sure your feed's processor settings "Author" field is set to some real user in your Drupal instance. Next import badge will come in just fine.

Now, this post probably belongs also to the feeds issue queue, but Im not sure how to cross-post, etc.
Apologies,
Inigo

debug backtracing as done in #23 helped me track down my problem.

A lot of people here are complaining that debugging methods are the only fixes offered. Unfortunately, the reality is that this error is a symptom caused by any large number of issues. So debugging is the only thing you can really do because the cause of your symptom is probably not the same as it was for others.

For many individuals, it's a problem with the UID column of several node tables, but for me, it was a problem with the Fuzzysearch module ( see http://drupal.org/node/1369956 )

The debugging methods offered here are great and many thanks to those who contributed.

My "Invalid argument ... taxonomy.module" error was triggered by bad nodes.

They had language "en", even though there are no language modules installed.
I deleted them, but they still showed up in Content Manager, though node page said content not available.
I removed the rows from the "node" table in the database -- solved.