Invalid argument supplied to foreach() in taxonomy.module (line 1189) due to incomplete/partially-deleted nodes

That's clearly an issue with one of the module, probably messing up the node object, probably during the hook_nodeapi($op = 'update index') stage. Could you list all modules in your installation that implements hook_nodeapi()?

One easy way to do it is to dump that code in a new content (Input format = PHP):

print "Modules implementing hook_nodeapi: " . implode(" ", module_implements('nodeapi'));

Anybody resolve this issue?

I had the same error messages, but my appear when a user performs a "Search". I disabled CCK and it got rid of the CCK messages but the taxonomy one remains.

If it helps, my installation details are below:

Drupal 6.4
Includes: Aggregator, Block, Color, Comment, Contact, Database logging, Filter, Forum, Garland, Help, Menu, Node, Path, Poll, Profile, Search, Statistics, System, Taxonomy, Tracker, Trigger, Update status, Upload, User
Modules
Up to dateok
Advanced help 6.x-1.0
Includes: Advanced help, Advanced help example
Up to dateok
Image 6.x-1.0-alpha3
Includes: Image, Image Attach, Image Gallery
Up to dateok
Simplenews 6.x-1.0-beta5
Includes: Simplenews, Simplenews action
Up to dateok
Theme Settings API 6.x-1.4
Includes: Theme Settings API
Up to dateok
Views 6.x-2.0-rc3
Includes: Views, Views UI, Views exporter
Themes
Up to dateok
Pixture 6.x-1.1
Includes: Pixture

Drupal 6.4
Access to update.php Protected
Configuration file Protected
Cron maintenance tasks Last run 35 min 33 sec ago
You can run cron manually.
Database updates Up to date
Drupal core update status Up to date
File system Writable (public download method)
GD library bundled (2.0.34 compatible)
Image gallery Galleries defined
Image module directories Exists (sites/default/files/images)
Image toolkit The gd toolkit is installed
Module and theme update status Up to date
MySQL database 5.0.27
PHP 5.2.6
PHP memory limit 32M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Web server Apache/2.0.52 (Red Hat)

This is beyond my debugging skills but if there's something anyone would like me to check and post it back here, I'd be happy to do so.

I recently updated from D6.7 to 6.9, and since then I've been getting lots of these:

warning: Invalid argument supplied for foreach() in /home/.otis/ivan/r.cfp/modules/taxonomy/taxonomy.module on line 1189.

I think it's probably the same issue as above, which is why I decided to update this issue rather than create a new one.

Specifically, I get a great many of those errors when I run cron manually from the status report page (to be clear: more instances than I have taxonomy terms, but far fewer than I have nodes). As a result of the errors, cron fails, and the "last run" date doesn't change.

They seem to also pop up sometimes when I edit old nodes or create new ones, but it's inconsistent and in testing for this bug post I wasn't able to reproduce it. I will keep trying to do so and post updates. Nonetheless, it *always* occurs when I run cron manually.

It's probably worth mentioning that I recently (after upgrading from 6.7 to 6.9) deleted some content types and created some new content types. I did all of that through the content-types admin panel, though, nothing shady like messing with values in the database tables.

I tried disabling everything but core modules, cleared the cache and ran cron again, and still got all of the errors. For the record, though, these are the contrib modules I have running:

• cck
• views
• countdown
• spamspan
• backup_migrate
• custom breadcrumbs
• pathauto
• path_redirect
• simplemenu
• string overrides
• token and token actions
• update status advanced

Again, I tried disabling all of those and still got the errors. I'm using a custom theme built on zen; switching to Garland and running cron manually still generates all of the errors.

There seem to be several issues posted against two other contrib modules related to the same error, but I don't have either of these installed: TinyMCE #309256: warning: Invalid argument supplied for foreach() in /var/www/vhosts/drupal6/includes/form.inc on line 1189. and #283879: warning: Invalid argument - When creating a new profile; Panels #316253: Broken arguments : Taxonomy term, Vocabulary ID, Node add form and Node edit.

