Pourquoi les données utilisateur dans WordPress peuvent être un cauchemar

Chaque site Web que nous créons a ses propres défis. Mais les outils que nous utilisons peuvent nous aider à les affronter de front.

WordPress et son écosystème de plugins sans fin ont aidé les concepteurs de sites Web à maîtriser même les demandes des clients les plus difficiles. Presque tout ce dont nous avons besoin est simplement de cliquer et de partir. Et s'il n'existe pas, nous pouvons le construire nous-mêmes.

Mais pour chacune de ces solutions que nous mettons en œuvre, il y a une conséquence cachée. Celui qui ne monte que lorsque nous approfondissons un peu les données spécifiques à l'utilisateur. Ce n'est qu'alors que nous réalisons le désordre emmêlé sous cette jolie coque extérieure.

Un début simple

Dans une installation WordPress par défaut, les données utilisateur (au moins le type que vous souhaitez exporter) sont en fait assez propres et soignées. Les données sont stockées dans la table de base de données wp_usermeta. À l'intérieur, vous trouverez les bases comme le nom d'utilisateur, ainsi que leur rôle / capacités et les préférences de compte.

Combinez cela avec ce qui est dans la table wp_users (nom d'utilisateur, adresse e-mail, mot de passe), et vous pouvez obtenir de nombreuses informations utiles pour chaque utilisateur sur votre site Web. En outre, vous pouvez facilement importer une liste CSV de nouveaux utilisateurs si nécessaire.

Bien sûr, la plupart des sites Web ne s'arrêtent pas à un paramètre par défaut. Au lieu de cela, nous ajoutons souvent un nombre illimité de plugins afin que les utilisateurs puissent en faire plus avec notre site.

Nous voulons qu'ils fassent des choses comme avoir des informations de profil personnalisées, suivre les commandes et appartenir à des groupes spécifiques. De plus, des fonctionnalités telles que les forums, les portails de support et les systèmes de gestion de l'apprentissage sont également largement utilisées de nos jours.

Et cela ne fait qu'effleurer la surface. Il y a beaucoup plus à ajouter à un site WordPress typique. C'est bien, jusqu'à ce que vous deviez essayer de discuter des données.

Des données, des données, partout

Le problème en question n'est pas tant la faute de WordPress lui-même. C'est là que, dans de nombreux cas, un certain morceau de données est stocké est laissé aux développeurs de plug-ins. Cela peut entraîner le stockage des données utilisateur que vous souhaitez collecter. C'est la nature de la bête.

Prenons un site Web récent sur lequel j'ai travaillé comme exemple. Il utilise un plugin d'adhésion, qui permet aux gens de rejoindre l'organisation du client.

Informations collectées

Lorsqu'ils s'inscrivent, nous leur demandons plus que des métadonnées utilisateur WordPress standard. Les nouveaux membres sont invités à fournir des informations telles que:

• Adresse de livraison;
• Numéro de téléphone;
• Votre préférence pour la façon dont ils reçoivent les newsletters (e-mail ou courrier postal);

Données générées

Au-delà des informations que nous demandons aux utilisateurs de fournir, il existe également une multitude de données générées par le plugin d'adhésion, qui comprend:

• Statut de membre (actif ou inactif);
• Niveau d'adhésion;
• Date d'expiration de l'adhésion;

Il n'y a rien au-dessus des paramètres. Ce n'est probablement pas très différent des dizaines de milliers d'autres sites qui exécutent le même ensemble de membres.

Bien que le site lui-même ne soit pas trop compliqué, cela ne signifie pas que vos données utilisateur sont faciles à trouver. Voyons comment une tâche apparemment simple peut devenir un défi qui prend du temps.

Le défi

Le client avait un besoin très élémentaire. Ils voulaient une exportation de tous les membres actifs qui préfèrent recevoir une copie imprimée du bulletin de l'organisation. D'après ce que nous avons, cela ne devrait prendre que quelques minutes pour improviser. C'était loin.

C'était beaucoup plus difficile que je ne l'imaginais. Les données dont nous avions besoin étaient présentes dans la base de données. Mais essayer de le reconstruire s'est avéré être une tâche presque monumentale pour quelqu'un qui n'est pas un assistant de requête de base de données.

Cependant, c'est pourquoi nous avons des plugins, non? Et il existe des tonnes d'options différentes, à la fois gratuites et premium. Mais, peu importe ce que j'ai essayé, je n'ai pas pu obtenir exactement ce dont l'exportation avait besoin. C'est pourquoi:

• Les données personnalisées que nous demandons aux membres de fournir nous est assez facile à obtenir. C'est dans la table wp_usermeta, que les plugins d'exportation d'utilisateurs peuvent généralement trouver. Par conséquent, générer une liste d'utilisateurs qui souhaitaient cette copie imprimée du bulletin était assez simple.
• Les autres données relatives aux membresCependant, il est stocké dans une autre table unique au plugin d'adhésion. Même un plugin de trading assez robuste que j'ai utilisé ne pouvait pas m'aider ici.

Le résultat a été que j'ai pu savoir qui avait demandé l'édition postale du bulletin, mais je n'ai pas pu savoir si leur adhésion était active, ce qui n'était pas très utile.

Bien sûr, ces informations ont été stockées dans une table adjacente dans la même base de données, mais elles pourraient également se trouver sur Jupiter à mes fins. C'était comme chercher les clés de la maison, pour découvrir que son voisin les avait en quête de secours.

Enfin, j'ai trouvé un plugin d'exportation, qui comprenait un plugin pour le plugin d'adhésion, qui m'a aidé à recueillir les données dont j'avais besoin. Si cela n'avait pas existé, vous seriez toujours coincé avec juste une demi-solution.

L'expérience peut-elle être améliorée?

Tout cela m'a laissé me demander comment ces situations peuvent être améliorées ou évitées en premier lieu. C'est une décision difficile.

Tout d'abord, j'avoue que ce genre de défis n'est pas mon point fort. Quelqu'un avec beaucoup d'expérience PHP et MySQL pourrait probablement trouver une solution personnalisée. Je? Je suis parti pour expérimenter avec les plugins et gémir quand ils ne fonctionnent pas comme prévu.

Mais une question mérite d'être posée: Dans le cas où une telle expérience est requise pour exporter un ensemble complet de données utilisateur? Il semble qu'il devrait y avoir un moyen plus simple de l'utiliser pour travailler.

Le fait que WordPress permet aux plugins de créer leurs propres tables de base de données est compréhensible et même bénéfique. Il garantit que nous pouvons installer et désinstaller des plugins sans craindre de casser quelque chose.

Cependant, alors que tout cela fonctionne à l'œil nu, c'est tout sauf pour ceux d'entre nous qui tentent d'accéder aux données sous-jacentes.

Peut-être qu'il devrait y avoir une API qui nous permet d'obtenir tout ce qui concerne un utilisateur spécifique, quel que soit l'endroit où il est stocké dans la base de données. Mais je laisserai cette discussion à ceux qui connaissent les avantages et les inconvénients d'une telle fonctionnalité.

Jusque-là, je continuerai à assembler les choses selon les besoins des clients, en espérant un processus beaucoup plus propre à l'avenir.