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]

Comments

cgmonroe’s picture

I'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 user makes a change to the info in a content_profile node which is tied to realname (e.g. name field in profile node).
  • Change doesn't take effect until system user info has been saved. (e.g. password/e-mail/theme form).
  • Before the form is submitted, the $account object is loaded.. and the current (pre change) values of the field get loaded from the Realname data. E.g. $account->field_first_name = [realname table value]
  • When the user is saved, the realname_user update code gets called, using the loaded $account object.
  • This ends up calling _realname_make_name to make changes/set new info.
  • _realname_make_name calls the content_profile_load_profile($account, $type) function... with the loaded $account object.
  • This calls content_profile_load and gets back the new values.
  • The values are processed and the $account object is supposed to be set to the new information

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:

//      if (empty($account->{$field_name})) {
      switch (count($values)) {
        case 0:
          $account->{$field_name} = NULL;
          break;
        case 1:
          $account->{$field_name} = $values[0];
          break;
        default:
          $account->{$field_name} = $values;
      }
//      }

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.

cgmonroe’s picture

StatusFileSize
new1.95 KB

Here's a patch with this two changes based on the CVS 6.1 Head.

cgmonroe’s picture

Status: Active » Needs review
YK85’s picture

subscribing - i use both Content Profile and Realname modules and would like to follow to learn more about this potential problem

Status: Needs review » Needs work

The last submitted patch, realname-875972-2.patch, failed testing.

ChrisLaFrancis’s picture

Subscribing.

derhasi’s picture

Status: Needs review » Needs work
StatusFileSize
new710 bytes

Similiar 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.

derhasi’s picture

Status: Needs work » Needs review
davidneedham’s picture

Status: Needs work » Needs review

The 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.

hass’s picture

Status: Needs review » Closed (outdated)