I am trying to migrate my CCK types in D6 to D7 Fields using content_migrate, so far, all except one type could be migrated. When I migrate a cck field of type text using an optionswidget in D6, trying to display the node in D7 results in a server reset:

In Chrome the message is "No data received ERR_EMPTY_RESPONSE", Firefox says "Secure Connection Failed The connection to the server was reset while the page was loading". The server log is completely empty for loading this page, so I guess php dies pretty early.

I have tracked this down to exactly this optionwidgets field by rolling back and migrating all fields 20+ one by one, no other field type causes such behaviour.

Some interesting detail: Rolling back the field in drush will immediately display the page in the Browser, without needing to reload the page. (Ajax?)

field_sex   list_text   RNAi Changed field type: The 'field_sex' field uses a 'optionwidgets_buttons' widget. 
The field type will be changed from 'text' to 'list_text'.

This is the output of from the migration process of this field:

Changed field type: The 'field_sex' field uses a 'optionwidgets_buttons' widget. The field type will be changed from 'text' to 'list_text'.
Created field field_sex
Created instance of field_sex in bundle RNAi.

The behavior can be fully each time reproduced by rolling back this field (node works again), and re-migrating (server error). So I am quite sure it depends on the migrated options field. I do not see a server reset anywhere else on my migrated site.

More details about what I have tried:

  • I have checked the configuration of the generated option field at admin/structure/types/manage/rnai-experiment/fields/field_sex
    It looks normal.
  • I have created a new content type in D7 using an options field with check boxed, that worked
  • I have compared fields_data_field_ and fields_revisions_field_ entries for the nodes that do not work with the new options, they look good
  • cleared the caches, no pending dbupdates, disabled-enabled the options module, vacuumed the database
  • enabled all debugging output in the Devel module (kromo) including queries

I hope someone can help me because I am completely out of options, and I cannot complete the migration without the data. Any pointer, workaround, or hint on how to debug this is very welcome. Please let me know if any more information is required.

More details below:
----------------------------------------------------------------------------------
This is run on a Centos 6 cloned test instance from the production, Apache/2.2.15 (Unix), PHP 5.3, PostgreSQL 8.4, updates completed, no pending db updates,
this is a Tripal instance. Core Options Enabled 7.41, CCK version 7.x-3.0-alpha3, I can add a full module list if that is required.

Following some SQL queries for one of the affected nodes, it looks very normal:

d7=# select * from node_revision where nid = 761442;
  nid   |  vid   | uid |      title       | log | timestamp  | status | comment | promote | sticky 
--------+--------+-----+------------------+-----+------------+--------+---------+---------+--------
 761442 | 761447 |  39 | Neverland AD F 1 |     | 1447762864 |      1 |       2 |       0 |      0

d7=# select * from field_data_field_sex where entity_id = 761442;
 entity_type |     bundle      | deleted | entity_id | revision_id | language | delta | field_sex_value 
-------------+-----------------+---------+-----------+-------------+----------+-------+-----------------
 node        | rnai_experiment |       0 |    761442 |      761447 | und      |     0 | female

d7=# select * from field_revision_field_sex where entity_id = 761442;
 entity_type |     bundle      | deleted | entity_id | revision_id | language | delta | field_sex_value 
-------------+-----------------+---------+-----------+-------------+----------+-------+-----------------
 node        | rnai_experiment |       0 |    761442 |      761447 | und      |     0 | female

Settings of this field at:

admin/structure/types/manage/rnai-experiment/fields/field_sex
--------------------------------------------------------
Label *: Sex

Required field

Help text: Enter the sex of the sample organism, if applicable.

DEFAULT VALUE: None

Field visibility and permissions: Public

Number of values: 1

Allowed values list:
female|female
male|male
both|both
unknown|unknown

Edit: adding the dblog output for loading the page for which the server responds with no data.

/admin/reports/dblog
-----------------------------------------------------------------------------
Notice: Undefined index: granularity in date_formatter_process() (line 250 of /home/licebase/d7/sites/all/modules/date/date.module).
Notice: Undefined index: todate in date_process_values() (line 358 of /home/licebase/d7/sites/all/modules/date/date.module).
Notice: Undefined index: tz_handling in date_formatter_process() (line 233 of /home/licebase/d7/sites/all/modules/date/date.module).
Notice: Undefined index: granularity in date_granularity() (line 347 of /home/licebase/d7/sites/all/modules/date/date.module).
Notice: Undefined index: access in user_reference_field_formatter_prepare_view() (line 392 of /home/licebase/d7/sites/all/modules/references/user_reference/user_reference.module).
Notice: Undefined index: access in user_reference_field_formatter_prepare_view() (line 380 of /home/licebase/d7/sites/all/modules/references/user_reference/user_reference.module).
Notice: Undefined index: access in node_reference_field_formatter_prepare_view() (line 408 of /home/licebase/d7/sites/all/modules/references/node_reference/node_reference.module).
Notice: Undefined index: access in node_reference_field_formatter_prepare_view() (line 396 of /home/licebase/d7/sites/all/modules/references/node_reference/node_reference.module).

That is the only output that I could find so far that is generated during page loading.

Comments

LiceBaseAdmin created an issue. See original summary.

LiceBaseAdmin’s picture

Issue summary: View changes
LiceBaseAdmin’s picture

Issue summary: View changes
LiceBaseAdmin’s picture

This is caused only by the widget optionwidgets_button, not with the optionwidgets_select. So change the widget type to anything else in the content_node_field_instance table in SQL and re-do the field migration. Then it works for me at least.

LiceBaseAdmin’s picture

LiceBaseAdmin’s picture

Unfortunately, the work-around doesn't work. After doing the migration like this, all content for the field is missing, and whenever a node is edited and content is saved for this field, the node becomes invalid again. That means that in principle, optionwidgets content cannot be safely migrated!

LiceBaseAdmin’s picture

Priority: Minor » Critical

Setting this to critical because having such field can result invalid server state and data-loss.

LiceBaseAdmin’s picture

Issue summary: View changes

Added output from /admin/reports/dblog so a little bit is being loaded.

LiceBaseAdmin’s picture

Issue summary: View changes
LiceBaseAdmin’s picture

LiceBaseAdmin’s picture

Priority: Critical » Minor

We finally resolved this one. After migrating the offending field,
I went to adjust field display:
admin/structure/types/manage/[our-content-type]/display and changed the settings in the Label column from "Above" to "<Hidden>", Saved,
changed Label back to "Above" and saved again. Then the display works.

We have done the field migration many times from the same data dumps and it always results in this behaviour, which can be resolved each time as described above. I am guessing that the migration generates some display settings that break the display, when the display is changed, valid settings overwrite the ones stored from the migration. Otherwise, I don't have a clue why this works.