Profile tokens are not available directly after adding/registering a user

this is more profile2 issue, so moving over. However, I think we cannot change the order of entity-creation so this is how it is. Maybe, just re-saving the user account with Rules after profile creation does the trick for your specific case?

subscribe

subscribe

This is a general problem for all profile2 tokens during user registration so, for instance, you cannot use profile2 tokens in registration emails.

This is a fix to recover the profile2 token values from the form data rather than from the profile2 data in the database (that hasn't been saved yet).

function MYMODULE_tokens_alter(&$replacements, $context){
  // profile2 only attached to 'user' type
  if ($context['type'] == 'user'){
    foreach ($context['tokens'] as $name => $original) {
      // only fix tokens that don't already have a replacement
      if (!isset($replacements[$original])){
        // expand the token chain
        $parts = explode(':', str_replace('-','_',$name), 2);
        // check if value exists in the data for this token
        if (isset($context['data']['user']->{$parts[0]}[$parts[1]])){
          $replacements[$original] = $context['data']['user']->{$parts[0]}[$parts[1]][LANGUAGE_NONE][0]['value'];
        }
      }
    }
  }
}

It doesn't handle languages or multiple entry fields but that would be easy to add.

subscribe

subscribe

Fix in #5 works OK, thx.

I consider this a bug. The solutions from #5 suggests profile2 should add this code.

Attached is a patch following along #5

A discussion with a colleague lead to using the rule 'After saving a new profile' which sounds way more plausible to use.

But the remark of @Dippers in #4 still holds thus making this patch valid too.

This is a general problem for all profile2 tokens during user registration so, for instance, you cannot use profile2 tokens in registration emails.

So please review whether this patch solve the Registration Mail problem

New patch tests for valid values for the $parts array.

When creating rules from this do not follow the hint done on the Action page

The data selector helps you drill down into the data available to Rules. To make entity fields appear in the data selector, you may have to use the condition 'entity has field' (or 'content is of type'). More
useful tips about data selection is available in the online documentation.

as that test will fail. Tokens module however will try to eval the used tokens.

I think my issue fits in here:

Rule:
"After saving a new user account"
"Create node of type ZZZ" -> "Set title of ZZZ to [profile:firstname] + [profile:lastname]"

The results of this is 2 nodes:
- One, with the title set to the actual replacement tokens - in this case the title of the new node would literally come out as: "[profile:firstname] [profile:lastname]"
- A second node, with the correct title built from the values of the profile2 tokens, so "Bob Smith" — as expected.

Seems as though the rule to create the node is being executed before Profile2 has a chance to save the data (creating node #1) — then once saved, the rule is executed again, creating the initially intended effect (creating node #2).

Help?

I took the advice from the first comment and created a Rule that re-saves the user after it is first created. That solved my problem.

Success with patch from #12

Confirmed — Success with patch from #12

I have a question to the patch from #12.
I'm not well familiar with git and versioning. How to apply this patch? Should I download git, and diff or somethink on this file?

When patch is applied, am i setting in rules value as before with: account:profile-name:profile-field?

Thanks for help :)

From #15 and #16 we conclude it works right?

Let's move this forward.

Can also confirm that patch #12 fixes the problem. Now, [user:profile-x:y] tokens can be used in the automatically sent welcome e-mails.

Please commit, thanks!

One more confirmation - #12 makes welcome e-mail work OK. Please, commit.

Patch fixes a similar problem with use of Profile2 tokens in Mailchimp merge fields.

I'm a bit concerned about whether this really is the best way of fixing the problem though.

(Also, patch comments need work for Drupal coding standards.)

Changed to Drupal coding standards.

Patch in #24 works for me too.

The patch in 24 only works if the column name for the field is 'value', and throws an error like "Notice: Undefined index: value in profile2_tokens_alter() ..." if it's not. I'm going to look into a more generalised solution starting now..

Update: it will also only work when the language is LANGUAGE_NONE, but perhaps this is always the case with the registration form? Doesn't seem likely..

Well spotted! I confirm this:

+++ b/profile2.module
@@ -879,3 +879,28 @@ function profile2_user_get_properties($account, array $options, $name) {
+          $replacements[$original] = $context['data']['user']->{$parts[0]}[$parts[1]][LANGUAGE_NONE][0]['value'];

This bit expects a structure like $entity->FIELDNAME[SOMETHING???][und][0][value]

which makes it pretty specific.

We should at the very least use field_get_items(), but that won't solve the 'value' problem IIRC.

So as we're already dependent on Entity API, we should in fact use an entity metadata wrapper.

Though I can't help but wonder if there's an altogether more elegant way to do this :/

@mrded what is the interdiff between #12 and #24? (what comment I did wrong)

I'm sorry for the obscure code as that's what it is. iirc I wrote it for a dutch only website 1 year ago :-/

@clemens.tolboom, difference is just in coding standards. Functionality is still same.

Okay, I've now spent many hours on this, trying many different approaches:

1. Modifying patch in #24 to use field API to render the fields. This doesn't seem to work because the fields API wants entities to work with, which we don't have yet. I tried taking the relevant bits of code extracted from the fields API call tree but it became a long and messy kludge. My feeling is that using hook_tokens_alter approach is a bit of a hack, in any case. :P
2. Modifying profile2 to create profile2 entities in hook_user_insert rather than in a register form submit handler. However this runs into troubles because it seems we need the $form and $form_state variables to do this properly, which we don't have access to in hook_user_insert (all we get is the "edit" array, which contains some of the $form_state['values'] sub-array).
   1. I then tried rebuilding the necessary bits of the form, but this became a bit of a hack which I'm not sure will work for all kinds of fields.
   2. I then tried storing a reference to the $form and $form_state variables in a global static variable via a custom register form submit handler to be called before the core register submit handler (by adding it before the core function in $form[#submit]), but it doesn't get called for some reason (gets called fine if it's appended to $form[#submit]), I then tried storing a reference to $form and $form_state in the validation function, but it looks like the variables must be cloned somewhere between calling the validate hooks and submit hooks because the references are missing (necessary) elements that appear in calls to the user register submit handlers.

I now hate Drupal even more than I was already starting to...

I think that I finaly found a proper solution.

The idea is that we disable e-mail notifications during execution of user_register_submit() callback, but send this notifications right after the saving of a user profile in profile2_form_submit_handler(). So we don't loose any e-mails or smth like that, but now all tokens from profile2 are available.

Patch that solves this issue attached.

31: profile2-tokens-1097684-31.patch queued for re-testing.

Okey, applied new patch with a small fix.

@Spleshka interesting approach.

I'm not sure whether your approach could have side effects on other modules behavior.

The other approach which still has issues just fixed tokens which is a solution for other modules too.

my 2cents

@clemens.tolboom,

I tried to keep the contrib's behavior here. For example, if some contrib disables the notification - the profile2 also will not send this notification. So this behavior is pretty save.

It's definitely a very clever approach.

Are there other use cases besides emailing new users, which this wouldn't cover?

In theory, we may miss a case when some contrib needs profile2 tokens while user registration process, and its callback executes after user_register_submit() but before profile2_form_submit_handler(). To avoid this case we may ensure that profile2_form_submit_handler() executes right after user_register_submit(), and all other callbacks - later.

Hmm.. the patch doesn't fix the issue in my case. Do I have to clear the cache or something ?

@PascalAnimateur,

No, you don't need to clear a cache. Please tell about your case.

The problem I have is with realname_registration which allows to generate username from profile2 tokens (i.e. first and last names). When sending the notification email, [user:name] doesn't pick up the realname tokens at all.

Okey.. so I see only one solution here: We need to have three form submit callbacks:
* First - right before user_register_submit() - disables e-mail notification.
* Second - right after user_register_submit() - creates user profile.
* Third - the last of all callbacks - sends e-mail notification.

@PascalAnimateur,

I've installed both profile2 and realname_registration modules. Name generation works successfull for me in both cases: with and without patch. The real name generates during hook_user_presave(), which is invoked in user_register_submit(). So your issue is not related with this issue.

The conclution: my patch is still waiting for a maintainers' reviews.

Maintainers often filter on "reviewed and tested by the community".
So to make maintainers see this faster, some of the followers of this issue needs to review and test it.

Agree. So guys, please make a patch review to finally solve this issue ;)

#39 looks good for me
Good to see unit tests here

Any progress here?

#39 Works good for me.

Cool, thanks! Now we need to get this commited ;)

Using Logintoboggan the patch in #39 causes registrations to send 2 emails.

I believe this is due to LT unsetting the core user_register_submit handler and uses its own.

Thanks @Loze! So we need to figure out why it doesn't work with LT.

+1 for LT duplicate email. Any success on this?

Okey, I got this problem. LoginToBoggan replaces default user_register_submit() function with its own one. So we need to catch this case. Also we have to ensure that form alter hook from Profile2 executes the latest to prevent possible issues when Profile2 executes before LT (or other contribs that may do some work aroung user_register_submit() function).

I've made some more coding and tests around this issue with LT and found a proper solution. See patch below.

Spleshka it looks good so far, VERY GOOD JOB!!!

Thank you. Please, test and set proper issue status if it is works for you.

This appears to be working for me as well using LT. Great job!

I spoke too soon. While its working on the registration end. I am getting the following error when I visit the edit profile page.

Notice: Undefined index: #submit in profile2_attach_form() (line 445 of C:\www\sandbox7\sites\all\modules\contrib\profile2\profile2.module).
Warning: array_search() expects parameter 2 to be array, null given in profile2_attach_form() (line 445 of C:\www\sandbox7\sites\all\modules\contrib\profile2\profile2.module).
Warning: array_splice() expects parameter 1 to be array, null given in profile2_attach_form() (line 450 of C:\www\sandbox7\sites\all\modules\contrib\profile2\profile2.module).
Warning: array_splice() expects parameter 1 to be array, null given in profile2_attach_form() (line 454 of C:\www\sandbox7\sites\all\modules\contrib\profile2\profile2.module).
Warning: array_splice() expects parameter 1 to be array, null given in profile2_attach_form() (line 458 of C:\www\sandbox7\sites\all\modules\contrib\profile2\profile2.module).

These errors are gone when I switch back to the unpatched version.

Thank you for tests, @loze! We are so close to the finish :)

I could not reproduce your bug, but I believe that this situation is possible if #submit handler is missing in the form for some reasons. So I've made small fix to ensure that this case never happens.

Thanks Spleshka, I think that's it!

Seems to be working with my initial test. Thanks for the quick response on this!

Welcome, @loze. Please, do not forget to set a proper issue status if you tested the patch :)

