Ici, l’exercice est plutôt simple. La seule vraie question porte sur le stockage des licences. Pour le reste (utilisateur et media), il s’agit juste de faire un tableau de correspondance entre les tables WordPress et les données issues de l’API. Après avoir fait cela, on pourra coder, enfin !

Les données utilisateurs

Diagramme des deux tables

wp_​users et wp_​usermeta

Le détail de la base de données se trouve dans le Codex, pour wp_​users et wp_​usermeta.

Dans la table wp_​users,

  • l’ID est un camp numérique entier, créé par WordPress
  • le user_​login est un champ « varchar » de 60 caractères, indexé, unique et qui ne peut pas être vide
  • le user_​pass est stocké sous forme MD5
  • le user_​nicename est un « varchar » de 50 caractères, il correspond au slug de l’auteur, il n’est pas accessible par défaut dans WordPress, et il a par défaut, la même valeur que le user_​login
  • l’email est stocké sur 100 caractères comme l’url
  • le nom affiché est stocké sur 250 caractères (varchar)

Toutes les autres informations que vous avez sur votre profil utilisateur se retrouvent dans la table wp_​usermeta, en particulier : le prénom, le nom, le surnom et les capacités (qui correspondent, de façon indirecte, au rôle).

Mappage de la page de profil

Où sont stockés les champs informations du profil utilisateur

La répartition des informations entre la table wp_​users et la table wp_​usermeta est un peu bizarre, avec des éléments d’identité comme le pseudonyme qui apparaissent dans la table user, des éléments uniques et obligatoire (les capacités) qui apparaissent dans la table meta, l’url qui n’a rien d’obligatoire qui est dans la table user (ce qui empêche d’avoir plusieurs « urls »). C’est un peu l’historique qui veut tout cela, l’essentiel est de savoir où sont stockées les informations.

La création d’un utilisateur se fait grâce à la fonction « wp_​insert_​user » qui prend comme arguments l’ensemble de ces données (user et usermeta).

Les données disponibles pour un utilisateur Flickr, via l’API, sont :

  • le nsid, ou identifiant unique de l’utilisateur, alphanumérique, avec un @
  • le username, utilisé dans l’url (l’équivalent du nicename)
  • le realname, qui correspondrait à la fois au pseudonyme et au nom à afficher publiquement (Flickr n’a pas de prénom et nom)
  • la description
  • trois urls utilisateurs : pour la galerie ( photosurl ), pour le profil ( profileurl ) et pour le mobile ( mobileurl )
  • une localisation, un fuseau horaire et des données statistiques sur les chargements
  • pas d’email, pas de méthode de contact

Le mappage va donc être facile :

Après avoir vérifié qu’on pouvait utiliser l’arobase dans un identifiant WordPress (on peut) ça donne ceci :

Dans WordPress En provenance de Flickr Comment
wp_​users -> ID  Générée à la création de l’utilisateur
wp_​users -> user_​login  nsid Vérifier qu’il s’agit d’un format « Flickr »
wp_​users -> user_​pass  Généré à la création de l’utilisateur
wp_​users -> user_​nicename  username
wp_​users -> user_​email Donnée obligatoire à la saisie, mais pas à la création via l’API, on peut théoriquement laisser vide, mais il sera demandé dès qu’on fera une modification manuelle de l’utilisateur. Le générer automatiquement.
wp_​users -> user_​url  profileurl  Attention à la sécurité des données
wp_​users -> display_​name  realname
wp_​usermeta -> metakey nickname  realname
wp_​usermeta -> metakey description  description  Attention à la sécurité des données
 wp_​usermeta -> metakey _​llncci_​gallery_​url  photosurl  Attention à la sécurité des données
 wp_​usermeta -> metakey _​llncci_​origine  « Flickr »
wp_​usermeta -> metakey wp_​capabilities  « Photographe »

On sait donc qu’il va falloir générer des données automatiquement pour l’email, et vérifier les données qui peuvent contenir des urls. Les données utilisées par wp_​insert_​user sont filtrées, mais pas l’url de la galerie de photo.

Il faut par ailleurs créer notre nouveau rôle utilisateur.

Stocker l’origine est un vieux réflexe d’informaticien, ça ne mange pas de pain et ça peut toujours servir. Il ne faut pas penser seulement à la création, mais éventuellement à la mise à jour de l’utilisateur. Les données à traiter diffèrent en fonction des APIs, savoir grâce à un champ quelles sont les données disponibles à traiter évitera bien des problèmes.

Les licences

Avant de s’occuper des données du media, il faut décider comment stocker nos licences.

En théorie, une information « répétitive » dont on doit contrôler l’affichage et donc la saisie (avoir toujours CC BY et pas de temps en temps Cc by ou CC-​​BY), pour lesquels beaucoup de posts auront la même valeur, doit être stockée dans une taxonomie.

Encore plus si on imagine qu’on va rechercher des posts (ici des images) sur la base des valeurs, ce qui sera le cas, pour afficher des pages de crédits avec les photos sous licence CC. C’est, entre autres, une question de performances.

Mais un problème se pose : bien qu’il y ait des discussions en cours, il n’y a pas, pour l’instant, de metadonnées pour les taxonomies. Cela viendra sans doute, mais les développeurs du Core veulent d’abord simplifier la structure actuelle pour repasser sur deux tables.

Or moi, j’ai besoin de metadonnées. Voici ce que je dois stocker au niveau de la licence :

  • une id unique, qui peut-​​être « verbeuse » comme le cc-​​by-​​20, mais sur laquelle je ne peux pas me baser de manière absolue
  • un affichage court : CC BY
  • un affichage long : Creative Commons Attribution qui doit être traduisible et compatible WPML
  • une url de référence, théoriquement sur le site Creative Commons et donc théoriquement construite à partir de l’url unique, mais cela reste théorique, et valable uniquement pour les licences CC. D’autres licences libres existent, celles utilisées sur Flickr, celles utilisées sur DeviantArt
  • éventuellement, une description de la licence.
  • et surtout, le lien entre le terme et la définition de licence de Flickr

