web-dev-qa-db-fra.com

WP_User_Query et données usermeta non uniques

Nous avons un problème avec un plugin WP que nous avons écrit et maintenons - Export User Data

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

Dans le plugin, nous exportons les données usermeta sélectionnées par l'utilisateur - à l'aide de 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 renvoyé, les champs usermeta ne sont pas renvoyés - par exemple (données d'objet réduites pour économiser de l'espace):

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

        [ID] => 1267
        ...
    )

[1]...

Nous avons essayé de modifier l'argument get_users du paramètre "fields" de "all" à "all_with_meta", mais cela ne semble pas modifier les données renvoyées à l'origine.

Au moment où nous exportons ces lignes de métadonnées utilisateur, nous parcourons d’abord le tableau d’objets WP_User, puis nous renvoyons les données du champ usermeta à un autre (le champ $ field provient d’un tableau de champs $ bouclés 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 en cours d'ajout de magiquement à l'objet $ user, même si cela n'apparaît pas dans les données d'objet renvoyées à l'origine. Toutefois, nous n'avons aucun contrôle sur le renvoi d'un seul ou d'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 qui serait possible si nous utilisions get_user_meta directement (mais nous aurions toujours le problème de ne pas savoir que les données stockées sont uniques. ou non, sans lancer de requêtes supplémentaires - ce qui serait coûteux pour les exportations importantes).

J'écris tout cela pour essayer d'expliquer le problème aux autres, tout en nous aidant également à trouver 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 rechercher des clés usermeta non uniques et renvoyer un tableau s'il existe plusieurs clés correspondantes.

8
Q Studio

La solution que nous avons finalement utilisée utilise un seul appel à get_user_meta en transmettant simplement le $ user_id - ainsi, toutes les données utilisateur sont renvoyées dans une seule requête, ce qui réduit considérablement la charge de travail. Base de données pendant les exportations de données utilisateur volumineuses.

Nous effectuons ensuite une série de contrôles sur les 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 la 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 renvoyées sont bien un tableau

Si nous trouvons 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 relatives à cette réponse sont réparties dans le code).

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

3
Q Studio