Also confirming patch #60 works for me.

Any progress here? Do we need more testers or patch is waiting maintainers to be commited?

@Spleshka The last commit to the projects repository was 11 months ago. So the problem is probably that this module needs new maintainers.

Since I am a new co-maintainer for Profile2, I was able to commit/push this patch to 7.x-1.x.

Thank you all indeed for your manual tests and reasonable advices!

Excellent, Spleshka, thank you! Good to know that this important module got live again after being unmaintained for 14 months.

Just wanted to confirm that this issue has indeed been fixed using the latest dev snapshot - 7.x-1.3+4-dev (2014-Mar-02).

Thank you, @roball, for confirmation!

Unfortunately it's still not working as expected from my end. What I'm basically doing is programatically creating the user:

  // Create new user.
  user_save($user, $edit);

  $profile = profile_create(array('type' => 'user_profile', 'uid' => $user->uid));
  $profile->field_category[LANGUAGE_NONE][]['tid'] = $term->tid;
  profile2_save($profile);

The rules fired as expected with the event "After saving new profile", but isn't able to validate the condition as expected. Here's the report from the Rules log:

" Reacting on event After saving a new profile.
0 ms Reacting on event After saving a new profile.
61.269 ms Evaluating conditions of rule Test rules. [edit]
70.323 ms Unable to get the data value for the variable or parameter list. Error: Unable to get the data property field_category as the parent data structure is not set.
79.401 ms Unable to evaluate condition list_contains. [edit]
79.461 ms AND evaluated to FALSE.
79.52 ms Finished reacting on event After saving a new profile.

