Profile tokens

I'm concerned that the method used here would be very expensive -- it might be useful to put them in an explicit 'profile' token domain rather than the general 'user' domain. Ideally, I'm trying to move away from sticking piles of .inc files into the token project itself, as modules can support tokens directly, but since profile.module is in core that's not going to happen. I'll ponder it and see if there's a way to keep things speedy. If you have any ideas on that, definitely chime in!

I am, though, committing the patch for the recursive array merging. It's a must-have. Thanks!

Hmmmm. That's an interesting idea. I'd feel more comfortable using keyed arrays rather than 'matching' arrays... something like:

token_replace('[token] string [another-token]', array('node' => $node, 'user' => $user);

This wouldn't be as cleanly forward-compatible, unfortunately. Perhaps providing a wrapper function -- token_replace_multiple() or something like that -- would be the best approach? Behind the scenes, it would be almost exactly the same, but the compatibility would be cleaner...

Thoughts?

+1 for this feature since there are already related issues that would benefit from it, f.e. personalizing Simplenews newsletters.

I think it should be in the 'user' token domain, because if you load a user object using user_load() it will have the profile properties as well. So profile_token_values() would be something like:

/**
 * Implementation of hook_token_values()
 */
function profile_token_values($type, $object = NULL) {
  $values = array();
  if ($type == 'user') {
    static $fields = array();

    if (empty($fields)) {
      $result = db_query('SELECT name, type FROM {profile_fields}');
      while ($field = db_fetch_object($result)) {
        $fields[$field->name] = $field;
      }
    }

    if (isset($object)) {
      $account = $object;
    }
    else {
      global $user;
      $account = $user;
    }

    foreach ($fields as $name => $field)
      $field->value = $account->$name;

      if (_profile_field_serialize($field->type)) {
        $field->value = unserialize($field->value);
      }

      $values[$field->name] = _profile_token_format_field($field);
    }
  }

  return $values;
}

I'm going to work on a patch.

Comments?

As promised, here is the patch.

Ops, I mean HERE is the patch :).

Changed profile_token_list() function so it makes use of _profile_token_profile_fields() too.

Sorry, needs review.

The problem with "where they actually belong" is performance...

Has anyone done benchmarks on this?

would this work for 6x? if not, any plans for token to support profile fields in 6x?

Can someone point me in the right direction for how to properly benchmark this? I'd be glad to help with testing / coding, as this is a feature I really need so Signup can use real names instead of usernames in salutations.

This patch still applies cleanly and does work from a functional level.

Thanks,
--Andrew

From the handbook: http://drupal.org/node/79237

"How to benchmark Drupal Code"

Thanks for offering to benchmark this, it would be great to include this functionality.

Ok, I finally managed to get some benchmarks done. It looks like there is no noticeable difference in performance. The steps I followed:

1. First, I used devel to generate users and nodes as suggested in the handbook.
2. Then, I used the UI to create 5 profile text fields. I can do more testing to test the date / list formatters, but I don't see of any ways to make them quicker, and what's there is pretty essential to the feature.
3. I used the following PHP snippet to fill in the profile fields for each user, since devel won't do it.
   

   $q = "SELECT uid FROM {users} WHERE uid > 1";
   $r = db_query($q);
   
   $q = "INSERT INTO {profile_values} VALUES('%d', '%d', '%s')";
   $i = 0;
   while ($uid = db_result($r, $i++)) {
     for ($fid = 1; $fid <= 5; $fid++) {
       $v = time();
       db_query($q, $fid, $uid, $v);
     }
   }

4. I created the attached module to provide a simple way to run token_replace with a random user on every page load. I then called /test-profile-token with ab.

I've attached the results, which are virtually identical. If we want more stress testing with *lots* of profile fields, I can do it, but I doubt there will be any issues given the attached results.

--Andrew

@deviantintegral - thank you very much for this detailed work. I'll try to test this and confirm the benchmark in the next few days at which point I would have to agree - let's add it.

Hi,

Could someone tell me what should be the exact syntax to point to a specific profile field value ? To make things clear :

- I used the "profile" module to create a "real name" field that users fill in when they register.
- I changed the username to display this field value.
- I've installed nodeprofile to create "public profiles" for other users. As you may know this module creates specific nodes used as user profiles.
- I'm using auto_nodetitle to automatically replace this node's title with the value of the "real name" field I created in first step (name is profile_pseudo).
- I replaced the standard token_user.inc file with that included in the Personalized mail module, as it is supposed to let me point to the profile & nodeprofile field values.

