Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We get this when submitting nodes of a type containing two text fields.
line 1022 is, of course:
foreach ($schema['content fields'] as $field_name)
from content_storage().
Status Report & update.php say database schema is up to date, so I'm baffled.
Any help...?
Comment | File | Size | Author |
---|---|---|---|
#14 | 2342_2341.diff | 1.18 KB | neoliminal |
Comments
Comment #1
matt2000 CreditAttribution: matt2000 commentedI went to each of my fields settings forms, and my content type settings form, and saved them without making any changes, and the problem seems to have gone away.
It's probably worth noting that this content was created under Drupal 5, and then the site was upgrades to Drupal 6. But this error was only recently noticed. (That doesn't guarantee it hasn't been there all along...)
So... my problem is solved, but there is still the mystery of why exactly it went wrong in the first place. I'll leave this open in case maintainers want to ask for follow-up info; but feel free to close.
Comment #2
markus_petrux CreditAttribution: markus_petrux commentedSee if the following issue can help you figure out the cause: #493068: Warning and cck values doesn't stored
Comment #3
racalvin CreditAttribution: racalvin commentedI 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?
Comment #4
markus_petrux CreditAttribution: markus_petrux commented@racalvin: You should report your issue to the SWFTools module.
Comment #5
matt2000 CreditAttribution: matt2000 commentedNo, #493068: Warning and cck values doesn't stored is not related. I did find that issue, and verified it was not the case for me before I discovered my own solution.
I still suspect the issue arose during the upgrade from D5. So the moral of the story: check all your content types after upgrade, and do as I did in comment #1 if you encounter errors.
Comment #7
davemybes CreditAttribution: davemybes commentedI 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.
Comment #8
matt2000 CreditAttribution: matt2000 commentedThe fix I reported in #1 apparently is only temporary. The problem keeps recurring, even with new content (post-upgrade.)
I'm re-opening, although I am also upgrading to 2.6 at the same time. If anyone can confirm the problem is resolved in 2.6, please do.
Comment #9
nsyll CreditAttribution: nsyll commentedsubscribe
Comment #10
matt2000 CreditAttribution: matt2000 commentedThe problem still exists in 2.6. Haven't yet figured out the source of it. :-(
Comment #11
Spillerspoiler CreditAttribution: Spillerspoiler commentedThe 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:
Comment #12
neoliminal CreditAttribution: neoliminal commentedI'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.
Comment #13
neoliminal CreditAttribution: neoliminal commentedHave 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?
Comment #14
neoliminal CreditAttribution: neoliminal commentedConfirmed 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.
Comment #15
nirad CreditAttribution: nirad commentedsubscribing
Comment #16
matt2000 CreditAttribution: matt2000 commentednot using memcached here. I'm currently under the impression that this is somehow is caused by subscriptions module, since this issue has not recurred, to my knowledge, since we disabled it. Anyone else using subscriptions?
Comment #17
neoliminal CreditAttribution: neoliminal commentedWe 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.
Comment #18
vkr11 CreditAttribution: vkr11 commentedSubscribe,
Just noticed this on one of the site, will continue to dig further (using 6.14 & cck 2.6 )
Comment #19
davemybes CreditAttribution: davemybes commentedI never used Memcached or Subscriptions modules, and haven't seen a recurrence of this problem since my original post (#7).
Comment #20
markus_petrux CreditAttribution: markus_petrux commentedHere'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.
Comment #21
cgs CreditAttribution: cgs commentedhttp://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。
Comment #22
ezra-g CreditAttribution: ezra-g commentedMarked #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.
Comment #23
ezra-g CreditAttribution: ezra-g commentedI 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.
Comment #24
dmotilla CreditAttribution: dmotilla commentedHi,
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.)
Comment #25
so4 CreditAttribution: so4 commentedHi,
Saving the configuration of the field again solved the issue for me.
Drupal 6 Site not upgraded from D5.
Comment #26
dazweeja CreditAttribution: dazweeja commentedTo 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:
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.
Comment #27
Anonymous (not verified) CreditAttribution: Anonymous commentedNo shared tables, Memcache or Subscriptions here, but installed Pecl/APC recently and this problem popped up. Saving the content type fixed it for now.
Comment #28
munyivanumber 1 helped me alot after trying all manner of stuff.
Comment #29
dmgl CreditAttribution: dmgl commentedHave the same problem.
Tried #1 #21 and #26 - didn't work.
6.20 settings.php:
Is there anything I can try?
Comment #30
Deathnerd CreditAttribution: Deathnerd commentedHello,
Im having the same issue on a fresh install of drupal 6.20. Here's the warning:
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
Comment #31
Renee S CreditAttribution: Renee S commentedEncountered this after installing APC. Re-saving the content type worked. Thanks :)
Comment #32
DigitalFrontiersMediaIn 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.
Comment #33
selinav CreditAttribution: selinav commentedHello, 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.
Comment #34
Robin van Emden CreditAttribution: Robin van Emden commentedI encountered this problem in my Aegir based single sign-on install.
I was able to fix it using '' for default prefix, following #21:
Though I am still left wondering why setting the default table prefix might have this effect?
Comment #35
joelbox-Mondial-IT CreditAttribution: joelbox-Mondial-IT commentedwithout 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
Comment #36
mdorrell CreditAttribution: mdorrell commentedWe 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?
Comment #37
Ator CreditAttribution: Ator commentedIt 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.',
);
Comment #38
rooby CreditAttribution: rooby commentedThis 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.
Comment #39
kubrt CreditAttribution: kubrt commentedSubscribing, using Memcache and APC, programatically creating nodes sometimes results in this error and creation of a blank nodes in the node table.
Comment #40
rooby CreditAttribution: rooby commented@kubrt:
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.
Comment #41
robin_b CreditAttribution: robin_b commentedA 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.
Comment #42
geerlingguy CreditAttribution: geerlingguy commentedLike #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!