warning: Invalid argument supplied for foreach() in content.module on line 1022.

See if the following issue can help you figure out the cause: #493068: Warning and cck values doesn't stored

I observed the following report entry after using CCK 6.x-2.4 and CCK 6.x-2.5:

"Invalid argument supplied for foreach() in .../sites/all/modules/swftools/swftools.admin.inc on line 480."

1. I uninstalled CCK 6.x-2.5 after receiving that error message.
2. I installed CCK 6.x-2.4 and received the same error message.
3. I uninstalled CCK 6.x-2.4
4. I downloaded and reinstalled CCK 6.x-2.5 with the same result.

This is how to invoke the error:
Navigate to Administer>Site Configuration> SWF Tools and
click on CCK formatters for the following result:

warning: Invalid argument supplied for foreach() in (omitted path)/sites/all/modules/swftools/swftools.admin.inc on line 480.

Note: I installed SWF Tools 6.x-2.5 before I installed CCK 6.x-2.5. Does that make a difference?
Should I uninstall both and try installing CCK 6.x-2.5 before I install SWF Tools 6.x-2.5?

@racalvin: You should report your issue to the SWFTools module.

I just spent half the day trying to figure out this exact same issue. My client has been having weird stuff happening to his site: images stop showing up, databases disappear from phpmyadmin and Backup & Migrate, and today, all the content from certain node types simply vanished. We initially thought we had a hacker, but then I checked the logs and saw the line 1022 error message, which led me here. Thank goodness!!

Here's an example of the weirdness: a recently created node had an image and two textfields - a short description and a body field (a CCK created body field). Today, only the title was visible. Editing the node, showed empty fields all around. Checking the database directly showed that the data was there, it obviously just wasn't getting pulled in for some reason. So I tried adding the content back into the node, but after saving it, nothing showed up on the node view. That's when I saw the line 1022 error in the logs. So I went to the content type, saved the main edit page, and then edited and saved (without any changes) each field. Boom! All the images and content magically reappeared. The really weird thing is that it seems to have fixed at least two other content types that had the same problem.

And, yes, this site was upgraded from 5.x. So now, to be safe, I'm going through every single content type and re-saving each field. Pain in the butt, but at least my client is happy...which means I'm happy :)

I have not tried upgrading from 2.5 to 2.6 to see if it fixes this, mainly because there is at least one known new bug with 2.6 and I don't want more trouble. I suspect that it won't fix it, though. As matt2000 suggests, its most likely something to do with the upgrade path. I know for sure that the upgrade broke a lot of the image field display settings, reverting to Generic Files instead of the correct imagecache preset.

subscribe

The same problem with my drupal site. I'm usign 2 sql db for my site (another base _SHARED) and when I add second site and it begin to use _SHARED tables - there goes lot of errors...
settings.php:

'content_field_image'=>'_shared.',
	'content_node_field'=>'_shared.',
	'content_node_field_instance'=>'_shared.',
	'content_type_blog'=>'_shared.',
	'content_type_news'=>'_shared.',
	'content_type_page'=>'_shared.',
	'content_type_photo'=>'_shared.',

I'm having this error as well. I created a text field, but when I try to enter text it appears to save. Returning to that page does not show the entered value. The db table shows NULL for the field in question.

This error appears at times, but I can't say it happens everytime.
Invalid argument supplied for foreach() in /var/www/pressflow-trunk/sites/all/modules/cck/content.module on line 1022.

Have traced this to a possible problem with the Memcache *driver*. Will continue to update as more information appears. Can previous posters please confirm they are using Memcache?

Confirmed driver problem:

PECL memcache driver vs. PECL memcached driver. PECL memcached driver works to solve this problem. The older version causes this problem.

Also, to have the Drupal memcache module use the PECL memcached driver, you need to apply attached patch.

subscribing

We are not using the subscriptions module.

As a follow-up the problem has completely disappeared for us. We may be looking at two different problems.

Subscribe,
Just noticed this on one of the site, will continue to dig further (using 6.14 & cck 2.6 )

I never used Memcached or Subscriptions modules, and haven't seen a recurrence of this problem since my original post (#7).

Here's a possible source of this kind of issues:

- #769862: warning: preg_match() expects parameter 2 to be string, array given in /includes/bootstrap.inc on line 777.

