Get userfields at 'u_register' event not possible with v1.6.3

Question

I am writing a plugin that informs the admin when a new user registers.

Everything works, however, I want to add the userfields specified on the registration page (fields set up in admin/...).

Problem is that with current qa-page-register.php (v.1.6.3), at first the user is created:

   $userid=qa_create_new_user($inemail, $inpassword, $inhandle);

And just afterwards the user profile field are saved.

With qa_create_new_user() the "u_register" event is fired and my event module triggered.

From the logical point of view, it is correct to first create the user and then write the user fields. But how can I get the fields otherwise? They are not transferred with the "u_register" plugin.

Thanks for any valuable tip.
Kai

 

PS: Maybe we can rewrite function qa_create_new_user() and throw in the userfields as well?

Answer 1

Your PS should be the most appropriate thing, in technical terms. However, maybe there was a reason not to update those fields before the event is fired and after the user is added to the ^users table... I don't really know.

Changing that would result in updating the core. Being 1.6.3 the stable version if the core gets updated ASAP with this change the minimally required version for your plugin would be 1.7. If the core does't get updated then soon you'll have to wait even more. So I wouldn't rely on a change in the core.

These are the 2 options I can think of:

1. Listen to the u_login and always check for some field that should always be null before the first login and then never again. There must be at least one in the ^users table that fulfills that requirement, most likely the loggedin field
2. If option #1 doesn't work then create a ^pending_registration_notification(userid) table. Listen to the u_register event and add the userid in there. Listen to the u_login and whenever the user logs in verify there is a record in there. If there is then the user has just registered so perform any needed action and remove the record. Do nothing otherwise

Comments

Thanks for your help.

The two options proposed seem to be complicated workarounds, I really hope we can just change the core line... and done =)