Confirming latest dev works great!

Just installed the latest dev version, and it's still not working as many have stated it is. Any tips or magic tricks would be greatly appreciated.

Last version not working here either. And when installed the automatic e-mail with a welcome message is no longer send, when admin creates an account.

Unfortunately, I have to confirm that on my new sites, having the latest Profile 2 7.x-1.x-dev installed, tokens such as [user:profile-profile:field-first-name] will no longer be resolved into the correct field value (instead, they are resulting in an empty string) in welcome e-mails.

I have been trying to resolve this issue on a site for days now as well. Using the latest dev version of Profile2 does not help for me.

Drupal 7.31
Profile 2 version 7.x-1.3+5-dev
Realname 7.x-1.2

Add a new user with generic username - testuser1
Edit Profile
add first name - Test
Add last name - User1

Realname not updated
Resave Profile page and the Realname is updated.

I also still have the issue.
By saving the user's profile twice the Realname is updated. Same as the steps outlined in #77.

Not a solution to the issue, but putting this here in case it helps anybody.

I implemented a rule outlined by Dave Reid here https://www.drupal.org/node/1414140#comment-6133400 which works as a workaround by updating the realname when the user's profile is updated.

{ "rules_rule_update_realname" : {
"LABEL" : "Update Real name",
"PLUGIN" : "reaction rule",
"REQUIRES" : [ "realname", "profile2" ],
"ON" : [ "profile2_update" ],
"DO" : [ { "user_realname_update" : { "account" : [ "profile2:user" ] } } ]
}
}