http://drupal.org/node/493068

$db_prefix = array(
'default' => ''
);

It's important that in default you should put a blank. If you don't do this, then you take this warning, I have solved this problem In this way。

Marked #493068: Warning and cck values doesn't stored as a duplicate of this.

Setting the default prefix isn't really a fix to this issue; CCK and Date should function properly without specifying a blank default prefix. On some sites, having a default prefix of '' will break other functionality, such as single sign on.

I've just started looking into this but it looks like drupal_get_schema() returns false for the table for a cck-defined event content type. Thanks to markus_petrux for pointing to a possible similar cause above.

I tracked this down to an instance of http://drupal.org/node/286986#comment-2951102 . If other folks could review the D6 patches there, that would be great.

Hi,

I've solved the problem by increasing the memory limit.

(It is highly recommended that you set you PHP memory_limit to 96M to use ImageAPI GD. A 1600x1200 images consumes ~45M of memory when decompressed and there are instances where ImageAPI GD is operating on two decompressed images at once.)

Hi,

Saving the configuration of the field again solved the issue for me.
Drupal 6 Site not upgraded from D5.

To anyone having this problem and you have a default database prefix other than '' (and you can't change it without breaking your site, eg. single sign-on), there is a hack that will fix the issue for you.

As ezra-g has pointed out in #23, there is an issue in core that causes db_table_exists() to fail when you have a default database prefix. content_schema() uses db_table_exists() and so returns an incomplete $schema variable. So if you'd like cck to function, add the following function to content.module:

function content_db_table_exists($table) {
  $prefixed_table = db_prefix_tables('{'.$table.'}');
  $pattern = '/^([_a-z0-9]+)\\.([-_a-z0-9]+)$/i';
  $match = array();
  if (preg_match($pattern, $prefixed_table, $match)) {
    global $active_db;
    return (bool) db_fetch_object(mysql_query("SHOW TABLES FROM " . $match[1] . " LIKE '" . $match[2] . "'", $active_db));
  }
  return (bool) db_fetch_object(db_query("SHOW TABLES LIKE '{". db_escape_table($table) ."}'"));
}

Then do a search and replace on the modules/cck folder and replace all instances of 'db_table_exists' with 'content_db_table_exists'. Clear the cache. Done.

As I said, a hack but not many other options until #286986: MySQL: SHOW TABLES LIKE database.tablename doesn't work is resolved for D6. Of course, you can always hack core if you feel so inclined and leave cck alone. Both options are evil. Of course, the next time you update cck you'll have to do this all over again so it's not recommended.

number 1 helped me alot after trying all manner of stuff.

Have the same problem.
Tried #1 #21 and #26 - didn't work.
6.20 settings.php:

$db_url = 'mysql://ts_user:xxx@localhost/ts_main';
$db_prefix = array(
'default' => 'ts_main.', 
'users' => 'ts_common.',
'sessions' => 'ts_common.',
'authmap' => 'ts_common.',
'users_roles' => 'ts_common.',
'profile_fields' => 'ts_common.',
'profile_values' => 'ts_common.',
'locales_source' => 'ts_common.',
'locales_target' => 'ts_common.',

Is there anything I can try?

Hello,

Im having the same issue on a fresh install of drupal 6.20. Here's the warning:

warning: Invalid argument supplied for foreach() in /home/halfbake/public_html/sites/all/modules/cck/content.module on line 1284.

I'm using devel, views, and token modules. I've disabled everything except cck, and cleared my cache. I've only published one page and promoted it to front page, but that was before I installed cck. Would that have caused the issue? I'm all up for ideas; I'll even wipe my drupal install and do a fresh install. Any help would be appreciated.

Thank you

Encountered this after installing APC. Re-saving the content type worked. Thanks :)

In my case, it appears to be somewhat related to table prefixing. Although in my case, table prefixing is being done programmatically via Domain Access. Re-saving the content type for the subdomains appears to clear the problem for me.

Hello, I've created a module to automate a content type creation with an imagefield and a datefield. I've the same problem.I've done the #21 solution but I'm wonder why I should change the $db_prefix value because I don't use prefix table. For information I use a clean install of Drupal 6.20.

I encountered this problem in my Aegir based single sign-on install.
I was able to fix it using '' for default prefix, following #21:

$db_prefix = array(
  'default'   => '',
  'users'     => 'databasename_front_site.',
  'sessions'  => 'databasename_front_site.',
  'authmap'   => 'databasename_front_site.',
);

Though I am still left wondering why setting the default table prefix might have this effect?

without any good cause (the webshop has been running fine for months) suddenly uploading, saving and retrieving the cck field fails with error 1022 in the log.

#21 didn't fix it (we are not using prefixes anyway in this system)
we are not using memcache and
#24 we are using 128k Memory
#25 resaving the content type fixed it for us

We are seeing this issue on our site as well. We are using memcache and APC. We are not using db prefixes. It seems to go away on its own, but comes back eventually. Has anyone had an update on this?

It is not working for me.

The error was BEFORE content_db_table_exists function (debug messages in it aren't appears)

My task:
Site1 -> database 1
Site2 -> database 2
Site1, Site2 -> database 3 (common)

Common content: nodes (with cck fields, users, file storage)

Common tables in settings.php:
$db_prefix = array(
'default' => '',
'users' => 'ots_common.',
'users_roles' => 'ots_common.',
'sessions' => 'ots_common.',
'node' => 'ots_common.',
'node_access' => 'ots_common.',
'node_comment_statistics' => 'ots_common.',
'node_counter' => 'ots_common.',
'node_revisions' => 'ots_common.',
'node_type' => 'ots_common.',

'content_node_field' => 'ots_common.',
'content_node_field_instance' => 'ots_common.',
'content_type_promo' => 'ots_common.',
'content_type_news' => 'ots_common.',
'content_type_anchorperson' => 'ots_common.',
'content_type_anchorperson_photo' => 'ots_common.',
'files' => 'ots_common.',
);

This has just started happening on a site of mine.

Not using any special caching modules or table prefixes or anything like that. It is a very simple site.

I have traced the problem on my site to the cache of the schema.
The database has these tables that are not in the $schema cache:
advanced_help_index
content_field_attachments
content_field_event_image
content_field_event_location
content_field_news_image
content_field_service_images
content_field_service_stad
content_type_event
content_type_news
content_type_page
content_type_service
helpinject
location_search_work
performance_detail
performance_summary

If I use the devel/php page to run drupal_get_schema() with $rebuild set to TRUE I get the full list without any missing.
So something has gone awry at some stage when building the cache, and now I'm getting serverd up a bad cache.

The problem is easily fixed by rebuilding the cache but why did it happen and if/when will it happen again.

In the content_storage() function we could force the call to drupal_get_schema to reset the cache every time but that would not be good for performance.

- Also, this is not minor. It fully breaks being able to create or edit nodes.
It is probably critical, although you might say it is major seeing as it only happens for some of the people some of the time.

Subscribing, using Memcache and APC, programatically creating nodes sometimes results in this error and creation of a blank nodes in the node table.

@kubrt:

using Memcache and APC, programatically creating nodes

This means you quite possibly have an issue somewhere else that is unrelated to CCK because the creation of blank nodes seems like the bug there.

A main cause is certainly the malfunctioning sql statement: SHOW TABLES LIKE '%'

When you save the settings of a content field, Drupal executes following sql statement to see if a table exists:

SHOW TABLES LIKE 'prefix.content_type_name'

This returns nothing in mysql because of the prefix. This makes Drupal think that the table doesn't exist, so I tries to recreate the table. But that also results in an error, because the table does already exists. Eventually Drupal says that the changes are saved (ahem).

Fixing this is what #26 tries to achieve. He changes the SQL statement when a prefix is present. However, in some situations his solution doesn't seem to work.

What did work for me is a similar fix in this thread: http://drupal.org/node/286986#comment-4605334 (comment 38 in that thread). Make sure you patch both database.mysqli.inc and database.mysql.inc

After applying the fix, clear the cache, edit a CCK-field of that content type and press save. Look at the sql-log of Devel (or the watchdog log) and see if it unsuccessfully tries to create the content_type table. As long as it tries to do that, it won't work.

By applying the patch, you're editing the core, which is not recommended. Make sure you document this core-change for yourself and other devs on your project.

Like #14/neoliminal, we were having the same issue, and flushing memcached solved the issue. No fields were showing up, and we were getting the errors any time we tried saving a node. Thanks!