In line 1286 php hits a warning because the module doesnt test if there are items in the field-array before iterate it.

patch:

Replace line 1284:
else {
with
else if (count($type['fields'])>0) {

Files: 
CommentFileSizeAuthor
#5 cck-invalid_arg_foreach-716878-5.patch651 bytesrooby

Comments

Subscribing.

Title:Invalid argument supplied for foreach() in .../modules/cck/content.module on line 1286Invalid argument supplied for foreach() in .../modules/cck/content.module on line 1284

The only reason I was seeing this error is because I had somehow ended up with content that had no node type.
Possibly due to a bug in a custom node importing module.

You should check your site for this because if that is the case it is your site's problem not cck's

@Rooby
I have the same problem so now I want to check in phpMyAdmin if my "content" also has no "node type".
But in which of the tables (what you call content) do I have to look for what you call "node type"? And is it really called node type in the table ordoes it have one of those unrecognizable non-self-explicating abbreviations as Drupal seems to be fond of?

Hello again, I found out.
The "node" table (of course) and the field "type". And it turns out that all the content seems to have a node-type assigned.
Does this mean I should try with the code from werk21?

StatusFileSize
new651 bytes

Yeah, that's the correct place to look in the database.

I can't really remember much about this now and I haven't tested that code so I can't comment on that sorry.

I just had a quick look at it and it isn't that the array is empty because that function doen't care if it is empty. It either doesn't exist or it is not an array.
This patch should resolve it, but I haven't tested it or looked into why it is happening.

The patch applies to 6.x-2.7 and possibly for dev too.

Works fine. Thanks

i also had this error when redirecting after node submission with the rules module.
cck version 2.8

this patch removes the error.

thanks

Version:6.x-2.6» 6.x-2.8

I just fixed the error using the patch from rooby but for some reason when I import my local database to my server half of the nodes that I created using a custom content type do not show up. There is a space for the content but it shows up as "n/a" instead of actually displaying what I created. I tried dropping all the tables on my servers database and re-importing them but nothing has worked!

I'm not sure if this problem has anything to do with the "Invalid argument supplied for foreach() in .../modules/cck/content.module on line 1284" but that used to only be displayed at the top of the page where the custom content type was.

Any input would be great! Thanks!

Category:bug» support
Status:Active» Fixed

This is a support request -- if you are trying to move data from one place to another and something went wrong which might (or most likely) might not have anything to do with CCK. You need to step back through whatever you did to move the data and figure out what happened to it. 'Import my local database to my server' could mean many things -- you used some custom code to move your data, you did a database dump and tried to load it on another server than the one it was created on, you used some import/export module to try to move your data. None of those is really anything to do with CCK and all of them have multiple places where data could get corrupted.

The error message is not hidden because in a normal situation you should never see it. The patch just hides the message, it does not fix the problem that caused it. It may or may not mean anything. If you ended up with content that is missing a type, that is way outside the scope of things that CCK by itself could cause.

The CCK maintainers can barely keep up with CCK issues, we really can't help you with things that are outside CCK (like moving data from one server to another.) Sorry.

Category:support» bug
Status:Fixed» Active

This should not be closed because of #8. Even if the issue in #8 is related to a db import, the issue in OP is not.

I did not db import and I get this error on a site I'm working on and it's very strange. The first time when I visit a page I don't get an error. If I refresh, I get the error. Move onto another page and the error is there the first time, but not on the next refreshes.

I fixed my error by changing the Author of each node to admin instead of Anonymous. It had nothing to do with the db import. Not really sure why that fixed the problem though...

I'm seeing the same error. Still trying to figure out what caused it; the only thing I changed is switching a multi-value node reference field from required to optional. Could that have something to do with it?

Subscribing. I am seeing

warning: Invalid argument supplied for foreach()
cck\content.module on line 1284

on my site. I had just deleted some Flashnode content and rather than deleting it, the uid in the node table for the node was set to 0 (zero).

I went into the db with PHPMyadmin and set it to a non-zero value to get rid of this error. If the developers want to look at line 1284 of content.module and write some code that checks for invalid data like this, it might help make the product better. I wish I could help more.

Yes, this was corrupted data and the faulty code that corrupted it was most like a contributed module, but my point here is that the core did not handle the error condition, and was displaying this error to ALL users on the home page.

you have not a anonymous user in database (user 0 ) chek it

Ah, so User 0 is "anonymous" - that helps, thanks.

Still, User 0 should not own content, right? Even if that is true, is it reasonable to expect the content.module code to check for this invalid condition and not display PHP errors (that don't indicate what the problem is) when they happen?

OK, I have checked the user table and there is no user with ID of 0.

I found a module to deal with this, http://drupal.org/project/anonymous_user but it begs the question how this user might be missing.

Status:Active» Fixed

CCK is not responsible for working around corrupted data. CCK is also not responsible for deciding how and when core will display errors.

BTW, it is perfectly valid to have a node that was created by an anonymous user, if you have set your permissions up to allow anonymous users to create content, or if you have imported content without giving it a user, or you have deleted the user that created it, or in lots of other situations.

But that has nothing to do with CCK and CCK does not have any control over it. As far as I can see there is nothing in this report that has anything to do with CCK.

@KarenS Thanks for the info on anon users owning content - makes sense.

But I think we came here because CCK is the module with the error message.

I realize that it's up to a developer to decide if they want to add error handling or not, but I think doing it makes code better and friendlier, whether it's module or core. I think I heard that CCK is going to be part of core in D7, so that distinction will be moot soon enough.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:6.x-2.8» 6.x-2.9
Status:Closed (fixed)» Needs review

Hi.
I have same issue.
In my situation, i replace standart behavior of front page, to prevent any drupal standart actions (such as node load, or show last nodes list), and i do something like this:
in template.php:
function my_theme_preprocess_page(&$variables) {
$variables['content'] = theme('node', NULL);
...
}

and in node-front.tpl.php writing my custom output code.
That's work fine, until i installed cck module.
I think this in normal situation and module should handle empty array on line 1290 in content.module.
Or I am mistaken?

I had an issue with a module that I created. (The error was nothing to do with CCK.) My module was giving me this error for a custom content type. (It was looking for nodes of this type, expecting to find one when there were none.)

Here's my old code :

<?php
$result
= db_result(db_query("SELECT nid FROM {node} WHERE type = '%s' ORDER BY RAND() LIMIT 1", "testimonial")); /* can return FALSE */
$testimonial = node_load($result); // fails if no node
$block['content'] = node_view($testimonial, TRUE); // fails if no node + produces error
?>

New code :

<?php
$result
= db_result(db_query("SELECT nid FROM {node} WHERE type = '%s' ORDER BY RAND() LIMIT 1", "testimonial"));
                if (
$result !== FALSE ) { /* there is a node, so show it */
                   
$testimonial = node_load($result);
                   
$block['content'] = node_view($testimonial, TRUE);
                }
                else {
/* no node, don't show anything */
                   
$testimonial = '';
                   
$block['content'] = $testimonial;
                }
?>

I don't know if it will, but hopefully this comment helps somebody.

Hello, I had same issue because was absent owner of the node, so you can check in db is there creator of the node.

May be that will help anybody.

We also noticed that any snippet of code which calls node_load($nid) with a NULL $nid seems to lead to this error. So a module or piece of evaluated php that does that could be related to the problem. If so, it would seemingly be a case-specific error.

Many thanks for the comment thread. It saved my life!

I was building a new version of my Drupal 6 database beside my old one for some reason. I was importing data from the old to the new and quite a lot of my imported nodes said 'page not found'. But they showed up again as soon as I imported ALL the users from the old database :)

Also had this problem, and also fixed it by checking the user ID for the node, and found that it was for some reason set to 0 (meaning no author). Changed it to a real userID and problem fixed.

I can concur that this issue exists on my site because the 'type' field isn't set on nodes that are being imported with the feeds importer module. In our case something in the chain of node-insertion (possibly an action that modifies the uid) is causing all the node fields to get cleared out. Interestingly, Drupal 6 isn't preventing these empty node records from being inserted, so we've been clearing them out periodically. If I'm able to track down the root cause I'll make a note here and in the implicated module's issue queue.