J’ai donc deux à trois données de plus que ce que WordPress propose en standard.

Comment stocker les données supplémentaires ?

Il existe quelques plugins qui permettent d’ajouter des metadonnées aux licences. J’ai préféré Taxonomy Metadata qui fait le pari de monter une structure « standard » wordpress avec une table meta et des noms de fonction conformes aux conventions WordPress. Le plugin reprend une soumission dans le trac, et il y a de fortes chances que la fonctionnalité soit créée de cette façon, « quand /​ si » elle l’est. (En clair, ça passe ou ça casse). Il existe d’autres plugins qui stockent ces meta sous forme sérialisées dans la table wp_​options.

Côté utilisation et performances, j’ai une petite préférence pour la première solution. Par contre, cela a un impact sur la comptabilité WPML, puisque ce plugin ne traduira pas les données de la table supplémentaire. Cela implique de « traduire » les termes (avoir un terme en anglais, un en français, etc) et donc de lier plusieurs termes à une seule licence Flickr.

Premier commandement de l’informatique : jamais une donnée de façon redondante ne stockera !

Troisième problème : l’utilisation d’un plugin supplémentaire. Cela ne me pose pas de problème sur les sites que  je gère, où je peux toujours trouver des solutions, pour un plugin qui va aller sur le repository, c’est loin d’être idéal.

Conclusion : une custom taxonomie avec des options

  • création d’une taxonomie de type hiérarchique, dont les valeurs de base seront créées lors de l’initialisation du plugin
  • gestion des informations supplémentaires via une page d’options dans le plugin, et stockage sous forme d’options sérialisées, avec un transient dédié à la correspondance avec Flickr, pour la performance
  • et bien sûr, création d’un fichier wpml-config.xml pour stocker ce qui doit être traduit et ce qui doit être copié.

Le modèle de données pour les images

Il devient donc extrêmement simple :  à l’exception du « crédit », des données Exif et de géolocalisation, tout correspond à des éléments standards de WordPress. Il suffira de rajouter quelques metakey, dans une metabox, et de travailler sur les fonctions d’importations et de mise à jour.

On se note aussi que les options du plugins devraient permettre de choisir quelles sont les données importées, ainsi que la taxonomie à utiliser pour les tags Flickr (catégorie, tags ou custom taxonomie).

Je n’ai plus qu’à coder… ce qui va sans doute délayer de quelques jours le prochain article de ce tutos.

Le modèle de données est une des bases d’un cahier des charges

Il est indispensable de faire cet exercice quand vous demandez un développement à un prestataire. Vous n’êtes pas obligés d’aller aussi loin techniquement parlant, mais vous devez avoir une vision détaillée et complète des données que vous voulez utiliser et de comment vous voulez les utiliser. (Les processus).

Cela permet de se rendre compte des éventuelles incohérences (comme le stockage des données de licences chez Flickr), que certaines données peuvent être manquantes et se demander comment les récupérer, bref d’éviter de bricoler en fin de parcours, ce qui conduit généralement à des données « mal stockées » ou redondantes.

Trois points importants sont à rajouter dans un « vrai » cahier des charges :

  • ce que j’appelle le « workflow » et qui décrit quels sont les différents utilisateurs qui peuvent intervenir dans un processus, s’ils ont les mêmes droits ou s’il y a certaines données que certains utilisateurs ne doivent pas voir. Cela peut impacter le modèle de données ;
  • d’une manière plus générale, tout ce qui va être lié à un affichage différent des données en front-​​end, selon le type d’internaute ; cela rejoint le premier point, mais ce n’est pas la même chose ; des exemples typiques :
    • un catalogue avec un prix pour les particuliers et un prix pour les professionnels,
    • un affichage de la langue par défaut,
    • un affichage de prix dans une devise en fonction du pays (et donc pas en fonction de la langue)…
  • une première estimation des performances nécessaires ; c’est le point le plus difficile pour un non technicien, mais vous pouvez donner des informations qui vont aider le professionnel à y réfléchir :
    • le nombre de produits et de catégories de produit dans un catalogue
    • le nombre de visites /​ commandes par jour que vous attendez raisonnablement (en gros, ce qu’il vous faut pour être rentable, sorti de votre business plan) ; si vous faites beaucoup plus vous aurez assez d’argent pour faire évoluer le site
    • le nombre de personnes qui vont travailler dans l’admin du site en même temps (une, vingt, cinquante…)
    • la fréquence de mise à jour des données, qui peut avoir un impact sur le cache, et donc les performances (un site qui donne en direct les cotations en Bourse a un cache beaucoup plus difficile à gérer qu’un blog qui publie une fois par mois).

Dans le cadre d’un plugin WordPress, on va passer beaucoup de points rapidement, juste pour vérifier qu’effectivement, l’API WordPress permet de les exécuter sans problème. Mais quand la solution n’a pas encore été choisie, il faut aller très en détail dans les processus. Et « a priori » on ne choisit pas une solution parce qu’on la connait bien. On choisit, après coup, une solution qui répond aux besoins.

(Oui, je sais, on dérive par rapport au tuto… mais c’est important aussi, non ?)

Le puzzle qui illustre cet article est une image sous licence CC BY NC de Susy Morris, et vivement que j’ai fini mon plugin pour arrêter de saisir ça à la main à chaque fois !

Que pensez-vous de cet article ?
Super0
Bien0
Bof0
Nul0
Poster un commentaire