registration data is saved in user object
| Project: | Content Profile |
| Version: | 6.x-1.x-dev |
| Component: | User registration module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | content_profile |
There is a case where the value of $user->data is populated with values from the content_profile module which are stored as arrays rather than strings.
To reproduce this:
* enable realname and content_profile modules
* configure content_profile to include at least one node type containing the "real" username value(s)
* create a new user and make sure you populate his content_profile name values.
* edit your admin user profile and provide name value(s)
easiest way to see this is to use devel module and turn on php code block.
run the following for the admin user:
<?php
$uid = 1;
$data = db_result(db_query("select data from users where uid = $uid"));
$data2 = unserialize($data);
dpm($data2);
?>You should see minimal values here. And you should not see any content_profile fields even if you've populated them in the admin profile (not at all sure why this is the case).
Now run the same code with the UID of the new user you created.
You should see a value for your name fields, but it's stored in an array element that will look something like: $account->field_profile_first_name[0][value]
Apparently if this value exists, realname attempts to use the value of $account->field_profile_first_name (thinking it's going to be a string). Of course it's not a string and realname reverts to the actual $user->name field.
In the case of the admin user, $account->field_profile_first_name is not populated at all initially, so realname runs the _load_profile hook in content_profile, which then creates a string value and assignes it to $account->field_profile_first_name. And in this case, the realname_username() function works as expected.
It looks like the extra junk in $user->data is only created if a user creates an account in the standard fashion by signing up then confirming via email.
If you create a new user as admin, this junk doesn't appear to be generated.
#1
#2
a temporary workaround for this problem is to create a a hook_user() that looks something like this:
<?php
function realname_fixer_user($op, &$edit, &$account, $category = NULL) {
if ($op == 'load') {
if (is_array($account->field_first_name)) {
unset($account->field_first_name);
}
if (is_array($account->field_last_name)) {
unset($account->field_last_name);
}
}
return;
}
?>
#3
I assume you're talking about "realname_make_name".
I'm not sure I understand this because the module should not allow you to select a field for use if it has multiple values.
#4
I've seen these same symptoms, but I think the 'extra junk' is coming from content_profile_registration, not realname...
Similarly, I fixed this with a hook_user implementation, but I did it directly in content_profile_registration.
#5
On second though, I think my patch here will blow away the values before they're saved to the database, and thus won't work how I had hoped.
#6
ouch, that's quite a critical issue - it shouldn't save there anything.
#7
I had a short look at it and committed a fix. Please test the next snapshot.
#8
sweet, i will report results
#9
Automatically closed -- issue fixed for 2 weeks with no activity.