The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Currently {users}.data is not migrated.
Proposed resolution
Not a lot. The new UserData service stores semi structured data: it needs a $module and it needs a $key. Neither is easily attainable in an automated fashion.
We should write a contact settings migration and then contrib can use that as an example.
Remaining tasks
Write a UserData destination and a contact settings migration and test the whole shebang. Also, unserialize data in the user source.
The destination should have IDs $module, $uid, $name.
User interface changes
None.
API changes
We have a new destination. Rare!
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | interdiff.txt | 2.75 KB | benjy |
| #22 | 2268897-22.patch | 9.36 KB | benjy |
| #20 | interdiff.txt | 640 bytes | benjy |
| #20 | 2268897-20.patch | 8.16 KB | benjy |
| #17 | interdiff.txt | 1.41 KB | benjy |
Comments
Comment #1
chx commentedComment #2
ultimikeComment #3
moshe weitzman commentedComment #4
benjy commentedGoing to do this tomorrow.
Comment #5
benjy commentedI suggested that we simply add this functionality to the existing EntityUser destination so we're waiting on a response from someone who knows the Entity API as to why the user.data service is no longer injected into UserStorage.
https://www.drupal.org/node/597236#comment-9125225
Comment #6
chx commentedComment #7
chx commentedComment #8
benjy commentedThis should be a pretty simple task adding the new migration. Going to tag it Novice and then maybe use it in core mentoring unless someone wants to pick it up.
Comment #9
berdirYou also need a source that extracts from users.data, which is a seriailzed column. That source will have to read the column, unserialize it and provide all top-level keys (anything else would be too complicated I think?) dynamically as fields so that the migration then can pick one and put it into the destination.
Comment #10
benjy commentedHow about adding that to the existing user source?
Comment #11
chx commentedAgreed. Makes sense to use the users source.
Comment #12
benjy commentedPatch attached.
Comment #15
benjy commentedAdded schema for the D6 user source.
Comment #16
berdirThis looks good to me. There's still a TODO in the fields() method in the UserData destination but the implementation & migration looks fine to me. Nice work.
Someone who has worked a bit more with migrate (@chx?) should check this too, but RTBC from my side when that TODO is fixed.
Comment #17
benjy commentedThanks for the reviews, i've added the fields implementation and updated the incorrect ids.
Comment #18
chx commentedLooks great.
Comment #20
benjy commentedWe need to skip the row when the setting doesn't exist.
Comment #22
benjy commentedSkip row if empty wasn't good enough because it's quite possible the setting could be "falsey" and therefore skipped. I've added a new process plugin, "skip_row_if_not_set" and fixed an error in the destination to return the three ids from import().
Comment #23
penyaskitoBack to RTBC per #18. The last interdiffs look OK.
Comment #25
webchickCommitted and pushed to 8.x. Thanks!
Comment #26
benjy commentedWho's benny? ;)
Comment #27
webchickWtf? I totally don't remember manually editing that commit message. I'll fix it in a bit.
Comment #28
webchickOh shoot. You know what it probably is is Safari trying to be "helpful" and auto-correcting Dreditor's stuff. :( :(
Comment #29
benjy commentedNo problem, i'm not sure how easy it would be to change so don't worry about that if it's a hassle.