You are here

Resolving the "Invalid argument supplied for foreach()" in /taxonomy.module

I have been trying to resolve this error that I've been getting for some time and have finally figured it out so I wanted to share it with others. I was unable to find a post on the forums or elsewhere that resolved my particular problem.

warning: Invalid argument supplied for foreach() in [path to]/modules/taxonomy/taxonomy.module on line 1241.

I wrote a basic module that just checked nodes, node_revisions, taxonomy and users. It turns out that the majority of my "warnings" were from referencing a user.uid in the node and node_revisions table that did NOT exist in the user table.

Due to importing multiple Wordpress blogs and other content a number of users were created and then deleted from the users table to "clean things up" (as in someone went into phpadmin and deleted those rows with that uid). Over time this caused problems, especially when (re)indexing with the Solr module.

The module report I wrote compared nodes and the nodes loaded up using node_load. The majority of the warnings were resolved by just recreating an account with that user id (uid) in phpmyadmin and assigning it the missing uid. I think updating both the nodes and node_revisions table to a valid user's iud would work but I didn't want to take the risk of corrupting something else, hence recreating the deleted account.

Comments

Not sure where to add this, but I turned my script into a Drupal reporting module. It checks various consistencies between tables and displays them. It seemed part of the problem with my errors was someone deleting rows from the node_revisions, users, term_node and vocabulary tables.

If you would like to try the report, let me know. It's bundled up already in a nice tar.gz.

I didn't realize there was activity on this thread. I'll subscribe to it from now on. Also, this report helped resolve the issues I was having; it may or may not help resolve yours. It you find out that it doesn't help, let me know and I'll work to add other inconsistencies and problems to this report.

Thank you very much for the code. Report indicated 6 problems, which I erased. Ran cron again, but the erros remained. warning: Invalid argument supplied for foreach() in /drupal/modules/taxonomy/taxonomy.module on line 1241.

The only thing off hand I could think is to check if there is no term_data.tid = 0, and then verify if in the term_is indeed a term_node that is set to term_node.tid = 0; if both are true, then try adding a row into term_data with a tid = 0.

This resolved a number of issues for me. I couldn't get the site to index properly because of the line 1241 error, and I had a number of taxonomy issues. Now it's indexed the site and fixed the tax errors! Many thanks

Yeah, I can't guarantee my script will report every problem. I was limited to the problems I had with my data and was trying to resolve my issues. That being said, I don't mind trying to help others, but it's difficult when I don't know what to look for; there is only so far someone can help without having access to a clone of your site.

If you're able to figure out what is causing your problems, let me know and I will add that to the report so it helps the next person.

Copy / pasting the code from the web page resulted in a funky character at the beginning of many lines for me (Mac OS). I couldn't see them on Mac, but on Windows they showed as a capital E with a caret ^ on top and caused PHP parsing errors. When I got rid of them, it worked fine.

Thanks for the module!
I need a little help...
Each time the cron runs these errors appear 17 times.

Your module tells me:

Missing VocabularyThe following is a list of term_data.vid that are NOT in the vocabulary.vid. If a new vocabulary.vid is created all will be well.

this term_data.vid/vocabulary.vid 0 IS NOT in vocabulary

In my PhpMyAdmin I looked at my term_data tables and there were no terms associated with vid 0
I looked at vocabulary tables and there are 9 vocabularies, vid from 1-10, but no vid 8 (I guess it was deleted at some point) - otherwise there's nothing suspicious.

Yeah, I can't guarantee my script will report every problem. I was limited to the problems I had with my data and was trying to resolve my issues. That being said, I don't mind trying to help others, but it's difficult when I don't know what to look for; there is only so far someone can help without having access to a clone of your site.

If you're able to figure out what is causing your problems, let me know and I will add that to the report so it helps the next person.

Best of luck.

All,

I have two drupal test sites that I test this against, and I'm limited with only the data set that I have, so it's difficult to figure out some problems. I'm a bit perplexed why the report does not work for some, and it works for others. It leads me to believe there are other inconsistencies with the data in particular tables.

If you have a test instance of drupal, where the information in those tables is not sensitive (meaning test data), and you have issues that are not being resolved using this report, I invite you to share that exported data and your exact setup (meaning active modules, their versions and drupal version) so that others, including myself, can work to incorporate more features in order to address varieties of problems into this reporting module.

I've only tested this reporting module using MySQL, not PostgreSQL. I'm curious to know how many are using PostgreSQL.

I have not started to port this to drupal 7. Should similar problems arise in drupal 7, I will start porting it.

I never realized that there were so many users that were having similar problems. I would be interested in feedback to know if it would be more beneficial to create an actual "official" contributed module where others can assist me in contributing to and maintaining it.

I will continue to monitor this thread. When I can determine exactly what is causing these other errors, I will incorporate them into the module. Likewise, if I'm able to offer a resolution to a post here, I will post a reply.

I apologize for not being able to address the specific needs of everyone at this time. Like many others, my time and resources are limited.

