Ok, so, I cannot reproduce this but in a client setup. D5 to D6 is ok, no problems in there but, once I try to migrate two of the multiple fields I have:

  • 1st - field_news_bilder file News Changed field type: The 'field_news_bilder' field type will be changed from 'filefield' to 'file'.
    Missing formatter: The 'image_plain' formatter used in 2 view modes for the field_news_bilder field is not available, these displays will be reset to the default formatter.
    Missing formatter: The '' formatter used in 1 view modes for the field_news_bilder field is not available, these displays will be reset to the default formatter.
  • 2nd- Details field_bilder file Page Projekt Caution: The 'field_bilder' field is a shared field that uses different widgets. The 'filefield_widget' widget is sometimes used to determine the destination field type for the new field. The migration may not work correctly if other widgets used by this shared field would create different results.
    Changed field type: The 'field_bilder' field type will be changed from 'filefield' to 'file'.
    Missing widget: The 'image' widget is not available for the field_bilder field, it will be set to the default widget.
    Missing formatter: The '' formatter used in 1 view modes for the field_bilder field is not available, these displays will be reset to the default formatter.
    Missing formatter: The 'image_plain' formatter used in 2 view modes for the field_bilder field is not available, these displays will be reset to the default formatter.
    Missing formatter: The '' formatter used in 1 view modes for the field_bilder field is not available, these displays will be reset to the default formatter.

It gives the following result (the scripts seam to be interrupted):

Migrating data

Field migration has encountered an error.
Please continue to the error page
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /projects/7.x/batch?id=8&op=do StatusText: Internal Server Error ResponseText:

Since nothing else is present on the Error Response, I have analysed the logs:

Some help would be awesome. I've tried the code changes in http://drupal.org/files/cck-remove_php_notice_max_filesize_per_file.patch and http://drupal.org/files/cck-remove_php_notice_list_field.patch with no positive outcome, and the errors are the same.

Hope this can be figured out soon!

*edit: sorry about the title... didn't knew what to put

Comments

dman’s picture

Generally, a missing formatter or widget is non-fatal - the description describes what will be done instead, and that's annoying, but OK.

Also, a 'notice' level PHP error is noise, but also non fatal.

