Préparation du modèle de données

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

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).

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 :

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 !