Any ideas? Let me know if there's any other info I could provide to track this bug closer to its source. I'm not entirely sure if this is taxonomy.module, admin.module, cron, or something else.

OK, so after banging my head against a wall, trying to flush taxonomy.module and reinstall the tables (only to discover that taxonomy doesn't have an uninstall path in D6 -- #360104: Allow taxonomy to be uninstalled - move install/uninstall from system.install to taxonomy.install), I determined that despite all of the warnings from taxonomy.module, that wasn't what was preventing cron from running, but rather it was timing out trying to index too many items for search.

And lo and behold, reducing that number so that cron didn't time out made all of the taxonomy.module errors go away.

Completely inexplicable in my view, but it seems to have worked.

So to the original poster, I would suggest looking to see if your cron is timing out for other reasons, fixing that, and seeing if it affects the error messages.

I won't mark this as "fixed" since my issue was slightly different from the original, but I think this could be the fix.

Well, it's a good thing I didn't mark it as fixed. After running a few crons and having it index 5% of the site, the errors returned. Cron will still run, but no more of the site will be indexed.

I suspect that it may be related to #286263: Make search indexing smart to handle nodes wth php redirects

I wasn't the one who set up the site, so I don't know if there's PHP code initiating a redirect on a node, but there may well be.

However, applying the patch listed on that page doesn't seem to alter the errors or the lack of indexing.

It seems like this might be something other than taxonomy.module, and the taxonomy errors are just a symptom -- but I'm not sure. Any ideas from ANYONE reading this would be really really helpful...

Same issue is with me any one who solved this ........?

Also having the same problem. Any fix would be appreciated

same issue every time I run cron manually:
Invalid argument supplied for foreach() in taxonomy.module on line 1189.

This might fix your problem: http://drupal.org/node/259632

Like reported, that is a hack, and it's a bad idea to change Drupal core code without to know what the consequences on the other code could be.

Hi every one ,
I am also having this same issue before many days and today i debub how can i solve this issue actually i was having error ....
warning: Invalid argument supplied for foreach() in \includes\form.inc on line 1193.
I am having this issue and when i debug and comment the code of checkboxes in my module than this error is resolved but i have to use this checkboxes ,check my code if i m missing some minor code and tell me how can i solve this ..

$form['payment_options']['business_payment_method']= array(
'#type' => 'checkboxes',
'#title'=> t('Payment Options'),
'#default_value' => variable_get('business_payment_method',$selected_payment),
'#options' => $payment_options,
);
I am using this tell me if you understand how can i solve this issue ...

Thanks in Advance

Azhar
4 Ace Technologies(www.4acetech.com)
karachi,Pakistan

Here is one that has started without adding any new modules and after stabilizing a 5.14 upgrade to 6.9. During each cron (always runs successfully) this error shows 3 times in a row (shown below). Cron is run once per hour on the 45's. The search index never finishes. It will show 22 left or 4 left or it will show 23 left or 5 left. These remaining items to index will alternate back and fourth like this. The error only seems to come from auto cron not manually but either way site never fully indexes.

I have tried this query: SELECT type, message, COUNT(*) FROM watchdog WHERE variables NOT LIKE 'a:%' AND variables != 'N;' GROUP BY type, message but returns no results in watchdog

Type php
Date Thursday, January 29, 2009 - 8:45am
User Guest
Location http://
Referrer
Message Invalid argument supplied for foreach() in /home/content/m/o/d/modoggieweb/html/modules/taxonomy/taxonomy.module on line 1189.
Severity error
Hostname
Operations

@david-en8 and @Kiam@avpnet.org -- it's true that that is a "hack" of Drupal core, but maybe it would be useful for taxonomy.module to have that feature; I could see a case for a legitimate patch proposed for Drupal core.

That said, I'm pretty sure now, thanks to that post, that the errors are due to nodes that were "partially" deleted in some way (prior to when I took over the site) -- probably, I'm guessing, by removing content types that had some existing nodes. As grobemo says in response to 259632:

In general, these warnings arise when an incomplete node object is passed into a function. In this case in particular, nodes are sometimes passed to taxonomy_node_update_index() without $node->taxonomy, so the function gets upset when it looks for that property.

I think this is the case because I'm seeing the node objects showing up in other places -- in automatically-generated menu links and pathauto rewrites (and, when I look up the node IDs, in the database tables) -- but not in any content searches or in admin/content/node. When I run cron, all but a few dozen nodes are being added to the search index, and I think it's those incomplete ones that aren't being added.

So my question thus becomes: Is there a reliable way to remove node objects directly from the database tables? I've found the node rows in the database, but I'm not sure if just removing them from that single table would be sufficient, or if there are references to them elsewhere, potentially creating more serious problems if I removed the table entries manually.

I'm changing the title of this issue because I think it's pretty conclusive that these incomplete node objects are what create the errors.

The only reliable way to remove nodes from the database would be to have a Drupal function to do that. Or it could be done by a module that removes the data from the database, and then calls the implementation of hook_nodeapi() passing them 'delete' like value for $op. In this way, all the modules which have a table row about that node should remove it from their own database table.

I’m also seeing this error on line 1189 in taxonomy module. Here is my module list:

Modules implementing hook_nodeapi: rdf content content_permissions fivestar image_attach image_gallery mollom tagadelic book comment menu path search statistics taxonomy trigger upload creativecommons_lite freelinking img_assist inline technorati twitter upload_image workflow pathauto fieldgroup calais

I was receiving this error and it was in fact due to "incomplete" nodes or orphaned nodes of some kind that I believe were created when phpbb2drupal module was used and some forums did not import successfully. I manually deleted these faulty forum nodes from the database (nodes table) and the errors went away. hope that helps someone.

I caused myself some major headaches by trying out untested php inside the node content...
taxonomy_get_tree() was in some old node revisions that had php errors. This was causing the whole thing to crash when running cron, even though I changed the nodes so the the current content had no problems.

My first solution was to just delete the nodes - but that lead to the error listed on this page.

What I ended up doing was reimporting the node_revisions table from my backup and going into each instance of an old revision with bad php in it and deleting the contents of body and teaser without deleting the node. Now it's working fine.

Don't know exactly how relevant this is to the exact problems others on this thread are having... Hope this is helpful to someone.

I'm kind of new at this - I guess the general drupal lessons I learned are:
1) don't delete records in the database ever - alter the content if it's causing problems.
2) don't use php in the node content if possible to avoid it. If you must, test it first outside drupal - it won't go away even when you make changes to it.

