Respostas:
Embora essa abordagem use módulos, adiciono nós depois que os usuários confirmam seus e-mails usando o Logintoboggan e o Rules . A integração de regras do Logintoboggan adiciona um novo evento, When the user account is validated
que permitirá executar ações após a confirmação por email.
Isso faz o trabalho para mim:
/**
* 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)
Se você estiver usando o módulo LoginToboggan para validação de email e não desejar usar o módulo de regras, poderá imitar a resposta de validação do módulo (explorando uma logintoboggan_email_validated = TRUE
propriedade temporária da conta que é enviada para hook_user_update) no código:
/**
* 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
}
}
Como o núcleo e outros módulos também invocam hook_user_update, você deseja implementar algo para evitar ações repetidas. Neste exemplo, defino outra propriedade na conta $ depois que a ação é iniciada, mas você pode impor um controle mais preciso, se necessário.
Observe que, se o LoginToboggan for usado para validação automática de e-mail, o método da IOco não funcionará (entre os muitos motivos - durante um hook_user_presave, o $ account-> status == 1 (é apenas a função que ele seleciona "pré-autorizado") Estado).