This is still not working with latest dev version.
Upon initial user creation, realname is not populated. Requires re-saving the profile.

Latest dev version is working for me neither.

Oh, that's bad. It seems that I have to digg into this issue again :)

That would be really appreciated, I temporarily fixed it with a rule like the one mentioned in #79.
I also had a caching problem with entitycache, but fixed it with a custom cache clear action in rules as well.

#5 Works good for me.

#5 worked for me too. :)

Another Workaround :

Create an hidden field in your user account
Populate that field in a custom module

This code is partly working, would need another condition for cases where $account is not new where it uses profile2_by_uid_load or it could be done wit a rule... it is clearly not a clean workaround, but at least headaches are fading away...

  if($account->is_new){
   
    $edit['field_temprealname'][LANGUAGE_NONE][0]['value'] = $account->profile_YOURPROFILETYPE['YOURFIELD'][LANGUAGE_NONE][0]['safe_value'].', '.$account->profile_YOURPROFILETYPE['YOURFIELD'][LANGUAGE_NONE][0]['safe_value'];
  }
  if(!$account->is_new){
    $profile = profile2_load_by_user($account);
    $firstname = ''; //you can find it with dsm($profile)
    $lastname = ''; //you can find it with dsm($profile)
   
    $edit['field_temprealname'][LANGUAGE_NONE][0]['value'] = $lastname.', '.$firstname;

  }

#5 worked for me with token pattern: [user:profile-name:field_name]

Sorry if this sounds like a stupid question but how do you re-save a profile in rules.

Can't get token [user:profile-name:field_name]
to appear in Rules action : Send mail to all users of a role
tried all the patches but nothing works

However tokens of the form [user:profile-name:field_name]
in emails from admin/config/people/accounts work as expected

any directions ? what is missing ?

EDIT
in rules action token has to be of the type
[account:profile-name:field_name]

So everything works

I have the problem of not mails not being sent. I dig a little into my configuration and it seems that profile2_attach_form its called twice don't know why yet. I think this is related to use also Profile2_regpath module.
The problem then is that the handlers are called twice and the $changed_ops static var is populated twice, the first time correctly but the second time is incorrectly populated with the previous unset($conf), so $notify is always false and no _user_mail_notify is called.
Anyway I just added a small check to avoid adding twice the hooks and avoid this silent error, validation is still added twice.
Cheers,
Jacq

Thanks @Dippers #5 works for me :)

Just to let you all know what I did to get this working. If you use Rules and create a reaction rule like this:

