Problem/Motivation

Currently when you try to login after a full migration there is a fatal error on the user edit page. Specifically:

Notice: Undefined index: third_party_settings in Drupal\Core\Field\WidgetPluginManager->createInstance() (line 130 of core/lib/Drupal/Core/Field/WidgetPluginManager.php).

Recoverable fatal error: Argument 5 passed to Drupal\Core\Field\WidgetBase::__construct() must be of the type array, null given, called in core/lib/Drupal/Core/Field/WidgetPluginManager.php on line 130 and defined in Drupal\Core\Field\WidgetBase->__construct() (line 55 of core/lib/Drupal/Core/Field/WidgetBase.php

Proposed resolution

I tried adding this to the d6_user_profile_entity_form_display migration as you would expect but it just wouldn't stick. I also tried adding tests for third_party_settings but that wouldn't fail within the test runner. Patch attached just ensures it's set in the destination which did in the end fix the problem but might not be the right approach.

Remaining tasks

User interface changes

API changes

CommentFileSizeAuthor
#12 2394615-10.patch4.51 KBbenjy
#9 2394615-9-FAIL.patch1.94 KBbenjy
#9 2394615-9.patch3.85 KBbenjy
#8 2394615-8.patch3.18 KBbenjy
#6 mike_test_dec23.txt16.88 KBultimike
#5 manifest.yml2.07 KBbenjy
#5 d6.sql_.gz68.24 KBbenjy
tps.patch1.09 KBbenjy

Comments

chx’s picture

chx commented
Status: Needs review » Needs work 
+//      $row->setDestinationProperty('options', $options);
benjy’s picture

benjy commented

It would be great if someone else could also test this, I could not get this to work by simply putting third_party_settings in the profile fields entity form display migration.

Maybe it's better in the destination anyway since without it, you get a fatal error when viewing the entity edit screen.

The last submitted patch, tps.patch, failed testing.

ultimike’s picture

ultimike
Primary language English
Location Florida, USA
commented

Benjy,

I couldn't reproduce the fatal error (without the patch). Here's what I did:

  • Started with a fresh Drupal 6 site with several users (including 2 profile fields), content types, and nodes.
  • Ran a full migration.
  • Logged into the Drupal 8 site as each migrated user, visited their edit account (user/[uid]/edit) page.

Did I miss something?

-mike

benjy’s picture

benjy commented
StatusFileSize
new d6.sql_.gz68.24 KB
new manifest.yml2.07 KB

@ultimike, hmm that's interesting. I've attached my manifest and the database i used if you want to have a test with that. Maybe the error is specific to certain field types on the user. I did keep seeing boolean_checkbox, maybe try adding that field your current setup as well?

ultimike’s picture

ultimike
Primary language English
Location Florida, USA
commented
StatusFileSize
new mike_test_dec23.txt16.88 KB

Benjy,

Just adding a D6 profile checkbox field to my local D6 test site doesn't cause the D8 user edit page to WSOD.

I then tried it with your D6 DB and my go-to full migration .yml file - still, no WSOD.

Finally, I tried it with your D6 DB and your manifest.yml, and couldn't get the migration to complete. I enabled the book module, but the migration still failed. I've attached my output.

-mike

benjy’s picture

benjy commented

The last fatal you got is fixed by #2394567: File field need associated metadata during cck_field migration

The other errors are, link module not enabled, missing files and a known error (without an issue) for the bundle promote setting migration.

I'll have another go at debugging this next week.

benjy’s picture

benjy commented
Status: Needs work » Needs review
StatusFileSize
new 2394615-8.patch3.18 KB

OK, the attached patch also fixes the issue by changing the migrations. Seems like it could be good in the destination since it might be easy for custom migrations to slip up.

Hopefully have a test coming soon.

benjy’s picture

benjy commented
StatusFileSize
new 2394615-9.patch3.85 KB
new 2394615-9-FAIL.patch1.94 KB

OK, tracked this down to the user picture and upload fields. Fail patch attached + tests and fix.

The last submitted patch, 9: 2394615-9.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 9: 2394615-9-FAIL.patch, failed testing.

benjy’s picture

benjy commented
Status: Needs work » Needs review
StatusFileSize
new 2394615-10.patch4.51 KB

That seems like a random fail UserAdminTest?

I've added the fix for d6_user_profile_entity_form_display as well.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Unless you actually have third party settings to store, I think its fine to init as empty as leave as-is. On a quick grep I did not find a user of entity display level third party settings in core, so it seems to be a contrib extension point.

+++ b/core/modules/migrate_drupal/config/install/migrate.migration.d6_user_profile_entity_form_display.yml
@@ -9,6 +9,8 @@ source:
+#    options:
+#      third_party_settings: {}

Why are you adding this commented out?

benjy’s picture

benjy commented
Status: Needs review » Needs work

They're commented out because I can't get a test to fail yet that proves they're needed but without them, testing a real migration does end up leaving your site with this error.

I have a feeling that this entire issue could be solved by #2220559: Entity displays must have a settings array

benjy’s picture

benjy commented
Status: Needs work » Closed (duplicate)
Related issues: +#2220559: Entity displays must have a settings array

I did say in IRC that I thought this was more likely a core bug that the Migrate API exposed and I think that was right. I updated that patch here: https://www.drupal.org/node/2220559#comment-9525761 and that fixes all the problems here with test coverage.

Closing as duplicate unless there is some push back from entity people to initialise third_party_settings for some reason.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Issue tags: +SprintWeekend2015

Retrospective sprint weekend tagging.