In my experience (doing a huge D7 upgrade this month) those clues are something to look at ... but possibly not the ACTUAL problem you've got right now.
:-(

Diagnostics I used were - looking at the actual webserver/PHP logs - not watchdog
and then I ended up running the upgrade from the commandline using drush, with verbose debugging on.

different types of errors leave messages in different places. I can't say at this point what your real issue is.

nmpribeiro’s picture

Thanks dman,

user@WebDev:~$ tail -f /var/log/apache2/error.log
[Fri May 17 13:34:18 2013] [error] [client 192.168.50.45] PHP Warning: Cannot use a scalar value as an array in /var/www/projects/7.x/modules/locale/locale.module on line 724
[Fri May 17 13:43:22 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=5
[Fri May 17 13:44:10 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=7
[Fri May 17 13:52:10 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=8
[Fri May 17 14:07:33 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=9
[Fri May 17 14:10:02 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=10
[Fri May 17 14:12:38 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=10
[Fri May 17 14:12:52 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=11
[Fri May 17 14:15:02 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=12
[Fri May 17 14:32:35 2013] [error] [client 192.168.50.45] PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615, referer: http://192.168.50.62/projects/7.x/batch?op=start&id=13

Can you give me a drush command to migrate a field? or better, a resource for me to read it? I really want to get more diagnose info on this.

dman’s picture

That error report is just right, and shows that something (sorry, I don't know what) is what has been crashing the process.
Yep, fatals are bad.

If you are already comfortable with drush...
and you have a working D7 site so far, just waiting for fields to be migrated. (I would actually roll back to before you tried the failed conversion, because a crash will have left it in an incomplete way)
Then the command is

  drush content-migrate-fields 

also,

drush help | grep content-migrate

will tell you what 4 actions available, and the help for each tells you some arguments, as usual.

In my experience - which is too huge to go into on this project - I found I had to do my migration steps in batches ... First do this, this and this from core, then that, that and that from a stable contrib, (snapshot the DB in between) then try a few of the more "out-there" fields and modules to find what's actually breaking.

Sorry, I can only pass on general hints. None of the 'fixes' I found were very general or explicable, and I lost a few days on tracing them.

dman’s picture

and "verbose debugging" is the drush flags -v and -d respectively

nmpribeiro’s picture

Thank you dman, your help is already awesome.

I don't know if I should put my output from drush verbose command, to migrate those two fileds (the others went well already so... I did them through drupal web interface prior to issue the drush command).

so... to see WHOLE output: http://justpaste.it/2n7w
Here I will only put the errors:

Migrating structure for field_bilder [8.32 sec, 17.96 MB] [status]
Undefined index: label content_migrate.values.inc:177 [8.44 sec, 20.3 MB] [notice]
Undefined index: full content_migrate.values.inc:231 [8.44 sec, 20.31 MB] [notice]
Undefined index: label content_migrate.values.inc:177 [8.44 sec, 20.4 MB] [notice]
Undefined index: full content_migrate.values.inc:231 [8.44 sec, 20.4 MB] [notice]
Undefined index: label content_migrate.values.inc:177 [8.44 sec, 20.41 MB] [notice]
Undefined index: full content_migrate.values.inc:231 [8.44 sec, 20.41 MB] [notice]
PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc, line 615 [8.44 sec,
17.94 MB]
The external command could not be executed due to an application error. [8.48 sec, 17.93 MB] [error]

Migrating structure for field_news_bilder [7.74 sec, 16.15 MB] [status]
Undefined index: label content_migrate.values.inc:177 [7.89 sec, 20.22 MB] [notice]
Undefined index: full content_migrate.values.inc:231 [7.89 sec, 20.23 MB] [notice]
Undefined index: label content_migrate.values.inc:177 [7.9 sec, 20.32 MB] [notice]
Undefined index: full content_migrate.values.inc:231 [7.9 sec, 20.32 MB] [notice]
Undefined index: label content_migrate.values.inc:177 [7.9 sec, 20.33 MB] [notice]
Undefined index: full content_migrate.values.inc:231 [7.9 sec, 20.33 MB] [notice]
PHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 615
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc, line 615 [7.91 sec,
18.11 MB]
The external command could not be executed due to an application error. [7.94 sec, 18.09 MB] [error]

dman, of course, all my work is being saved and backuped every step I do (almost) so no data has been lost. I have a pre-TheseTwoFieldsMigration sql backup, so I think I'm safe to play around this issue.
I'll google for these field.crud.inc line 615 error... since it's the actual Fatal Error culprit.
if you know something just drop a comment.

nmpribeiro’s picture

Ok...
drush content-migrate-field-structure field_not_being_migrated_properly
drush content-migrate-field-data field_not_being_migrated_properly

The structure command gives me error (as my previous comment states).
The data command from drush actually works well, so I guess it's a structure issue.

Can you point me how to divide this migration of structure even further?

I think I am not going to wait for any fix... if it happens, great, if not, I will try to understand this and post here any advance I make. We're on D7 for some while now, and this hasn't been fixed so... should I wait? What are the odds?
I will read from the drush content-migrate-field-structure command source code. It's my best bet to understand what it does.

Thanks in advance for any help - hope this is usefull for others as well.

dman’s picture

It comes down the the exact field now, and whether this field has full upgrade support, or has been slightly mangled, or (in my case) was operating on slightly inconsistent data - I had dupes in my file table.

I'll guess that your *_bilder are image fields... filefield in D6 becomes just 'file' in D7.

If your D7 version is close to 7.22, the actual error line is complaining about :

 $instance['widget']['settings'] += field_info_widget_settings($instance['widget']['type']);

... means that I guess it's trying to invoke a widget that doesn't really exist - assuming that it's field_info_widget_settings() returning NULL.

Personally, It's drop a debug line into there just before it fires - if using drush then the following would be adequate.

if ($instance['field_name'] == 'field_news_bilder') {
  print_r(get_defined_vars());
}

But I can't tell you what to look for, it becomes a bit seat-of-the-pants debugging to know what looks suspicious in that dump of data.

Best case scenario would be that you need an extra rendering module that takes care of it.
Medium case is that you just have to skip this field and remake it by hand on the D7 site, then import the data yourself, either manually or using something like node_import :-}

nmpribeiro’s picture

Well, I've just been reading and debugging this module's source code... and found that in ckk/modules/content_migrate/includes/content_migrate.admin.inc in line 246:

$instance_values = content_migrate_get_instance_values(NULL, $field_name);

foreach ($instance_values as $bundle => $instance_value) {
try {

if (isset($instance_value['messages'])) {
$messages = array_merge($messages, $instance_value['messages']);
unset($instance_value['messages']);
}

if (!isset($instance_info[$bundle][$field_name])) {
$instance = field_create_instance($instance_value); -> it gives the error
$context['instances'][$field_name][$bundle] = $instance;
$messages[] = t("Created instance of @field_name in bundle @bundle.", array(
'@field_name' => $field_name, '@bundle' => $type_names[$bundle]));
}

}

Checking further...:
if (!isset($instance_info[$bundle][$field_name])) {
drush_log("Inside second IF");
drush_log(json_encode($instance_value));
$instance = field_create_instance($instance_value);

JSON of that $instance_value:

{
"field_name": "field_news_bilder",
"weight": "3",
"label": "News [notice]
Images",
"widget_type": "filefield_widget",
"description": "",
"entity_type": "node",
"bundle": "news",
"default_value": "",
"widget": {
"type": "file_generic",
"weight": "3",
"module": "file",
"active": "0",
"settings": {
"max_resolution": "450x1000",
"image_path": "",
"custom_alt": 0,
"custom_title": 0,
"teaser_preset": null,
"body_preset": null,
"default_image": null,
"use_default_image": 0,
"progress_indicator": "bar",
"min_resolution": "0",
"alt": "",
"title": "",
"title_type": "textfield"
}
},
"display": {
"Teaser": {
"label": null,
"type": "image_plain",
"weight": "3",
"settings": [],
"module": "filefield"
},
"Full": {
"label": null,
"type": "image_plain",
"weight": "3",
"settings": [],
"module": "filefield"
},
"default": null
},
"settings": {
"file_directory": "",
"file_extensions": "png
gif jpg jpeg",
"max_filesize": ""
}
}

http://api.drupal.org/api/drupal/modules!field!field.crud.inc/function/f...
I'm trying to understand this, but if I change $instance = field_create_instance($instance_value); => $instance = field_create_instance($instances_value);

It finalizes.... but with the error:
Error creating instance of field_news_bilder in bundle News. [0.45 [error]
sec, 18.14 MB]
exception 'FieldException' with message 'Attempt to create an [error]
instance of a field that doesn't exist or is currently inactive.' in
/var/www/projects/7.x/modules/field/field.crud.inc:474
Stack trace:
#0
/var/www/projects/7.x/sites/all/modules/cck/modules/content_migrate/includes/content_migrate.admin.inc(266):
field_create_instance(NULL)

so.... this $instances_value is null... i'll further try to debug

nmpribeiro’s picture

I see... well, it's a fileField CCK 6.x file field, with File Uplad widget (I've changed Image to FUpload in an attempt to be more acertive)...

I'll check further... but we're talking about hunderds of nodes and 1500 images... hard to re-do it, but that node_import might be worth a look

nmpribeiro’s picture

Ok, output from that print_r:

Array
(
[instance] => Array
(
[field_name] => field_news_bilder
[weight] => 3
[label] => News Images
[widget_type] => filefield_widget
[description] =>
[entity_type] => node
[bundle] => news
[default_value] =>
[widget] => Array
(
[type] => file_generic
[weight] => 3
[module] => file
[active] => 0
[settings] => Array
(
[max_resolution] => 450x1000
[image_path] =>
[custom_alt] => 0
[custom_title] => 0
[teaser_preset] =>
[body_preset] =>
[default_image] =>
[use_default_image] => 0
[progress_indicator] => bar
[min_resolution] => 0
[alt] =>
[title] =>
[title_type] => textfield
)

)

[display] => Array
(
[Teaser] => Array
(
[label] =>
[type] => image_plain
[weight] => 3
[settings] => Array
(
)

[module] => filefield
)

[Full] => Array
(
[label] =>
[type] => image_plain
[weight] => 3
[settings] => Array
(
)

[module] => filefield
)

[default] =>
)

[settings] => Array
(
[file_directory] =>
[file_extensions] => png gif jpg jpeg
[max_filesize] =>
[description_field] => 0
[user_register_form] =>
)

[field_id] => 35
[required] =>
[deleted] => 0
)

[update] =>
[field] => Array
(
[type_name] => news
[entity_types] => Array
(
)

[settings] => Array
(
[description_field] => 0
[display_field] => 0
[display_default] => 1
[uri_scheme] => public
)

[translatable] => 0
[storage] => Array
(
[type] => field_sql_storage
[settings] => Array
(
)

[module] => field_sql_storage
[active] => 1
)

[foreign keys] => Array
(
[fid] => Array
(
[table] => file_managed
[columns] => Array
(
[fid] => fid
)

)

)

[indexes] => Array
(
[fid] => Array
(
[0] => fid
)

)

[id] => 35
[field_name] => field_news_bilder
[type] => file
[module] => file
[active] => 1
[locked] => 0
[cardinality] => 1
[deleted] => 0
[columns] => Array
(
[fid] => Array
(
[description] => The {file_managed}.fid being referenced in this field.
[type] => int
[not null] =>
[unsigned] => 1
)

[display] => Array
(
[description] => Flag to control whether this file should be displayed when viewing content.
[type] => int
[size] => tiny
[unsigned] => 1
[not null] => 1
[default] => 1
)

[description] => Array
(
[description] => A description of the file.
[type] => text
[not null] =>
)

)

)

[field_type] => Array
(
[label] => File
[description] => This field stores the ID of a file as an integer value.
[settings] => Array
(
[display_field] => 0
[display_default] => 0
[uri_scheme] => public
)

[instance_settings] => Array
(
[file_extensions] => txt
[file_directory] =>
[max_filesize] =>
[description_field] => 0
[user_register_form] =>
)

[default_widget] => file_generic
[default_formatter] => file_default
[module] => file
[default_token_formatter] => file_url_plain
)

[widget_type] => Array
(
[label] => File
[field types] => Array
(
[0] => file
)

[settings] => Array
(
[progress_indicator] => throbber
)

[behaviors] => Array
(
[multiple values] => 4
[default value] => 1
)

[module] => file
)

)

nmpribeiro’s picture

[module] => file
)

)
Inside Mian Drupal file.crud.inc line 627, foreach loopInside Mian Drupal file.crud.inc line 627, foreach loopInside Mian Drupal file.crud.inc line 627, foreach loopPHP Fatal error: Unsupported operand types in /var/www/projects/7.x/modules/field/field.crud.inc on line 632
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Unsupported operand types in
/var/www/projects/7.x/modules/field/field.crud.inc, line 632
[0.29 sec, 16.06 MB]

field.crud.inc:
line 626 - 632
626: foreach ($instance['display'] as $view_mode => $display) {
627: print_r("Inside Main Drupal file.crud.inc line 627, foreach loop");
628: $display += array(
629: 'label' => 'above',
630: 'type' => isset($field_type['default_formatter']) ? $field_type['default_formatter'] : 'hidden',
631: 'settings' => array(),
632: );

So, 3 foreach loops in instance['display'] and it breaks at fourth display foreach cycle...

nmpribeiro’s picture

Issue summary: View changes

*title seams not adequate

nmpribeiro’s picture

Ok

Resolution:

Create the same fields with the same exact name (in my case "field_news_bilder") so, call it "News Bilder" and then the D7 field machine name got exactly as the one in D6, and gave it the same label. This created the structure in D7 (since when I issued command "drush content-migrate-field-structure field_not_being_migrated_properly" it failed, this will work the rebuilding of the structure). Now, one thing is missing: data!

Drush command "drush content-migrate-field-data problematic_field" will do the trick, provided the machine name is the same. I was able to rebuild all data model with D6 content through this way.

Hope this helps others with the same issue. In the end, it was rather simple.
However, this migration module is not 100% functional. I was not able to pinpoint the exact problem with it. The above information might be usefull for this module developers if they do get interested in fixing this - just ask me for any D6 db table related with this issue and I am glad to send privately.

Thanks dman!

dman’s picture

Wow, that resolution actually makes sense.

In the UI, the conversion of field structure and data happens as one step, so it's interesting to see that with drush the two phases are different.

In brief:

- if you are getting an error migrating the STRUCTURE
* build the field yourself with the exact same name using the normal UI
* see if you can then migrate just the DATA from old field to new field

Yup, that's sensible!

burgs’s picture

I had the same error, and without digging too much into what was missing from the display array, I managed to stop the fatal error by adding in

$display = (array) $display;

after

foreach ($instance['display'] as $view_mode => $display) {

on about line 626

I didn't get any data come through, but I'll have to check if that was because there was none there previously.

burgs’s picture

Issue summary: View changes

remove id of project

asPagurus’s picture

Hello.
I had the same error. But in my case I have two field with images. One were converted but another - weren't.
I went to phpMyAdmin and copied content of field 'display_settings' in table 'content_node_field_instance' from "good" field to "broken" (they have the same widget) and all my problem solved)

rfay’s picture

Category: Bug report » Support request
Priority: Critical » Major
Issue summary: View changes