WP_User_Query et données usermeta non uniques


8

Nous avons un problème avec un plugin WP que nous avons écrit et maintenu - Exporter les données utilisateur

Un utilisateur a signalé un problème selon lequel les enregistrements de métadonnées d'utilisateur non unique ne sont pas renvoyés correctement - ici

Dans le plugin, nous exportons les données usermeta sélectionnées par l'utilisateur - en utilisant get_users () qui à son tour utilise WP_User_Query:

Nous passons quelques arguments simples à get_users:

// build argument array ##
$args = array(
      'fields'    => 'all',
      'role'      => sanitize_text_field( $_POST['role'] )
);

Si nous inspectons un objet WP_User retourné, les champs usermeta ne sont pas retournés - par exemple (les données d'objet réduites pour économiser de l'espace):

Array
(
[0] => WP_User Object
    (
        [data] => stdClass Object
            (
                [ID] => 1267
                [user_login] => user@email.com
                ...
            )

        [ID] => 1267
        ...
    )

[1]...

Nous avons essayé de changer l'argument get_users pour le paramètre "fields" de "all" en "all_with_meta", mais cela ne semble pas changer les données retournées à l'origine.

Au moment où nous exportons ces lignes de métadonnées utilisateur, nous effectuons d'abord une boucle sur ce tableau d'objets WP_User, puis faisons écho aux données de champ usermeta individuelles ($ field provient d'un tableau de champs $ qui boucle en dehors de la boucle $ users):

// build row values for each user ##
foreach ( $users as $user ) {

    // grab value from $user object ##
    $value = $user->{$field};

}

Les données de champ sont ajoutées comme par magie à l'objet $ user, même si cela ne figure pas dans les données d'objet renvoyées à l'origine - cependant, nous n'avons aucun contrôle sur le fait qu'il retourne un seul ou un tableau de valeurs pour chaque champ usermeta.

Comme les données sont renvoyées automatiquement, nous ne contrôlons pas la méthode sélectionnée, ce que nous serions en mesure de faire si nous utilisions directement get_user_meta (mais nous aurions toujours le problème de ne pas savoir que les données stockées sont uniques ou non, sans exécuter supplémentaire requêtes - ce qui coûterait cher pour les grandes exportations).

J'écris tout cela pour essayer d'expliquer le problème aux autres, tout en nous aidant à rechercher des réponses et à résoudre ce problème.

Mise à jour

Nous avons poussé un correctif de test vers github en utilisant une méthode pour vérifier les clés usermeta non uniques et renvoyer un tableau dans le cas où il y a plus d'une clé correspondante

Réponses:


3

La solution que nous avons choisie à la fin utilise un seul appel à get_user_meta en ne passant que $ user_id - de cette façon, toutes les données utilisateur sont renvoyées dans une seule requête, réduisant ainsi une lourde charge sur la base de données lors d'exportations de données utilisateur importantes.

Nous effectuons ensuite une série de vérifications par rapport aux données renvoyées, notamment:

  • is_serialized ($ value) - pour vérifier si les données ont été renvoyées sous une forme sérialisée (nous essayons ensuite de les désérialiser - dans certains cas, cela échoue lorsque les données ont été stockées sous une forme incorrecte).
  • is_array ($ value) - pour vérifier si les données retournées sont en fait un tableau

Si nous constatons que les données sont retournées dans un tableau, nous implosons récursivement le tableau jusqu'à ce que nous ayons une chaîne de données à retourner dans le fichier d'exportation.

Je n'ai pas inclus de code spécifique dans cette réponse, mais plutôt lié aux fichiers github hébergés (je sais que ce n'est pas idéal pour l'avenir, mais les parties qui se rapportent à cette réponse sont réparties dans le code).

Les exportations se déroulent correctement et ne s'étouffent pas - nous publierons le plugin mis à jour la semaine prochaine.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.