Unfortunately, when I type "[profile_pseudo]" in the automatic title generation field, it does not work.... Help please !

I succeeded... If anyone's interested, I just inserted the following code :

"

global $user;
if ($user->uid) {
  $user = user_load(array('uid'=>$user->uid));  // make sure to assign the returned value.
  print($user->profile_pseudo);
}

"

in the PHP argument textbox.

very intresting

Updated patch.

Patch for version 6. Untested.

What's the status of this issue and the actual possibility of this getting into token's module? I had a stalled project related to this and now I am bringing it up to life again. My main objective is to have a working module for that would let me personalize newsletters (there's been a reference to that issue as well in this thread) and I built a token_profile module that does something very similar to what recidive's patch does. Actually I haven't got that far as to properly support all the profile fields format as he did.

I was thinking if uploading both modules (token_profile and simplenews_token) one I have them completed but was wondering if I should do that if there's plan to follow this issue into token's core.

There's also something else in my mind and that's a default replacement text for empty profile fields, as you can imagine, this is very useful but very specific to newsletters, but, by working this into a module, I can have a bit of a freedom and I was thinking in providing a helper module which would let you configure a default replacement for your profile fields. In that case, I'll need to do the profile replacement in a specific module.

What do you think of uploading it anyway?

@hanoii - I'd say that the status is we need a review of the latest 5.x and 6.x versions uploaded by recidive.

@recidive - I assume this is a re-roll of your patch in #12. Thanks for your help with this!

@hanoii - Also, your use of profile tokens seems very specific and therefore it might not be useful for general use.

@greggles, yes, this is a re-roll.

It certainly pretty specific what I wanted to do, actually I changed my mind and I am thinking in creating a custom token modules that would let user add custom tokens with PHP support for any complex replacement.

I have applied #24 and tested it a little bit and so far it's working great.

I've applied the patch in #25 to 6.x-1.11, and it works as described. I haven't encountered any problems yet. I think this is a very useful addition. Thanks.

Is this patch likely to make it in to the module? If not, shouldn't it be prepared as a separate module? I like the functionality, but don't like applying patches that are not going to be adopted by the maintainers of the module, because it makes updating a pain. =(

@greg.harvey - what we need is someone to really review the code. A review is not just "works for me" but is a review.

I'm inclined to apply this to the dev branches to let it get more tests/reviews there.

@greggles - Fair enough. I won't be able to look at this as yet, but I've put a task of reviewing this patch in to our "Maintenance" backlog of work to do here. We could definitely do with this feature (specifically to use in conjunction with Pathauto for automated user profile aliases), but it's company policy not to apply patches that aren't going to be a part of a point release, so happy to help with the process if someone doesn't beat us to it. =)

Btw, it's not clear - should this be for D6? Version is set to D5, but latest patch seems to be for D6. I won't change it, as I could confuse things!

@greg.harvey: patch in comment #24 is for version 5 and the one in #25 is for version 6.

Could this work to give me profile fields as tokens in auto nodetitle module? It's weird, I applied the patch but no new tokens in replacement patterns of auto nodetitle. I thought those tokens in there came from token module?

token_profile.inc referenced in this patch doesnt exist in the token 6 module...

After installing the patch: (d5)

any ideas why the $mytext = token_replace($mytext,$type = 'user', $object = NULL, $leading = '[', $trailing = ']'); successfully replaces the [user] token, but returns empty if the token is [profile_name]??

I can see the new tokens from the profile module under the user object.

I found a few problems with the D6 patch in #25 while trying to benchmark it.

First, there was a bug with profile date fields that was caused by unserializing the field after the profile module had already unserialized it. For url fields, the patch in #25 produces a token that has the text of the url, but no link. And for textarea fields, the newlines are stripped by check_plain, resulting in a single line textfield returned by the token.

The attached patch fixes these problems.

I repeated the benchmarking that deviantintegral described in #19 for this new patch using the latest dev code. I modified the process slightly, adding a total of 11 profile fields, 5 textfields and one of each of the other fields (date, url, textarea, checkbox, freeform list, and list selection). I then modified the code in #19 for D6 and extended it to randomly populate all of these profile fields for each of the 2000 users in the database. I used a similar testpage for the benchmark that does a token_replace on the 11 profile fields.

The benchmark results before and after the updated token_profile patch are attached. There is a slight increase in the request time (323 +/- 7.8 ms with the patch, compared to 307 +/- 9.3 ms without) that is just at the edge of being significant. Note that like deviantintegral, I could not see a difference in performance with token replace on 5 text profile fields. It took the more stressful test (probably the date field) to see a difference.

I still think this would be a very useful addition. It would be great if we could get this into the dev version. I am willing to do additional testing as needed.

This patch worked flawlessly for me. I was able to get the core profile fields to show up in the replacement patterns for user path settings in pathauto which is a great help. Is there any chance this will be committed soon?

The patch works like a charm, however, the profile fields are not available upon user registration, only on updating user profiel. I wanted to send out email with user details upon registration, but that does not work with this. Any ideas how to fix it?

Tested the patch at #39 (D6) and found an issue, possibly the same issue as #41.

In my case, integration with Token and Mentions, the User Object didn't have the profile fields.
To fix the issue, you simply need to add the following line after line #30 of token_profile.inc:

    profile_load_profile($account);

Other than that, patch looks good and would be a great addition to Token.

Cheers,
Deciphered.

+1 for this feature.

I would be happy to re-roll another patch, but would like to know if the maintainers would be interested in committing this or not (once its marked RTBC, of course). If the maintainers don't intend to commit the code, there is no point in updating it.

I ask because the patch in #39 involves a small addition to token.module - though it completely parallels support for other core modules (like node, user, taxonomy and comment).

Some guidance would be appreciated.

Now that token is in core for 7.x (and includes this feature) I don't think we should include this in 6.x.

If anything we should just backport the token code from 7.x to 6.x and provide this feature that way.

6.x patch in #39 worked, but I needed the tokens to be available to Pathauto node titles. I created a custom module as so to solve the problem:

/**
 * Implementation of hook_token_values().
 */
function mymodule_token_values($type, $object = NULL) {
  $values = array();

  if ($type == 'node') {
    if (isset($object)) {
      $account = $object;
    }
    else {
      global $user;
      $account = $user;
    }
    profile_load_profile($account);
    $fields = _profile_token_profile_fields();

    foreach ($fields as $name => $field) {
      $field->value = $account->$name;
      $values[$field->name] = _profile_token_format_field($field);
    }
  }

  return $values;
}

/**
 * Implementation of hook_token_list().
 */
function mymodule_token_list($type = 'all') {
  if ($type == 'node') {
    $fields = _profile_token_profile_fields();

    foreach ($fields as $name => $field) {
      $tokens['node'][$field->name] = $field->title;
    }

    return $tokens;
  }
}

I am quite certain just adding "node" to the original patch would work as well, haven't tested this much yet but it appears to work great.

Thanks.

Thanks everybody for sharing your features.

I took the patch from MGN in #39 and added the suggestion from Deciphered in #42 and included the node token support as suggested by JStarcher in #46.

I just edited the patch from #39, and didn't actually create a new one (because I don't know how to make the patch make a new file). I tested the patch and it works for me.

Changing the issue to version 6.x and to 'needs review'. I would also appreciate this functionality in the module, whether that be by commiting this patch or by backporting. What's the status on this?

Marcus

Hi there,

I'm using drupal 6. After applying the patch mentioned above i got an "Array" when using the profile token with the invite module.

Can anyone help me to fix this problem?

Thanks in advance!

add suport checkboxes filed

@orb your patch file above can't be downloaded -- maybe its the strange filename -- please simplify the name and re-upload

-- glen

Just confirmed a problem with this .inc for token: the cache has to be cleared whenever a node containing profile tokens is updated. I am using this patch with Mention, and the replacement [@username] to [profile_fname] results in the token appearing in the clear as text ([fieldname] instead of the profile data) in the node until the Drupal cache is cleared on admin/settings/performance

EDIT: Note that changes to the page in general seem to "clear" the cache of profile fields but Drupal is not re-acquiring them when the page is rendered the first time after it's saved.

Thoughts?
--glen

Subscribing

I created this cross-post http://drupal.org/node/531648#comment-2392346 in Mentions, in case it's a problem with the mentions module. Note the strange behavior I found was related to the input filter cache not being cleared. I handled it in mentions.module with a FIX.

-- glen

What's going on with this patch? Could not the profile data be provided via hook_token_values in a submodule?

Anyone interested in adding this support through a module (because they don't want to edit contrib modules) can use this:

/**
 * Implements hook_token_list().
 */
function example_token_list($type = 'site') {
  if ($type === 'profile') {

    // Load the profile tokens
    $result = db_query('SELECT * FROM {profile_fields} ORDER BY category, weight');
    $fields = array();
    while ($field = db_fetch_object($result)) {
      $tokens['profile'][$field->name] = $field->title;
    }
    
    return $tokens;
  }
}


/**
 * Implements hook_token_values().
 */
function example_token_values($type, $object = NULL, $options = array()) {
  $tokens = array();
  
  if ($type == 'profile') {    
    // Load the profile tokens
    $account =& $object;
    profile_load_profile($account);
    $result =  db_query('SELECT * FROM {profile_fields} ORDER BY category, weight');
    while ($field = db_fetch_object($result)) {
      $tokens['profile'][$field->name] = profile_view_field($account, $field);
    }
  }
  
  return $tokens;
}

subscribing

subscribing

+1 subscribing

I don't mean to be impertinent, but after fooling with this fix and others for a while, I concluded that it's much easier and more effective to simply use the Content Profile module instead of Profile. With Content Profile, you can create all the custom CCK fields you wish, and they will be instantly available as tokens in myriad variations. Content profile integrates nicely with the user account, with creation of user accounts, and with the Rules module. Sweet.

@gjmokcb

While that's fantastic for you, it has absolutely nothing to do with the topic at hand. If you where to mention that there was Token support in Content profile maybe it would have been of some benefit to the users patiently awaiting this capability, but you did not mention anything of the like.

I use Content Profile but I also use Profile and have been following the updates to this issue queue.
Content Profile is great and all but I agree with Deciphered on how this issue is about the importance of token support for Profile.

Profile is still in core for D7, so we should start supporting it there, and backport if necessary. And feature requests are never critical. :)

Profile tokens would be very useful, for example on community sites that hold several content profiles its great to be able to use one single profile field for example name and for me, to be able to use that as a token would be great.

I've attached a new module that exposes uprofile tokens from the advanced profile kit.

Example usage:

echo theme('token_help', 'uprofile');

global $user;
token_replace($original, 'uprofile', $user, '[', ']');

The code looks like this:

/**
* Implements hook_token_list().
*/
function token_profile2_token_list($type = 'unspecified') {
  if ($type === 'uprofile') {

    // Load the profile tokens
    $fields = content_fields(NULL, 'uprofile');
    foreach($fields as $field) {
      if($field['type_name'] !== 'uprofile')
          continue;
      $tokens['uprofile'][$field['field_name']] = $field['widget']['label'];
    }
   
    return $tokens;
  }
  else if ($type === 'profile') {

    // Load the profile tokens
    $result = db_query('SELECT * FROM {profile_fields} ORDER BY category, weight');
    $fields = array();
    while ($field = db_fetch_object($result)) {
      $tokens['profile'][$field->name] = $field->title;
    }
   
    return $tokens;
  }
}

function token_profile2_uprofile_values($account)
{
    global $user;
    $nid = db_result(db_query("SELECT nid FROM {node} WHERE type = 'uprofile' AND uid = %d", $account->uid));
    $profile_node = node_load($nid);

    // Load the profile tokens
    $fields = content_fields(NULL, 'uprofile');

    // Extract values
    $results = array();
    foreach($fields as $field) {
        if($field['type_name'] !== 'uprofile')
            continue;
        $field_name = $profile_node->$field['field_name'];
        $results[$field['field_name']] = $field_name[0]['value'];
    }

    return $results;
}

/**
* Implements hook_token_values().
*/
function token_profile2_token_values($type, $object = NULL, $options = array()) {
  $tokens = array();
 
  if ($type === 'uprofile') {
    $tokens = token_profile2_uprofile_values($object);
  }
  else if ($type === 'profile') {   
    // Load the profile tokens
    $account =& $object;
    profile_load_profile($account);
    $result =  db_query('SELECT * FROM {profile_fields} ORDER BY category, weight');
    while ($field = db_fetch_object($result)) {
      $tokens[$field->name] = profile_view_field($account, $field);
    }
  }
 
  return $tokens;
}

The only thing I'm not happy with is content_fields(NULL, 'uprofile'); doesn't limit to 'uprofile' content type like it should.

I added an extra check to make sure the field is of type 'uprofile'.

@Deciphered

Golly, thanks for your helpful response. You are so generous! It's people like you that make this a true community!

Subscribing

Subscribe.

Here is the Profile Tokens 6 module with the sole purpose of enabling Profile Tokens in Drupal 6 as Drupal 7 already has it as far as I understood.

It's based heavily on code presented here, mainly by marcushenningsen at #125640-47: Profile tokens.

I hope it solves a few immediate problems to others as it's solving for me.

rsevero, I could create a Drupal project page for #70 if you're interested.

I'd be more than happy to help get this into token.module for D6 and D7, considering profile is a core module. But a few things:
1. This needs to be a proper patch so it can be run against our test bot
2. This needs SimpleTests for *any* new tokens, which would be all the profile tokens (see #1)

:)

First of all I would like to thank both fizk and Dave Reid for their prompt answers.

I believe fizk idea is much more doable as:

1. The code is ready for it;
2. I am not sure how I would create SimpleTests for all profile tokens as the tokens themselves are installation dependent. I could try to create tests for each possible type of profile token but even this would be kind of hard as I couldn't find many tests in the Token module itself to serve as example (and incentive).

Does anybody has ideas on how to deal with point 2 above?

I've added your code to the token_profile module: http://drupal.org/node/783272, http://drupal.org/project/token_profile

:(

Sorry Dave, I should've added, when the patch is committed to token.module, I'll deprecate the token_profile version.

Here's the initial patch for Drupal 7. Let it be known I really hate profile module. I will be super glad when it's been completely deprecated with fields in D8.

Still needs work on some token formats and tests.

@ fizk

I think your idea of including the code I provided in the already existent Token Profile module is great but unfortunately the http://drupal.org/project/token_profile page doesn't show the 6.x version. Is there an expected delay?

The first link you provided (http://drupal.org/node/783272) returns an "Access denied" message to me so I don't know what it's about.

@Dave Reid

Do you think tests on profile field types are an appropriate solution?

About the lack of SimpleTests on the Token module: I was looking on the last released version. Now that I looked on the last dev version I can see there are many tests to learn from.

@Dave

Sorry for messing the the Status and Assigned fields. I believe my browser used a cached version of them.

I managed to fix the Status field but can't change the Assigned.

rsevero, the dev snapshot is only created twice a day, so it should be available sometime tomorrow.

For the record, Dave rocks.

Just FYI, #70 is working perfectly for me on Drupal 6.16/latest Token. Thanks for this (hopefully temporary) solution!

#39: 125640_token_profile_D6_v2.patch queued for re-testing.

+1

subscribing.

Tried out both. Looks good. #74 also has a patch for node author.

+1 for this feature add intp D7 and D6
Regards

subscribing

Any news for this as it does not seem to be in the nightly builds?

It's not yet included, but I've been working on it today. However, I've discovered a blocker that we need to fix in core: #967330: The [current-user:?] token should provide the actual loaded user

Finally got a good chance to polish this up for D7.

And we got the green light from the testbot!
Committed #91 to Token 7.x-1.x!
http://drupal.org/cvs?commit=450438

@Dave Reid: Nice work. Quick question: To get profile tokens to work, does it still require manually applying the http://drupal.org/node/967330 D7 core patch?

Thanks,
Ben

@BenK: No I committed a fix to work around it in the meantime.

Subscribing - coming from #345253: Drupal 6 stable release

any plan for the backport? tokens will get updated to the D7 format (meaning [current:~])? or will be using current D6 format (meaning [user-~]?

Adding new release blocker tag.

Subscribe
(Sorry)

nothing new yet?

I just copy a paste the token_profile module into token for D6 branch. Yup I didn't know how to create the simpletest "test"

killua99, if you scroll up to #74 you'll see that the Token Profile D6 module was created using code from this issue:

http://drupal.org/node/125640#comment-2897586

A second try with SimpleTest. If this not pass I'll try one last chance ... if not pass w/e ... the initial code works ...

See my previous comment.

@fizk: and you put "The Drupal 6 version will be removed once the issue in http://drupal.org/node/125640#comment-2897612 has been resolved." ... Well I don't want to add another module for this feature. Just sorry if I understand in another way. That was my last submit patch.

killua99, That's right, but the code that you copy/pasted into this issue is already in this issue. Why do we need the same code to be here twice?

@fizk: because is not a patch for token. Is another module. I know is idiot duplicated twice the code. I read the comment #70, #71, #72, #73, #74, #75, ... that code was supposed to be in token.module and not in token_profile.module.

Well I guess I'm late to patch that code into token.module... I'll use that code into token.module and not in token_profile.module.

and sorry for duplicated twice the code.

PS: that code was previously duplicated twice, in this thread and in another module (token_profile).