I had this after updating a site from Drupal 5.16 to 6.10.

I noticed that the number of errors were as many as the number of "site notes" that I had. I've removed those, and the messages have gone.

Gets this error when anonymous user tries to searches for a word that is in the 'title' of any node that is viewable by authenticated users alone. If he signs in and again searches for the same the error is not triggered.So for me it is a content access error.

Is the issue present in Drupal 6.10 too?

not sure. site is on 6.9 . not yet updated.

This issue exists in 6.10 as well. According to the first comment on http://drupal.org/node/259632, it can be fixed by altering the taxonomy_node_update_index function as follows:

function taxonomy_node_update_index(&$node) {
  $output = array();
 if (empty($node->taxonomy)) {
    return;
  }
  foreach ($node->taxonomy as $term) {
    $output[] = $term->name;
  }
  if (count($output)) {
    return '<strong>('. implode(', ', $output) .')</strong>';
  }
}

Alternatively, we could patch as suggested in http://drupal.org/node/69807:

function taxonomy_node_update_index(&$node) {
  ...
    if (array_key_exists('taxonomy', $node)) {
      foreach ($node->taxonomy as $term) {
        ...
      }
    }
   ...
}

That way, people won't run into this error even if they have bad nodes in their DB.

Can anyone offer advice on how to identify the nodes that are causing the errors as I'd like to delete and recreate them in the hope this will fix the issue. Currently it is stopping the indexing from completing.