Event: After saving a new profile
Elements: Data Comparison (Data to compare, [profile2:type], Data value: (Profile 2 type here)
Elements: Send mail

Then all of the profile2 are available as tokens in the email.

At first I tried to set this up using Event: After saving a new user account, but the fields were showing up blank and unavailable, as described above. Since new users on my site are also entering profile2 information at the same time, this got it working as the way I wanted.

Hi all!
This is a long discussion thread with many contributions. I tried to follow all aspects and also tried some (last) patches, but I couldn't get fix my problem, which is the following:

Diretly after an user has been registered, his/her profile2 field's content is not shown and can't be manipulated(=>no effect) inside a View (nothing to do with Rule or mail sending, though I tried to fix my problem with Rule: after saving a new user account|new profile approaches).

As soon as I save the profile2 by selecting it (/user/userID/edit/profile2name) and press the button "Save" manually: the fields becoming available and view based changeable...
But how can I simulate/automate this saving process??? :(

It leads to despair, so I appreciate your help, seriously!

Edit:
To be precise: This is only the case for profile2 variables not haven been asked for during the registration process.
After registration, those variables should show the default-value (like they do at /user/userID), but in the View they just don't.

#60 did not work for me as it disabled all emails. #12 worked for me.

So... I have another use case that isn't working properly on registration of a new user. I have a site that uses 2 Profile2 types for each user. The first one is an 'Application' that the user fills out when they are registrating for the site. This 'Application' is hidden from the user after they fill out the information and apply to the site. Then I have the 'Member Profile' that contains some of the fields of the 'Application' profile. This can be edited freely by the user to show their information to other users of the site.

I would like to copy some fields from the 'Application' Profile2 to the 'Member Profile' Profile2 on user registration; however, at user creation time the 'Member Profile' doesn't exist at all and I can't figure out how to create it.

Using a rule on Create New Profile (with the type 'Application') works great, allowing me to access the data in the 'Application'; however, I can't figure out how to programmatically (in Rules) create the 'Member Profile' for the user. I can create _a_ 'Member Profile' but I can't use 'Set a data value' to set the User's 'Member Profile' because it says 'The selected property doesn't support writing.' Also, I can't set any of the individual values of the User's 'Member Profile' because it says 'Parent data structure has not been set yet'

In fact, if I add a Rules Trigger to Create New Profile with the type of 'Member Profile' the trigger doesn't get called until I go in and manually create the 'Member Profile' by hand and then save it.

Any ideas?

Thanks,
Raxxraxx

#5 worked for me - thank you to Dippers :)

I don't get any options in Drupal 8 for this. Is there a way to integrate Profile2 for Realname or should I just get rid of Profile2?

The fix in #60 has now been released into 7.x-1.4, as it was already in the dev build 4 years ago. However, it seems it wasn't a complete fix, and has caused a new issue for a user who's gone straight from 1.3 to 1.4. See issue #2954186.

The problem is the profile2_module_implements_alter() hook, for reasons I can't work out but discovered by a bit of guesswork! I've posted a patch in the other issue to remove this hook. If anyone here is using 1.4, could you feed back whether applying the patch in issue #2954186 affects behaviour, either positively or negatively?

Thanks

The changes in 7.x-1.4 seem to have introduced several other issues, with quite a lot of module conflicts going on. AFAICT, much of it results from the use of hook_module_implements_alter(), removing it clears most of these other issues.

I'm therefore attaching a patch against latest dev (7.x.1.4-dev+3), which removes the hook function, but leaves everything else in #60, and also includes the fix in #90 which appears sensible.

Please try this patch with latest dev, and let us know the results.

Related issues: #2449913, #2954186, #2956961

Thanks

I came here from #2954186
So I only tested what is related to there.
Patch dev, works fine.

Fix also confirmed in #2962543. Marking RTBC.

Can confirm patch #99 fixes an issue we had with Profile2 7.x-1.4. Field Group was not able to render fields inside the Profile2 fields on a user registration page. Downgrading the Profile2 module to 1.3 or 7.x-1.4+6-dev (which includes patch #99) fixed the issue.

Hi, Has this been fixed.

I am having the same issue with Profile2 7.x-1.7.

Thanks

Hi noopal

I came into this issue quite late, as I was in the process of tidying up the module. I don't have a configuration that showed up the problem, I followed reports from affected users, and it also interacted with other issues so was a bit mind-bending!

Reading the original report again, it sounds like the core of the problem is that, on registration, the profile entity is created after the user entity. However, I don't see how that can be changed, as the profile needs the user uid - that is generated by the database and doesn't exist until the user has been created. So if the profile were written first it would be incomplete.

Is that a fair description, or is there another problem here?