Réponses:
Bien que cette approche utilise des modules, j'ajoute des nœuds après que les utilisateurs ont confirmé leurs e-mails à l'aide de Logintoboggan et de Rules . L'intégration des règles Logintoboggan ajoute un nouvel événement, When the user account is validated
qui vous permettra d'effectuer des actions lors de la confirmation par e-mail.
Cela fait le travail pour moi:
/**
* Implements @see hook_user_presave
*/
function hook_user_presave(&$edit, $account, $category) {
if ($account->uid // user is not new
&& $account->status === "0" && $edit['status']==1) { // user is being activated
}
}
if($account->uid && $account->original->status == 0 && $account->status == 1)
Si vous utilisez le module LoginToboggan pour la validation des e-mails et que vous ne souhaitez pas utiliser le module de règles, vous pouvez simplement imiter la réponse de validation du module (en exploitant une logintoboggan_email_validated = TRUE
propriété de compte temporaire qui est poussée vers hook_user_update) vous-même dans le code:
/**
* Implement hook_user_update()
*
*/
function yourcustommodule_user_update(&$edit, $account) {
if (!empty($account->logintoboggan_email_validated) && !isset($account->your_custom_action)) {
$account->your_custom_action = TRUE;
// Do what you want here
}
}
Étant donné que le noyau et d'autres modules invoqueront également hook_user_update, vous voudriez implémenter quelque chose pour éviter des actions répétées. Dans cet exemple, j'ai défini une autre propriété sur le compte $ une fois l'action lancée, mais vous pouvez imposer un contrôle plus fin si nécessaire.
Notez que si vous utilisez LoginToboggan pour la validation automatique des e-mails, la méthode d'IOco ne fonctionnera pas (parmi les nombreuses raisons - pendant un hook_user_presave, le $ account-> status == 1 (c'est juste le rôle est dans votre "pré-autorisé" élu) Etat).