Any advice would be appreciated.

David

@david-en8: did you try one of the code snippets from #26?

I was hoping not to have to change any of the system modules, and having to keep doing so every time I update the version.

If I can identify the nodes that are causing the problem I shouldn't need to do the modifications.

I've come across this entry, do you think it might help?
http://drupal.org/node/310164

David

As i said, its a content access error for me.

Gets this error when anonymous user tries to searches for a word that is in the 'title' of any node that is viewable by authenticated users alone. If he signs in and again searches for the same the error is not triggered. So for me it is a content access error.

The error disappeared after i unpublished those nodes. Did so to get rid of the error until a good fix hits this thread.

With Drupal 6.12, I have resolved the issue :

if (!empty($node->taxonomy)) {
.....
foreach ($node->taxonomy as $term) {
........
}
}

I have run the following queries to find nodes without any Taxonomy entries or revision entries:

select node.`nid`
from node left join node
on node.`nid`=term_node.`nid`
where term_node.`nid` is null;

select node.`nid`
from node left join node_revisions
on node.`nid`=node_revisions.`nid`
where node_revisions.`nid` is null;

I did find several nodes without terms and corrected them, but still get the errors!

I've also looked to see if I have any nodes with terms that are not in the term_data table.
Interestingly if you change right to left in the code below you get a list of terms not used in any node!

select term_data.`tid`
from term_data right join term_node
on term_data.`tid`=term_node.`tid`
where term_node.`tid` is null;

Also note that the error message has changed since the recent update to:
Invalid argument supplied to foreach() in taxonomy.module (line 1214)

After more digging around I found the the first user in the user table "0" was missing and this seems to be used by a number of the logging routines.
My problem is that I don't know how to recreate it as MySQL starts creating auto increment records from "1" even if you specify the start to be "0"!

If you turn off AUTO-INCREMENT restore the user records including one with a uid of "0", then switch AUTO-INCREMENT back on it changes the number!

Any ideas?

Hi you all,

I had the same error/message after upgrading a drupal 5 site to drupal 6. After checking around a bit, I noticed that this was happen when indexing by search module was in progress. So I have completly removed und uninstalled all search modules and reinstalled them. After this action no messages are left, I am fine now :-)

Tom

Hi Tom

When you mention Removed and uninstalled, can you outline the procedure you followed.

I have disabled the search and the error have gone away, but as soon as I re-enable them, even after flushing the table the errors return.

I have even used the Development module version 6.x-1.18 to re-install search but this has not made any difference either!

You help would be appreciated.

David

Hi David,

my last posting is incorrect, sorry for that. After rebuilding the search index (it takes a while for 300.000 nodes) I had the same error again, but only with 6! warning messages. So I used the first SQL statement from http://drupal.org/node/310164#comment-1114330 and ... as I could see, there were my 6 nodes which where linked to a wrong/missing revision. I corrected these nodes manually (with Linux MySQL Query Browser) and after this procedure, no problems left.

The site is running now for about 10 days with 40 Users and a growing of 5.000 nodes. All went fine so long :-)

Tom

I tried the select nid,vid from node where (nid,vid) not in (select nid,vid from node_revisions) query and it returned zero results, so the error I'm getting can't be due to the same problem of missing entry in the node_revisions table.

I get: Invalid argument supplied for foreach() in /home/innovate/public_html/modules/taxonomy/taxonomy.module on line 1214. 32 times every time cron.php is run!

Does anyone else have ideas what is causing this?

I'm getting this also, Drupal 6.14. Triggered by Cron.php or by search.

