array_merge() [function.array-merge]: Argument #2 is not an array in content.module on line 716

Can anyone confirm whether or not this is still happening with php5 in latest version? There have been numerous changes since this report was filed, so even if it's still happening, the line number will have changed.

I'm not experiencing it with php5.

@stanbroughl, can you reconfirm... maybe a debug_backtrace from that line so we can see if the call is originating from another module.

I'm completely new to all this having just begun to look at Drupal in the last few days. I downloaded the most current released versions of everything, including the CCK on Friday 8th December, 2006. I am using PHP 5 and, according to other advice on the site though I am using MySQL 5 I have set it to run as MYSQL40. I'm running on Debian Sarge, using the PHP5 packages from dotdeg.org. And I do get these error messages - or very similar anyway - in my case they occur on line 733 and 746 of content.module Not sure if they are causing problems yet - the content type still seems to have been created and is editable.

I wonder if this is related to http://drupal.org/node/102556. The value that does not seem to be an array is the $info value and that other issue reports a problem with the $info value not getting set correctly in php 5. I can't replicate either of these issues yet, but they look like they might be related.

That related issue was someone who didn't get the database updated properly from an earlier version, so that is unrelated to the errors reported by jockox3, since that was a new installation, so I don't think that other issue is a factor.

Still unable to reproduce this. Anyone else seeing it who can provide more info??

I also got this:

# warning: array_merge() [function.array-merge]: Argument #2 is not an array in D:\Websites\wwshopper.com\wwwroot\drupal\modules\cck\content.module on line 733.
# warning: array_merge() [function.array-merge]: Argument #1 is not an array in D:\Websites\wwshopper.com\wwwroot\drupal\modules\cck\content.module on line 746.

when I'm in q=admin/node/types/content_relation_type/fields after saving changes to the field.

According to http://www.php.net/manual/en/function.array-merge.php

The behavior of array_merge() was modified in PHP 5. Unlike PHP 4, array_merge() now only accepts parameters of type array.

The solution is also there and simple. Typecast all of the parameters to be arrays.

Change line 733 from $field = array_merge($field, $global_settings); to $field = array_merge((array)$field, (array)$global_settings);

And change line 747 from $field = array_merge($info['fields'][$field['field_name']], $field); to $field = array_merge((array)$info['fields'][$field['field_name']], (array)$field);

The line numbers are correct for the version I have. Your numbers may very.

This is a simple fix but I don't know if there are other issues with this as to why the parameters aren't arrays.

OK, trying to sort things a little :
Line 714 in stanbroughl's original report back is September is now line 733 reported by rocnhorse and jockox3 :
$field = array_merge($field, $global_settings);
I don't know about stanbroughl's line 716 - never was an array_merge in there.

The other error in line 747 is a consequence from the one in 733. So we should fix the one in 733.
Technical stuff below, non-tech readers can skip to last paragraph :-)

The code is the following :

$field_result = db_query('SELECT * FROM {node_field} nf');
while ($field = db_fetch_array($field_result)) {
  $global_settings = $field['global_settings'] ? unserialize($field['global_settings']) : array();
  $field = array_merge($field, $global_settings);
  ...
}

$field is necessarily an array - no doubt about that.
$global_settings might not be an array if the 'global_settings' column in the node_field table does not contain serialized data for an array. BUT looking at the code that inserts / updates this table, it seems that this can not happen.
So this is strange :-)

In short :
I committed a fix that checks if $global_settings is an array before merging (I think it is safer to do nothing instead of casting the invalid data to an array and keeping it)
@rocnhorse, jockox3 & stanbroughl : can you check last version of CCK and see if the problem is still here ?

I'm trying to backtrack through the code to see how global_settings could ever possibly not be an array, and I agree with yched, it doesn't appear this is possible, so this is very strange. The only thing I can see would be if we have a malformed field module that is not providing the right info in its field_settings hook, so I think it is important to identify what field modules were being enabled when the error was thrown.

I'm leaving yched's workaround in there until we nail this down, but I'd like to get this fixed correctly which we can only do if we know for sure which field modules were involved.

I did some more testing with this and it seem that this isn't a "bug" in CCK but it isn't handling bad data elegantly.

I have subform installed and the fields that it creates in it's .install are incorrect.

If unserialize($field['global_settings']) fails because of bad data, it returns FALSE. This then causes array_merge to fail.

I'm moving my issue over to http://drupal.org/node/101985 to fix the insert statements in the subform.install.

The only change to content.module would be error handling for bad serialization.

yched's patch makes sure that content.module won't fail if the field passes it bad data, so I think this is resolved from the standpoint of the content module.