In getting Profile2 profiles to merge properly I found and fixed a number of bugs. Unfortunately many of these are intertwined, so it would be difficult and tedious to post patches for each one. The issues are in includes/profile2.usermerge.inc.
1) If one of the two profiles does not exist, usermerge gives up and does nothing. This isn't right. The user should be given the option to choose the user-to-be-deleted's data. This must be fixed both for review and then for processing of the usermerge.
2) When a field has more than one value, usermerge gives up and displays "multiple values". This isn't helpful. The individual values should be displayed.
3) The user should be given the option of merging a field when the cardinality (maximum number of values) is not 1 and when the values from two profiles are different.
4) User merge gives up when it can't easily display the value of the field. If needed, the value should be rendered using drupal_render(). This happens when there are compound fields, like an address field.
5) All languages are process twice when a field is merged because of an oversight in finding the array union of the languages in both profiles (need to call array_unique).
6) When merging fields, duplicate values should be removed (e.g. same cell phone number in both profiles).
7) When merging the cardinality must be respected (max number of values).
Patch forthcoming...
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | usermerge-profile2_merge_multiple_issues-2274663-1.patch | 7.13 KB | danchadwick |
Comments
Comment #1
danchadwick commentedComment #2
antiorario commentedSounds reasonable. I've committed it. I'll wait a couple of days before making a new release, just in case.
Comment #3
danchadwick commentedThanks for the nearly-instantaneous commit. :)
One suggestion: If you name your commits using the Drupal convention, it makes it easier for contributors and other maintainers to track the issues.
I will look forward to a new release so I can update my production server. Thanks for your work on this module.
Comment #4
danchadwick commentedOne other bug that I fixed that I wanted to point out: Due to an oddity in PHP precedence, the following doesn't do what you think:
What one usually really wants is:
Alas the PHP manual does not list the precedence of the object operator (->), but the array operator ([]) is very high -- higher than the object operator. This means that the first code evaluates as if it were:
This is looking in the object for a field whose name is given by the array $field, array item 'index' -- which is almost never what you want. I've been bitten by this a few times.
Comment #5
antiorario commentedThanks for the tip about Drupal conventions.
About #4, if it's something you found in the Profile 2 code, I didn't write it (and I'm aware of the oddity). I know, it's no excuse, since I should have kept my eyes open for stuff like that, but I didn't have Profile 2 installed so I wasn't able to test it—I was relying on the community for that. And hey, it worked :-)