Thanks for your help on this. I am unable to post the contents of my tables, but I will say that I did find some of the threads here helpful. I had about 20 users that I deleted during setup of my site that were for testing accounts. I used Devel module to create a a number of users. I then used phpMyAdmin to change UID #'s to fill in blanks. I did not replace every UID that was previously deleted. I have no more errors. While I do not know where the error came from, it was definitely a missing UID that caused the error.

The module worked for me to determine the ID of the user in question as relating to the error. It turns out that the user was no longer in the database so my guess is that he might have been manually deleted instead of being deleted in Drupal but I can't be sure of that.

My error was:

node_revisions.nid(78) & node_revisions.vid(85) uses node_revisions.uid(11), but users.uid(11) does NOT EXIST.
(similar ones repeated 16 times all pointing to the same user ID

Should a new user be created a somehow try to assign that missing id to the user or would it be better to try to delete the node revisions or better yet assign a different user to those revisions?

UPDATE:
I was able to resolve this error found with the module using this query in PHPmyadmin:update `node_revisions` set uid = 1 where uid = 11
You may need to substitute the user id in question. Basically the query changes the user id to 1 from the missing id of 11

Awesome module. I was however wondering if there was a way to add the variable table to check and see if the data stored in it was able to be serialized. I tried modifying what you have but I'm still fairly new to php and I can't quite seem to get it to work.
Also cafuego wrote a module for v7 http://drupal.org/project/variablecheck but even after going through his I just dont know what I'm doing wrong.

I get the following
Notice: unserialize() [function.unserialize]: Error at offset 42 of 374 bytes in unserialize() (line 637 of /public_html/includes/menu.inc).

I think it is in the variable table but I have manually checked the table and looked through it and cannot find the problem within the table. I think your module would help me identify the issue in the table.

Its weird because I don't have any variables that are 374 bytes in length in that table.

I get the error whenever I view an admin page and it just shows up in the error log. I think it has something to do with my menu but I have a workaround for the menu because I was not able to alter the basic navigation menu.

cafuego added support to v6 for his Variable Check module which was able to fix my issue.

I ran the module and it did not give any error results. The problem I was having where I got this error, is when I search for the name of a user that should display with profile module, I get the error, and the entry where that user should come up, just had

"...
Anonymous - Comment"

If I tried to browse to the user's page profile page, I just got a 404 error.

I noticed in the node table that these users had a uid of 0. I changed on of these to 1 and the page worked. These particular users don't actually have login accounts, and are just listed as adjunct professors on my site, so I have been simply removing the user form the authoring information on the profile page (since an actual user can only have one profile).

so, what I noticed, is when I set the uid to 1, then went to the edit page for that user profile, it had my ID in the Author info. I removed that (setting the field to blank) and saved. Checked that user node in the DB again and it had a uid of 72. I used an update query to change all the uid =0 nodes (which corresponded to the profile pages that were having an issue. and now they all work. And the index that would only go to 95% complete, now goes to 100%.

Hi,
Thanks for the code. I installed your module and ran the report and received the following report. I don't yet know how to fix the errors. Hope someone can help me with that. If not I'll be studying it out myself as I have time.
(The top two "user warning" listings were errors from Drupal)

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.

Missing Vocabulary

The following is a list of term_data.vid that are NOT in the vocabulary.vid. If a new vocabulary.vid is created all will be well.

this term_data.vid/vocabulary.vid 154 IS NOT in vocabulary

this term_data.vid/vocabulary.vid 154 IS NOT in vocabulary

this term_data.vid/vocabulary.vid 154 IS NOT in vocabulary

node.nid(218) CANNOT be found in node_revisions.nid

The node_revisions table lacks the row being called from node.nid(218) with it's matching node.vid. There is also not a node_revisions.vid(327) in node_revisions. One solution to resolve this is to insert a row into node_revisions where:

node_revisions.nid = 218
node_revisions.vid = 327
node_revisions.uid = 1
node_revisions.title = bibl exp
node_revisions.body = This is a recovery for lost content.
node_revisions.teaser = This is a recovery for lost content.

node.nid(233) CANNOT be found in node_revisions.nid

The node_revisions table lacks the row being called from node.nid(233) with it's matching node.vid. There is also not a node_revisions.vid(343) in node_revisions. One solution to resolve this is to insert a row into node_revisions where:

node_revisions.nid = 233
node_revisions.vid = 343
node_revisions.uid = 1
node_revisions.title = Leaders in Religion
node_revisions.body = This is a recovery for lost content.
node_revisions.teaser = This is a recovery for lost content.

I am glad that experts find this module very useful. What about the newbies like me...

I have copied and pasted the code in to the correct files using the wordpad (I am not a developer so I have no cool tools to use for coding).
I have put the module in the modules directory.

That's it. I do not see the module among the modules from the admin view. I understand that cron must be run to generate reports. I use poormanscron. I look at the Report folder I do not see any there either.

How on eath am I supposed to use this - please give me "special_report module use for dummies" version. Many thanks in advance.

I am glad that experts find this module very useful. What about the newbies like me...

I have copied and pasted the code in to the correct files using the wordpad (I am not a developer so I have no cool tools to use for coding).
I have put the module in the modules directory.

That's it. I do not see the module among the modules from the admin view. I understand that cron must be run to generate reports. I use poormanscron. I look at the Report folder I do not see any there either.

How on earth am I supposed to use this - please give me "special_report module use for dummies" version. Many thanks in advance.

Not sure if you figured it out yet or not, but enable the module as normal under the site building/modules section. Under the same section at the top of the page you can run update.php and then it should show up in the reports section under your admin menu if you have them organized by task.

The Module did not show up under the modules. I am pretty sure it was due to copying and pasting the code from the screen.

DANNY, thank you for emailing me the module. That worked. I enabled the module and the report showed up under the reports section.

Looks like I had only missing nid problem in the node_revisions table. However, I did not insert lines into the node_revisions table as suggested. When I checked the "node" table I saw entries for two content page duplicated and one deleted content page. Obviously the deleted and duplicated pages did not have the corresponding entries in the node_revisions table. After deleting those three (redundant) entries from the "node" table, the special_reports did not show any other issue.

Thanks so much for this module. I don't know how I would ever have found these database errors. I had looked in all the usual places, but your module reported exactly what I needed. It still shows this error

The following is a list of term_data.vid that are NOT in the vocabulary.vid. If a new vocabulary.vid is created all will be well.

this term_data.vid/vocabulary.vid 6 IS NOT in vocabulary

this term_data.vid/vocabulary.vid 6 IS NOT in vocabulary

But the 1241 error is gone in my logs, so I don't know if I need to investigate and fix this vid error or not. And I'm not quite sure how to fix it if I need to. The main point is that when I run cron, the 1241 error no longer appears. I had three missing rows from the revision table.

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.

Thanks very much.
This module helped me find a problem I had been searching for.
One issue that others may run into:
As soon as I resolved the foreach() error in taxonomy by inserting a new row into node_revisions as recommended by this module, I got an even uglier error from xmlsitemap. Researching that, I found that it was known and updating to beta2 fixed it.

The moral of the story is don't panic, plan to update xmlsitemap if you aren't on the most recent version.

No, try changing your server's memory limit to at least 100MB or as high as your host allows if you're on shared hosting. There's lots of tutorials how to do this. You can see what your current limit is by visiting yoursite.com/admin/reports/status

Also try flushing the cache first, this helps reduce the database size. To flush the cache, go to yoursite.com/admin/settings/performance

We persist with this error (1241) and have tried Avaya's module.
It took a while but realized that the node debug report can only be viewed if you are user 1
Report cannot be viewed -- it results in a WSOD time out.
We have memory boosted.
We have 300+ posts that had a uid 0, but created a user account as uid 0 but that didn't help. We think these were orphaned when we deleted some accounts a while ago.
Cron has failed for several weeks now. And it gives the 1241 error.
What adds to our bafflement is that cron worked fine up to a few weeks ago. No major changes to the site since then.

So questions are these:

Why are we getting the WSOD? And what can we do about it?

Any thought as to why we have so many nodes with uid 0 after account deletions?

Should we just bite the bullet and ascribe these nodes to uid1? Or should we just delete the nodes?

very frustrating. And we suspect it is at the root of some hangups our site has been experiencing.
thanks in advance,
geoff

Thanks a lot for this, I ran it and solved a few node_revisions issues. I stopped getting the infamous 1241 taxonomy error, but I still can't get my cron to execute :( I thought I'd seen the light but no dice. Thanks anyway!

I had a customer complaining that the SEARCH on the site was not functioning. So every time we attempted to reindex the site we noticed a funny behaviour, initially at every cron run the percentage of the site indexed would gradually increase and at a particular point it would start reducing gradually. I always thought that the SEARCH index was corrupt and would flush the SEARCH tables from the mysql command prompt.

But today when I checked watchdog I noticed this error and it misled me into thinking that it was some taxonomy term misbehaving, but then I had only one taxonomy term that was created by the simplenews module for identifying the newsletter. I checked all content types but couldn't home in on the problem. I went back to the SEARCH seeting screen (remember that I flushed the SEARCH tables) and to my surprise found that there were abou 22000+ items to reindex, on a site with about 1500+ users and very little content I had a doubt on the how the number of nodes increased to 22000+. So googling drupal with the "Invalid argument...taxonomy" string I landed on this post. So I quickly installed the special reports module and it threw a few misisng references in node_revisions. So I did a quick SELECT and then DELETE on all node_revision records with uid=0 then ran the special reports again now it pointed to the node table with uid=0 and missing node revisions. So did a quick SELECT and found content of the type MEMBER (this content type doesn't even exist) . So DELETED all of these misbehaving nodes. That left me with about 1600+ nodes. And I ran cron and search sailed through beautifully. Thank you.