J’ai eu besoin récemment d’inclure un éditeur visuel dans un plugin WordPress. Je pensais que c’était une tâche aisée sans chercher sur Google : il n’y avait qu’à faire comme les développeurs de WordPress !

J’ai pensé à tort et ça m’a confirmé une fois de plus que le code source de WordPress était un joyeux bazar.

Le besoin

Mon besoin était tout bête : sur une seule page de mon plugin, j’avais besoin de transformer un bête champ texte en éditeur avancé avec possibilité d’uploader des images et tout ça.

Avec ce simple besoin, j’ai cependant constaté :

1. qu’il était pénible de remonter le cheminement logique de l’éditeur jusqu’à l’inclusion des scripts
2. qu’il n’y a pas de façon standard d’ajouter l’éditeur : il y a bien une fonction wp_tiny_mce mais elle ne fait pas tout … c’est à dire que sans inclure ses dépendances (non documentées), cette fonction n’est d’aucune utilité
3. qu’on trouve à boire et à manger dans le code de WordPress. Pour le code is poetry, on est plutôt proche du SMS kikoololesque

Après avoir trouvé ma solution, je suis cependant tombé sur un article expliquant comment inclure TinyMCE dans WordPress. Elle est juste mais nous verrons que seule la moitié du chemin a été faite avec.

La solution

<?php
add_action('admin_menu', 'include_tinymce');
function include_tinycme()
{
  add_action('admin_head', 'wp_tiny_mce');
  wp_enqueue_script('jquery-ui-core');
  wp_enqueue_script('jquery-ui-tabs');
  wp_enqueue_script('editor');
  wp_enqueue_script('media-upload');
  add_thickbox();
}

Plusieurs remarques par rapport à ce code :

• Le choix de l’action
  Le mien s’est porté sur admin_menu. Vous pourriez en choisir une autre, du moment qu’elle s’exécute avant admin_head. J’ai choisi celle-là parce que c’est là que j’y construis les menus de l’administration : WordPress est initialisé et n’a pas encore été affiché.
• Le choix wp_enqueue_script
  J’aurais pu caller cette fonction en tant que filtre de admin_head et utiliser la fonction print_script MAIS je soupçonne cette dernière fonction de ne pas vérifier si un autre script du même nom a été inclus.
  J’ai choisi de ne pas créer de conflit : wp_enqueue_script ne chargera qu’1 fois et 1 seule le script nommé. Pas de chichi.
• L’inclusion de l’éditeur
  Pour afficher l’éditeur, il suffira d’appeler la fonction the_editor() en lieu et place de son textarea. Vous noterez toutefois que vous serez obligé(e)s de nommer l’éditeur content sous peine de devoir ajouter quelques filtres supplémentaires.

Après à vous de vous débrouiller avec l’architecture de votre plugin. Personnellement j’ai tout basculé dans des classes depuis un bon moment pour éviter tout conflit de nom.

La solution optimisée

Cependant ne crions pas victoire si vite : avec ce qu’on a fait, nous avons juste réussi à inclure TinyMCE sur toutes les pages de l’admin WordPress. Ce n’est pas ce que je recommanderai pour deux raisons :

1. le respect des performances utilisateurs : charger 150Ko de JavaScript pour rien sur une page sans TinyMCE, c’est du gâchis
2. on ne fait pas une généralité pour une exception

Heureusement pour nous WordPress est bien fichu car il nous fournit 2 variables globales (*hm*) d’exception :

• $plugin_page
  Cette variable contient le nom de la page renseignée par les méthodes add_management_page() et add_options_page(). On aurait pu passer directement par admin_print_script* mais il faisait flemme d’ajouter une fonction de plus.
  Exemple :

  <?php
  add_management_page('Titre', 'Label', 8, 'test_management_page', 'mon_callback');
  //$plugin_page vaudra 'test_management_page'

• $pagenow
  Cette variable contient le nom du fichier actuellement exécuté.
  Si vous vous trouvez sur wp-admin/tools.php?page=test_management_page, $pagenow vaudra tools.php

Avec ces deux variables, on est capable de charger ce qu’on veut, où on veut et quand on veut.

Au final, ça nous donnerait ceci :

<?php
add_action('admin_menu', 'include_tinymce');
function include_tinycme()
{
  global $plugin_page;
  if ($plugin_page === 'test_management_page')
  {
    add_action('admin_head', 'wp_tiny_mce');
    wp_enqueue_script('jquery-ui-core');
    wp_enqueue_script('jquery-ui-tabs');
    wp_enqueue_script('editor');
    wp_enqueue_script('media-upload');
    add_thickbox();
  }
}

Là on a bien terminé le travail.

Conclusion

Il n’y a au final pas grand chose à chose à ajouter pour disposer de TinyMCE. Encore faut-il le savoir.

On peut cependant regretter le manque de flexibilité de cette manipulation :

• j’ai definé la liste des fichiers en cherchant les noms de fonctions JavaScript manquantes (merci Firebug et l’affichage des exceptions en console)
• la liste des dépendances de wp_enqueue_script n’est absolument pas complète : editor devrait appeler wp_tiny_mce et media-upload (voire jquery-ui-*)

Un jour WordPress nettoiera son code pour faciliter la maintenance …

