CCK field migration reproducibly results in server error on node display

Question

I am trying to migrate my CCK types to Fields using CCK module in D7, using content_migrate, following the documentation. After migrating all fields of a certain content types, I got a server reset when trying to view any node of this content type.

See also https://www.drupal.org/node/2665208

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 migrated all fields one by one and tracked it down to a text field that was using an optionwidgets_button widget in D6.

Edit: We found a second broken field. This field does not cause a server reset but a 'The website encountered an unexpected error' from Drupal upon display of any node where this field is set. This field is of type user_reference.

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

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

Rolling back the field suppresses the error; re-migrating this field fully reproduces the error.

no pending dbupdates, Postgres 8.4, PHP 5.3

Answer 1

We have now identified the source of the error. The content-migrate process seems to sometimes generate invalid display settings for fields. We have now seen this for two different fields. To identify the offending field, we did the following to debug:

• if possible, (you getting at least a drupal error) get a call stack, so that the offending field type and field name can be searched for (grep for 'field')
• to repair offending settings: go to admin/structure/types/manage/<data type>/display
• set each field <hidden> in the Label column (yes that is odd, but I guess this setting is enough to trigger generating fresh display settings)
• Save
• set each field back to original Label settings
• Save

If you want to find the culprit without stack trace, one could switch each field off, and reload the content.

I am not sure about the reason for why this works, but I suspect serialized data. Drupal uses a lot of serialized strings to store settings in the database, and the deserialization might not be robust against corrupted settings. I don't think this is really a bug in the migration code, but corrupted settings can occur at any time.

So I guess it might be a good idea to re-generate settings, in any case of a display error of custom content.