Plugin en cours de développement : Creative Commons Image Management

Il y a longtemps, on avait parlé de tutoriels pour le développement d’un plugin, qui reprendraient toutes les étapes, sur un cas réel : au lieu d’avoir des bouts de fonction, pas toujours simples à intégrer les uns aux autres dans le codex, vous auriez un exemple de démarche complète.

Difficile à faire pour les plugins que je code pour mes clients, qui sont très orientés SEO, et pas diffusés. En revanche, je suis en train de travailler en ce moment sur un plugin pour gérer les images sous licence Creative Commons dans mes blogs, en ayant un peu assez de faire ça “à la main” ou en utilisant une armada de plugins. Comme celui-ci sera bien évidemment sous GPL (et proposé sur le repository), c’est l’occasion de faire ce tuto.

A qui s’adresse le tutoriel ?

A ceux qui connaissent déjà php et javascript. Il ne s’agit pas d’un tutoriel “basic”, et les fonctions de base de php ne seront pas expliquées (mais vous pouvez vous retourner vers la doc).

De la même façon, les fonctions du codex ne seront pas réexpliquées (c’est déjà fait, et si vous ne parlez pas anglais, le traducteur de Bing est là, meilleur que celui de Google). Enfin, j’ai choisi de développer en procédural, et pas en orienté objet, pour que cela soit plus accessible. (Ceux qui maîtrisent la POO sont assez grands pour adapter !)

On va donc parler de :

• bonnes pratiques
• logique d’organisation
• structuration de données
• sécurité
• interaction avec des API externes (Flickr)
• trucs et astuces

En particulier, comme je ne vais pas développer dans l’ordre logique, mais commencer par le plus immédiatement utile, vous verrez à chaque étape, comment on préserve l’avenir en évitant de coder en dur des éléments répétitifs ou voués à être modifiés.

Le principe du plugin

Les termes de la licence Creative Commons, quelle qu’elle soit, demande que l’on affiche au minimum la licence, avec un lien vers le contenu de la licence et le nom de l’auteur. Il va donc falloir stocker ces données dans WordPress, “quelque part”, et tant qu’à faire, dans la mesure du possible, les importer automatiquement lors de l’upload de l’image, via l’API Flickr.

Qui peut le plus peut le moins, pendant qu’on y est on pourra importer d’autres informations, quand elles existent :

• la description
• les tags
• les données exifs
• les données de géolocalisation

Le plugin, par ailleurs, permettra d’afficher automatiquement ces informations, sous la photo ou au bas du post, et de faire des pages reprenant toutes les photos utilisées, ou toutes les photos d’un auteur. Bien entendu, tout cela en multilingue.

Le principe étant de ne pas réécrire totalement ce qui est déjà très bien fait, le plugin s’appuiera sur au moins deux plugins que j’utilise régulièrement, peut-être trois :

• Remote Image Grabber
• Media Rename
• Taxonomy MetaData

Le choix du modèle de données

Pour savoir ce que l’on va choisir pour stocker les données, on commence par faire un descriptif détaillé, en précisant à chaque fois :

• l’origine de la données (API Flickr, manuel, WordPress)
• son format
• si elle est obligatoire ou facultative
• si elle doit être traduite ou pas (la nécessité de traduire facilement une donnée peut avoir un impact sur le modèle de données)

La méthode “bête et brutale” consisterait à tout stocker dans des champs personnalisés, sur chaque image, mais on s’aperçoit vite que l’on a des données répétitives :  celles qui concernent l’auteur, et celles qui décrivent la licence. Il faut donc, au niveau du media, stocker un lien vers l’auteur (ça tombe bien, c’est un standard WordPress), vers les données de la licence (soit via un champ personnalisé, soit via une taxonomie), et les données “uniques”.

Au niveau de l’auteur, on va rajouter des metas.

Le choix du stockage des licences (option ou taxonomie) va faire l’objet d’un article à part.

Les différentes parties du plugin

Il va donc falloir :

• vérifier au démarrage que le(s) plugins nécessaires sont installés, avertir s’ils ne le sont pas, proposer de les installer et prévoir des solutions (dégradabilité, l’essentiel doit marcher)
• faire une ou plusieurs pages d’options permettant de stocker la clé d’API, les choix de données à importer, le format d’affichage
• définir un user role, gérer les fonctions traitant de l’auteur, créer une metabox pour l’auteur
• définir une taxonomie ou une option, générer les valeurs de base
• créer la metabox sur la page d’édition des media
• rajouter des fonctionnalités à l’import de photo via ImageGrabber
• créer des templates
• créer des fonctions d’affichages des listes de medias avec les shortcodes qui vont avec.

Les données sur la licence sont donc :

• un identifiant unique
• un sigle ( CC BY NC SA )
• un nom complet “Creative Commons Attribution Pas d’utilisation Commerciale Partage à l’identique”
• une url qui renvoie vers la description complète sur le site Creative Commons.

Bien s’organiser

Je n’aime pas commencer par le “commencement” c’est-à-dire l’initialisation du plugin, avec les contrôles et les pages d’options.

L’expérience prouve qu’on oublie toujours quelque chose quelque part, et je préfère donc laisser cela à la fin, sauf pour deux choses :

• la déclaration du domaine de traduction via load_plugin_textdomain, pour pouvoir commencer à travailler tout de suite correctement
• la mise en place d’une routine pour mettre à jour mes propres plugins en automatique, pour laquelle j’utilise un code trouvé sur github
• j’ajoute, en haut, en commentaire, pour les retrouver facilement :
  • le textdomain
  • le préfixe que je vais utiliser pour toutes les fonctions
  • la liste des options que je définis peu à peu “en dur”, pour rajouter à la fin la page de gestion des options

Pour plus de lisibilité, je vais séparer mon code dans plusieurs fichiers (si j’étais en POO, cela correspondrait grosso-modo à mes classes) :

• gestion des options
• gestions des utilisateurs
• gestion des images
• interaction avec l’API Flickr
• définition des templates et des shortcodes

La page de mon plugin proprement dit ne comprendra donc que les fonctions d’initialisation, et les appels aux autres fichiers.

Y’a plus ka…

(Et le blueprint qui sert de fond à l’image en à la une est une photo sous licence CC BY NC SA  de Big Save Diode)