"warning: Invalid argument supplied for foreach() in /home/atvbcorg/public_html/modules/taxonomy/taxonomy.module on line 1214."

I've found the solution!!!!!
After looking in http://drupal.org/node/259632 I used the following SQL:

SELECT n.nid, n.uid AS original_n_uid, u.uid FROM node n LEFT JOIN users u ON n.uid = u.uid WHERE u.uid IS NULL;
To find the nodes that have invalid owner ID's (uid)

SELECT * FROM users u;
To display the list of valid users (uid)'s, if you have 100's don't use this method!

Select one for the list then use the following code to update the notes to a valid value:
UPDATE node SET uid=18 WHERE nid=314;
In the above example 18 was a valid uid, and 314 was a node I wanted to update.

You can check if the update has been done using:
SELECT * FROM node n where nid = 314;

You can use phpMyAdmin or MySQL Query Browser

I hope this helps everyone who has been having this problem which has been driving me mad for months.

David

[Edited by kiamlaluno to remove the tags <h1>]

I ran into a similar problem. It's documented at #692764: Converting taxonomy vocabulary to required can cause PHP errors in watchdog.

David's solution in #38 is the same conclusion I came to.

It seems this problem occurs when a user has been deleted but any referencing nodes have not been set to UID 0. The query in node_load does an INNER JOIN on the {users} table which causes no result to be returned if the author no longer exists.

The only becomes a problem because of node_update_index which does a select without respecting the author relationship which node_load requires.

I believe running this query should show you any missing user id's for nodes...

SELECT n.nid FROM node n LEFT JOIN users u ON u.uid = n.uid WHERE u.uid IS NULL

It looks like Drupal 7 no longer enforces the UID relationship on node_load (due to the entity's)...

Do you still need help?

Yup, I was talking to you. ;-) Closing this issue.

Ah, I was getting this error on taxonomy.module at Line 1293 using the latest 6.x version. #38 helped me find the nodes to delete.

Deleting them was another chore, I referenced the code node_delete() in node.module but node_load() was not returning an object for these 'partial' nodes. But now, no more errors on Cron and I didn't have to hack taxonomy.module :)

#38 did the trick for me too

I keep getting this php error. would love to fix it but, im a newbie when it comes to these things. the solution in #38 is miles over my head. any hopes in a solution for the mysql inept?

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 in Content Manager but they still showed up, though node page said content not available.
I removed the rows from the "node" table in the database -- solved.

#38 saved my life!
Coming off a Drupal 5 -> Drupal 6 Migration, this "SELECT n.nid, n.uid AS original_n_uid, u.uid FROM node n LEFT JOIN users u ON n.uid = u.uid WHERE u.uid IS NULL"
gave me a bunch of nodes with type = "user_node" with referenced uids of user that have been deleted.

I deleted all these nodes and tadaaa: no more foreach()-warning.

Thanks a lot for this (even 2,5 years after your post)

I had the same problem, thanks #38 david-en8.

Interestingly, in my case the queries in #38 didn't reveal the problem nodes. It turned out there were 2 unlisted (orphaned) Ubercart product nodes, which were using taxonomy for their catalog vocabulary. The Status Report screen indicated the orphaned products and linked to a page providing URLs. One of them was an old node that had never been properly deleted; the other was linked to but resulted in a page not found. However, from the node id in the URL I was able to find the offending node in the node table and delete it that way. After doing so, the foreach error message ceased appearing on cron run.

I think what may have happened is that originally a taxonomy assignment was not required on product-type node creation and these nodes were not assigned a category term. OR.. the term they had previously been assigned was deleted.

Hooray. #38 did it for me. You rock.

If all you want to do is give the nodes to the anonymous user (or a single user by replacing the uid) you can do this:
UPDATE node n LEFT JOIN users u ON n.uid = u.uid SET n.uid=0 WHERE u.uid IS NULL;