Fatal error: Cannot unset string offsets [#989254]

Just was bitten by this issue. Error:

Fatal error: Cannot unset string offsets in /var/www/drupal/sites/all/modules/cck/content.module on line 1248

This fatal error prevents to create or edit nodes of the affected content type, so this is a major issue.

Relevant modules (anything missing?):

Pressflow 6.19
CCK 6.x-2.8
Filefield 6.x-3.7
FileField Paths 6.x-1.4
FileField Sources 6.x-1.2
Imagefield 6.x-3.7
Imageapi 6.x-1.9
ImageCache 6.x-2.0-beta10

The function in line 1248 is:

/**
 * Invoke a field hook.
 *
 * For each operation, both this function and _content_field_invoke_default() are
 * called so that the default database handling can occur.
 */
...
    // Make sure AHAH 'add more' button isn't sent to the fields for processing.
    unset($items[$field['field_name'] .'_add_more']);

Any ideas?

Comments

Comment #1

asb commented 10 December 2010 at 18:32

I removed all CCK fields from the affected content type which are not part of CCK; now there are only two node reference fields and one textfield left, so this seems to have nothing to do with Filefield or Imagefield. The fatal error persists.

Watchdog log also another error when editing the affected content type:

Warning: htmlspecialchars() expects parameter 1 to be string, array given in check_plain() (line 1151 of /var/www/drupal/includes/bootstrap.inc).

I have no idea why this error is happening.

Update: I removed the CCK text field, and the error is gone. This is really weird ...

Anyone?

Thanks & greetings, -asb

Comment #3

rhymeswithcamera commented 18 December 2010 at 22:07

I just noticed this issue today. So far, it only seems to be affecting one content type (the one created by Content Profile). This type has a lot of CCK text fields - single-value and multi-value. One additional Watchdog error I received in Watchdog was:

Invalid argument supplied for foreach() in .../modules/cck/content.module on line 796.

Since we are still in development, I may just recreate the content type and hope the issue disappears. This would be a showstopper if we were in production.

Comment #4

AntiNSA commented 22 December 2010 at 14:23

Comment #5

Welsby commented 6 January 2011 at 12:31

I ran into this issue, turned out to be down to a coding mistake. I was trying to set..

$node->{$key} = 'whatever';
Instead of doing..
$node->{$key}[0]['value'] = 'whatever'

Which caused CCK to spit out this error upon being asked to node_save on the corrupted object. Because it's expecting to unset an array but it got a string. Could add a type check before the unset command, but if I'm passing it corrupted data to save it has every excuse to fatal error out on me.

Comment #6

rhymeswithcamera commented 6 January 2011 at 15:49

@Welsby, congrats on finding a resolution! As I was researching possible causes/resolutions for this issue, I did come across other issue threads where the cause was custom code - usually in hook_form_alter.

To date, I haven't found the cause for this error on my site, but I have stopped it from appearing - at least for the time being. The issue got so ugly at one point that I couldn't create or edit several content types.

Here's a quick snapshot of my development setup and what I did - just in case it helps anyone else:

Configuration: I don't have any custom code to review or fix. I do have about a dozen custom content types - the largest one being 'profile' (that uses Content Profile). Many of these content types share multiple fields - some fields are simple textfields/textareas, others are single- and multi-value selects. It was these 'sharing' content types that produced the error.

What I did:
(1) Tested for module conflicts: I disabled all my contrib modules, and started enabling them back one by one until the error reappeared. The only possible offender was Auto Nodetitles. Disabling Auto Nodetitles on my Content Profile type 'fixed' the issue for that type, but not others. So, in my mind, this wasn't the cause.
(2) Exported all custom content type definitions, and then deleted all the content types. I then went to the database to make sure there were no orphan tables or data. All the tables were gone, but there was several instances of orphan data. I deleted all of it. The idea was to reset my content type "stuff" back to "0."
(3) Imported all the type definitions back in. After several rounds of testing, I could not get the error to reappear. Success! But for extra measure...
(4) Removed shared fields to reduce the complexity and (potential) risk. I now have a lot more single-instance fields, but if this error appears again, it will hopefully be easier to isolate.

Perhaps with all the twisting-&-turning I've put these custom content types through during development, something got corrupted along the way. And hopefully the steps I took to start afresh 'fixed' the problem. Time will tell.