web-dev-qa-db-fra.com

Admin user edit - Récupère la méta de l'utilisateur nouvellement soumis immédiatement après la mise à jour/l'envoi

J'essaie de pousser les champs de mise à jour d'utilisateur vers une API par l'intermédiaire du profil utilisateur ou du compte utilisateur admin.

J'ai permis à un utilisateur de mettre à jour son propre profil et de le mettre à jour également avec les mêmes (nouvelles) données de mise à jour de l'API distante.

J'ai eu moins de succès à faire fonctionner l'administrateur correctement.

if  ( is_admin () ) {
    add_action ( 'profile_update', 'myplugin_admin_update', 10, 2 );

    //add_action ( 'edit_user_profile_update', 'myplugin_admin_update', 10, 2 );
    // ^ Fires before form submit. Don't think I can use it.
...
}

 function myplugin_admin_update ($user_id, $old_user_data) {
 $user_meta                 = array_map( function( $a ){ return $a[0]; }, get_user_meta( $user_id ) );
...
}

J'ai ensuite envoyé cette méta à une autre routine pour qu'elle soit traitée et envoyée. Cette partie fonctionne bien.

Le problème est que les données sont "anciennes". Bizarrement, les données je tire de la base de données à l'aide de hook profile_update ne sont pas les données soumises/nouvelles, mais les anciennes données - contrairement à la description dans api codex. Je comprends que le hook livre $ old_data mais cela ne m'intéresse pas - juste au moment où il se déclenche. J'ai seulement besoin d'un crochet qui se déclenche immédiatement après que l'administrateur a mis à jour un utilisateur. Pas avant. J'ai besoin des données nouvellement soumises.

profile_update Ce hook vous permet d'accéder aux données d'un utilisateur immédiatement après la mise à jour de ses informations de base de données.

Qu'est-ce que je fais mal? J'obtiens 'anciennes données' quand j'interroge DB sur ce crochet.

MODIFIER:

Je testais seulement certains méta-champs. J'ai mis à jour 'Prénom' et c'était la nouvelle valeur publiée dans l'API. D'autres champs affichent les anciennes données envoyées à api, comme mentionné ci-dessus.

Je n'ai pas mentionné dans l'article original que ces méta-champs se lisant comme des anciennes données sont les champs du plugin 'Membre WP'} _ (ajoutés via le plugin). Ils sont toujours stockés dans usermeta dans DB, cependant.

Si je clique deux fois sur "Mettre à jour" sur l'utilisateur, je suis en mesure de mettre à jour l'API avec de nouvelles valeurs, mais cela semble être une solution faible.

Donc, maintenant la question est: pourquoi seules certaines méta-valeurs sont lues comme de nouvelles valeurs?

user-meta
4
bshea

Je soupçonne que le problème réside dans la priorité de l'action profile_update.

Vous utilisez la priorité 10, qui est également la priorité par défaut. Le plug-in WP-Members met à jour les méta-champs utilisateur personnalisés à l'aide de ce même crochet, également avec la priorité par défaut. Donc, la mise à jour du plugin est susceptible de se produire après votre processus. (C’est probablement pour cette raison que vous voyez de "nouvelles" données lorsque vous appuyez deux fois sur la mise à jour. Les "nouvelles" données ne sont plus nouvelles à ce stade. C’est maintenant les données qui sont enregistrées pour ces champs.)

Si vous modifiez la priorité pour que votre action intervienne plus tard, vous devriez la voir se mettre à jour (à condition que le reste de votre fonction ne pose pas de problème). Fixez-le à 11 ou plus pour qu'il vienne après la mise à jour des données par WP-Members:

add_action ( 'profile_update', 'myplugin_admin_update', 11, 2 );

3
butlerblog