J’ai publié il y a quelques jours la version 1.2 du plugin Amazon Widgets Shortcodes. Cette version suit plusieurs autres publications plus intimistes, à des fins de tests grandeur nature. Ce fût en tous cas suffisant pour commencer à attirer l’attention de traducteurs.

Concrètement, ce plugin facilite la monétisation des blogs WordPress en évitant de copier du HTML fourni par Amazon. Les widgets Amazon s’intègrent du coup par le biais de petits raccourcis textuels, les shortcodes.

Présentation et explications sur la conception du plugin.

Widgets Amazon

Amazon fournit des widgets au travers de son programme Partenaires (également nommé Associates dans le reste du monde). Ces widgets permettent d’intégrer des fonctionnalités sympathiques sur son propre site ou blog à partir d’un code HTML généré par leur interface.

La liste des widgets et des fonctionnalités est assez importante :

• lien produit (avec ou sans image)
• widget carrousel (présentation de produits dans un carrousel d’images)
• widget slideshow (présentation de produits sur une bande déroulante)
• widget envies cadeaux
• liens textuels
• liens aperçu produit
• liens contextuels
• etc.

Les widgets se créent en ligne et au final, leur code HTML nous est gentiement proposé.

Premier constat : le code fourni par Amazon a beau être fonctionnel, c’est quand même un sacré bazar. Pour peu que l’on bascule de l’éditeur Visuel à l’éditeur HTML de WordPress, le code est nettoyé par endroit le rendant quasi inutilisable.

Second constat, copier ce code dans l’éditeur visuel de WordPress (TinyMCE) est passablement horrible avec parfois jusqu’à 10 lignes de HTML illisible.

Enfin, côté maintenance c’est pas gagné : si Amazon change le code HTML des éléments sans assurer de rétrocompatibilité (ce que je ne leur souhaite pas), les widgets déjà insérés seraient rendus inopérants.

Arborescence du code d'Amazon Widgets Shortcodes

Les objectifs fixés et avoués du plugin Amazon Widgets Shortcodes

Toujours désireux d’utiliser les widgets Amazon et sentant que ça pouvait être pratique, je me suis dit que c’était l’occasion rêvée de produire un plugin utile, bien conçu et fiable.

En développant ce plugin, je me devais d’atteindre ces objectifs :

• le rendre internationalisable (i18n)
• le proposer en 2 langues minimum (français et anglais)
• permettre son exploitation facilement et sans se prendre la tête (KISS)
• fournir une documentation d’utilisation appropriée
• rendre l’évolution du code aussi souple que possible

Stratégie de développement

Maintenant que j’avais les idées, il fallait les mettre en place. Voici comment j’avais envisagé les étapes du développement :

1. support d’1 seul widget Amazon
2. augmentation du nombre de widgets Amazon supportés
3. stabilisation de l’API et internationalisation
4. configuration intégrale depuis l’admin WordPress
5. intégration des widgets depuis l’éditeur HTML WordPress (TinyMCE)
6. intégration du copier/coller de code HTML Amazon
7. support intégral des widgets
8. améliorations pratiques et ergonomiques
9. utilisation en tant que widgets dans les thèmes WordPress
10. gestion intégrée des widgets (Amazon ne fournissant aucune API à ce niveau)

Cette progression permet de créer petit à petit l’application, de la rendre modulaire et extensible. L’ajout et le support de nouveaux widgets ne doit pas remettre en cause l’architecture du plugin.

Code JavaScript d'Amazon Widgets Shortcodes

Ce à quoi il faut penser en développant un plugin

Développer un plugin c’est bien. Il faut cependant toujours avoir en tête qu’il ne sera pas installé que sur son propre blog. Ça doit être le leitmotiv qui accompagne toute nouvelle idée afin de prévoir les installations et mises à jour.

Voici 5 points clés pour développer un bon plugin :

1. penser utilisateur avant tout (c’est lui qui doit savoir l’utiliser, pas ses développeurs)
2. penser que le développement pourra se faire en équipe (clarté du code, documentation)
3. penser que le plugin pourra être utilisé dans plusieurs langues (i18n)
4. penser aux scénarios de mise à jour (base de données, tests fonctionnels/unitaires)
5. penser que ce plugin n’est pas le seul sur le blog (optimisation, nommage)

Intégration d’un widget Amazon par copier/coller

C’est le serpent qui se mord la queue diraient certains.
Et pourtant, c’est la meilleure fonctionnalité qu’on puisse apporter. Tout le monde n’étant pas technicien, les utilisateurs lambda apprécieront de pouvoir simplement se débarrasser de leur code HTML Amazon pour le convertir sur leur blog.

Simple comme bonjour !

Conclusion

Le développement d’un plugin WordPress est relativement aisé. Certaines parties de la documentation sont quelque peu obscures, notamment celle qui touche l’éditeur HTML et son internationalisation. Il m’a fallu m’inspirer d’autres plugins mais aussi comprendre que WordPress 2.5 mettait en cache la configuration de TinyMCE dans un fichier.

L’autre partie ardue fût le plugin TinyMCE : la documentation est toujours partagée entre la version 2 et la version 3 et là encore, la meilleure documentation reste le code source d’origine. Je saluerai au passage le gros effort de lisibilité que leur équipe a apporté. On en prendrait presque du plaisir à le lire

Quoiqu’il en soit, le plugin WordPress Amazon Widgets Shortcodes est bel et bien prêt à être utilisé par le grand public. Le minimum vital est là. Le confort aussi.