I've used realname tokens in pathauto before to replace user ids from user profile urls (e.g. e.g id = email addr but you don't want it to be exposed via the profile url). But that was with the default profile module. Now, I'm trying to do this with the content profile module and there are problems.
With the default profile, this will produce a user URL like users/greg-monroe when a new user is created. Additionally, if the users changes their realname related fields, the URL changes (e.g. someone gets married/ typo on initial entry). VERY NICE... much thanks for this!
However, if you are using profile_content generated fields, the profile url is alway the username. I've traced the problem to the [realname] token being returned as "" and being defaulted to the user id.
After a lot of code splunking, I found that the realname_content_profile.inc plug-in (content_profile_load_profile function) is using the CCK 'value' as a key for the field (e.g. $field[0]['value] ). But in realname.module (_realname_make_name function), it is trying to use the 'view' key. (E.g. $field[0]['view]).
Some issue searches showed that this is related to (but not quite the same as): http://drupal.org/node/544574 So, I changed the way that $stuff['%'. $i] is set in _realname_make_name ~778 from:
$private_field = isset($account->{$private}) ? $account->{$private} : FALSE;
if (isset($account->$name) && !empty($account->$name) && !$private_field) {
if (is_array($account->$name)) {
$stuff['%'. $i] = $account->{$name}[0]['view'];
}
else {
$stuff['%'. $i] = $account->$name;
}
to
$private_field = isset($account->{$private}) ? $account->{$private} : FALSE;
if (isset($account->$name) && !empty($account->$name) && !$private_field) {
if (is_array($account->$name)) {
$stuff['%'. $i] = $stuff['%'. $i] = isset($account->{$name}[0]['view'])?$account->{$name}[0]['view']:$account->{$name}[0]['value'];
}
else {
$stuff['%'. $i] = $account->$name;
}
This sort of fixes the first part of the problem. Now when a user is created/registers, the profile URL is as expected.
The other part of this (modifying URL when name changes) is still broken. I can see why changing a profile node might not trigger this.. but I thought it would change if you saved the base user information after modifying a profile node. (since this should trigger the realname/pathauto refresh). But for some reason this doesn't happen.
Another interesting symptom that happen after changing a name is that the "Profile for " title on the user profile keeps the original name. But all the "themed" output shows the new name.
Anyone have any ideas on how to make name changes work with the profile URL and title?
FYI - My set up is:
Content Profile has a "public" content-type and a "private" content-type associated with it. The user's first/last name are CCK fields in public.
Content Profile User Registration module is set up.
Realname has Content_profile module turned on and is using the info from the CCK fields.
URL Alias for users: users/[realname]
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | viewandvalue-875972-7.patch | 710 bytes | derhasi |
| #2 | realname-875972-2.patch | 1.95 KB | cgmonroe |
Comments
Comment #1
cgmonroe commentedI've found the answer to the other part of this... there is a logic bug in the realname_content_profile code.
Here's a description of the overall flow to help describe the problem and the simple fix:
The logic bug occurs in this last part. The code to update the $account->$fieldname values is wrapped in an empty($account->$field_name) condition. However, because the $account object has been loaded with the old values, the new values never get set in the $account object.
The solution is to drop this check. Once I did that, the names and url's changed as expected. Here's the new code from realname_content_profile.inc, ~ line 30:
I'll try to find the time to create a patch with both these minor fixes relating to this later this week.
FWIW - I think the isempty test is related to the cache system not working in previous versions and the code being called multiple times. With the -dev version, my debugging shows this code only gets called once per page.
Comment #2
cgmonroe commentedHere's a patch with this two changes based on the CVS 6.1 Head.
Comment #3
cgmonroe commentedComment #4
YK85 commentedsubscribing - i use both Content Profile and Realname modules and would like to follow to learn more about this potential problem
Comment #6
ChrisLaFrancis commentedSubscribing.
Comment #7
derhasi commentedSimiliar issues were filed in #544574: content_fields, nodeapi, view vs value and #994782: Why does _realname_make_name() access the 'view' index instead of the 'value' index?.
I reapplied the patch from above to the current dev, that fixes the problems for me.
Comment #8
derhasi commentedComment #9
davidneedhamThe patch in #7 appears to be totally different from #2 (not just a simple re-roll). Regardless, neither of them seem to be working for me against the latest dev.
Comment #10
hass commented