J’ai contacté le support à plusieurs reprises pour prendre connaissance de la mise en place de noms de domaine personnalisés et de la mise en place de nouvelles fonctionnalités. Bénéficier d’une adresse en monblog.fr au lieu de monblog.canalblog.fr est intéressant, en terme d’image mais aussi d’indépendance.

Le gros problème est que Canalblog ne m’a jamais répondu. Ni à moi ni à plusieurs utilisateurs.
En 2010, ce sont donc plus de 700 000 blogs qui se retrouvent captifs d’une plateforme avec une seule porte de sortie : le copié/collé de leurs articles. Difficilement acceptable.

Canalblog Importer : plugin d’import de Canalblog vers WordPress

Las de ce mutisme de la part de Canablog, j’ai donc décide de me mettre à l’ouvrage pour offrir une extension WordPress répondant à ces 2 critères :

• importer un maximum d’éléments
• en demander le moins possible à l’utilisateur

Une fois le plugin activé, une nouvelle entrée fait son apparition dans la rubrique d’administration Outils > Importer : Canalblog Importer.

L’import Canalblog en 5 étapes

L’import de son blog Canalblog se déroule par la suite en 5 étapes :

1. Configuration
2. Import des mots-clefs
3. Import des catégories
4. Import des articles
   • Import des articles
   • Import des commentaires
   • Import des médias
5. Nettoyage

La configuration de l’import est le moment requérant toutes vos capacités pour taper l’adresse de votre blog. Oui c’est tout. S’ensuit alors une suite de recommandations, entre autre pour s’assurer du bon déroulement de l’import. Ça concerne la configuration des permaliens et le format de dates sur Canalblog.

Une fois le bouton d’import cliqué, il faudra réitérer le clic au début de chaque étape clé, la plus longue étant l’import des articles.
Techniquement, sur un blog possédant plusieurs milliers d’articles sur 5 ans, il m’aura fallu à peine 20 minutes de patience et 5 clics.
Difficile d’en demander plus à quelqu’un n’ayant aucune notion technique.

Écran de configuration de Canalblog Importer

Canalblog Importer : les fonctionnalités

Les différentes étapes de l’import résument à elles seules les fonctionnalités de cet outil d’import :

• import des mots-clefs
• import des catégories
• import des articles
• import des commentaires
• import des médias
• import des auteurs
• correction des liens inter-articles
• intégration des médias dans le gestionnaire de médias de WordPress − avec génération de vignettes à la clé et utilisation de celles-ci au sein des articles
• reprise de l’intégration et tolérance à l’erreur : l’import peut être relancé indéfiniment, les contenus ne seront pas réimportés en double

En gros, ce que cette extension ne fait pas, c’est le café, la récupération de la blogroll et la migration du référencement vers votre nouveau blog − faute au manque de nom de domaine et à l’impossibilité de dire aux moteurs de recherche les nouvelles adresses des articles hébergés sur Canalblog.

J’ai essayé de rendre toutes les étapes conviviales, explicatives et rassurantes sur le processus en cours et restant. C’est encore plus simple que de rédiger un article de blog. Enfin, je trouve

Écran d'aide à la fin d'import

La clé de la réussite : cURL et XPath

Sous le capot, la dépendance à PHP 5.1+ s’explique par 3 choses :

• l’autoloading PHP
  J’en ai un peu marre de faire des require à tour de bras donc je fais fi des recommandations de WordPress : PHP4 est mort, faut arrêter avec ce délire de compatibilité, pas en 2010 (ni même en 2008 ou 2009).
• cURL
  C’est vraiment la boîte à outil de la manipulation HTTP. Elle est abstraite dans la classe WP_Http. Son utilité ? Récupérer du contenu distant. Pratique pour rapatrier le contenu de pages HTML, entre autre.
• DOMXPath
  Associé au DOM PHP5, c’est un outil formidable pour requêter au sein d’un document HTML … disons, récupéré à distance ? La structure des thèmes Canalblog étant identique (pour peu qu’ils n’aient pas été retouchés en mode avancé), le travail de constitution des sélecteurs XPath n’en était que plus facilitée.

Donc clairement, cette extension effectue un travail bête et méchant de crawl des pages d’un blog, de manière structurée afin de peupler tranquillement un blog WordPress de ce même contenu.
Je me suis basé au maximum par les outils déjà existants … y compris la classe d’import WordPress.com ! Je l’ai réutilisé pour l’import des médias vu qu’elle correspondait parfaitement au besoin.

Le pouvoir aux utilisateurs

Au-delà du simple aspect technique de la réalisation de l’extension (qui a demandé quelques heures de travail tout de même), il faut comprendre une chose : capturer ses utilisateurs pour éviter leur fuite en cas de déclin d’un produit n’empêchera pas les utilisateurs de trouver une solution à leur problème.

La réponse au problème de la communauté est venue de la communauté elle-même : elle veut partir ? Elle part et s’en donne les moyens.

Le seul moyen pour Canalblog de conserver ses utilisateurs, après cette porte de sortie offerte à tous les usagers, c’est d’innover et de les reconsidérer comme le moteur de leur croissance. Tout effort pour entraver cette démarche serait une pure perte de temps, n’ajoutant que trop de douleurs à une agonie certaine.

Canalblog Importer est une extension gratuite pour WordPress, libre de téléchargement, d’utilisation et de modification (sous réserve que le code modifié soit republié sous la même licence). L’extension constitue ainsi une bonne base pour constituer de nouveaux imports d’autres plateformes, fermées elles aussi.

Cet outil me paraît indispensable alors j’ai décidé de l’intégrer à WordPress : WP-LESS est né.

LESS en quelques mots (ou lignes de code)

Pour mettre en exergue l’intérêt de LESS, je reprends un exemple officiel :

#defaults {
  @width: 960px;
  @color: black;
}
.article { color: #294366; }
.comment {
  width: #defaults[@width];
  color: .article['color'];
}

Le source précédent utilise 3 principes :

• les variables (dont leur nom est préfixé par un @)
• les namespaces (ici, #defaults) pour regrouper des propriétés
• les accesseurs (pour obtenir la couleur de l’article au sein du commentaire)

Une fois ce code compilé par LESS, la feuille de style générée se résume à ceci :

.article { color:#294366; }
.comment {
  width:960px;
  color:#294366;
}

C’est simple et efficace. Surtout quand on sait que l’on peut effectuer des opérations mathématiques, y compris en utilisant les variables, la conception va se retrouver facilitée.

L’intérêt de WP-LESS

WP-LESS intègre le parseur PHP, phpless, au sein de WordPress pour minimiser le travail à fournir.

Une fois activé, dès qu’il détecte un fichier comportant l’extension .less, il compilera automatiquement le fichier pour produire des CSS interprétables par les navigateurs Web. Pour des raisons de performances, cette compilation n’est effectuée que lorsque le fichier .less est modifié. Cela implique également qu’à chaque mise à jour de votre fichier .less, vous n’avez pas à vous soucier de compiler son équivalent CSS.

De nombreux hooks et filtres sont placées un peu partout dans le code pour permettre à tout développeur, créateur de thème ou bidouilleur de se fixer dessus sans avoir à modifier le code du plugin. Et dans les rares cas où ça ne suffirait pas, tout est extensible puisqu’il suffit d’hériter de l’objet WPLessPlugin pour parvenir à vos fins.
Des tas de choses qu’on ne pourrait pas faire en simple PHP4 (message subliminal : WordPress doit abandonner PHP4).

WP-LESS agit en toute transparence et simplicité.

Quel avenir pour WP-LESS ?

J’ai déjà en tête d’autres fonctions pour simplifier encore plus la vie :

• permettre l’intégration dans un thème en tant que dépendance externe pour permettre aux thémeurs de redistribuer WP-LESS sans avoir à activer le plugin
• proposer des helpers pour ne pas avoir à passer par wp_enqueue_stylesheet (même si c’est la meilleure solution)
• dissocier les fichiers .less des feuilles de style dans l’éditeur de thème avec une validation lors de l’enregistrement
• afficher un tableau de bord montrant l’état des fichiers de cache tout en pouvant les purger

Vous attendriez d’autres fonctionnalités de la part de ce plugin ?

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 …

Pour les besoins du boulot et non plus pour le plaisir, j’ai eu pour impératif de me connecter à un Intranet client via un VPN Citrix. Je ne sais pas pour vous, mais quand j’entends VPN, je commence à avoir des sueurs froides en me disant que la galère ne fait que commencer.

Et bien pour une fois, je peux dire que je n’ai presque pas ramé. Vous allez voir, c’est simple et rapide.

Citrix Presentation Server en 2 minutes

Citrix Presentation Server c’est une manière d’offrir une connexion à des applications à distance indépendamment de la machine que l’on utilise. En clair, que l’on soit sous Linux, MacOS X ou Windows, on est censé pouvoir accéder à des applications d’une infrastructure distante.

Tout se fait via son navigateur Web préféré (Iceweasel sous Debian, Firefox sous Ubuntu dans mon cas). Seulement voilà, quand je souhaitais lancer l’application Putty pour profiter d’une jolie connexion SSH, que nenni !
À la place, j’avais le droit de télécharger un fichier launch.ica qui, j’avoue, ne m’évoquais pas grand chose.

Si on en est là, c'est que ça ne va pas

Installer le plugin ICA pour Linux

Une recherche Google plus tard, je découvre donc sans surprise qu’il me faut installer un client Citrix. J’ai un peu peur en imaginant qu’il ne fonctionne que sur des systèmes d’exploitation arriérés.

Et pourtant, quand on sait ce qu’il faut installer c’est tellement plus simple :

1. Téléchargez le client ICA pour Linux
   1. En prenant la version .tar.gz puis en lançant ./setupwfc
   2. En convertissant le .rpm par un petit sudo alien -i ICAClient-10.6-1.i386.rpm
   3. En utilisant le .deb que j’ai créé avec alien
2. Liez le plugin ICA à votre navigateur Web
   • Sous Ubuntu : ln –s /usr/lib/ICAClient/npica.so /usr/lib/mozilla/plugins/npica.so
   • Sous Debian : ln –s /usr/lib/ICAClient/npica.so /usr/lib/iceweasel/plugins/npica.so
3. Fermez et relancer Firefox/Iceweasel si nécessaire
4. Dans les modules complémentaires, vérifiez que le plugin apparaît bien (ou bien dans about:plugins)

Plugin Citrix vu depuis le gestionnaire de modules Firefox

Conclusion

Bref ça marche bien même sous Firefox 3 et j’en suis content. Le chargement des applications est relativement rapide. Ça fait presque bizarre de voir une application Windows bien se lancer !

C’est également la première fois que je peux me connecter à un VPN distant sans sérieux problèmes. J’ai déjà eu droit aux VPN Cisco à passphrase aléatoire généré par un badge … même le support technique n’a pas pu m’aider : j’étais le premier à les appeler en étant sous Linux !

Chargement de l'application Windows à distance

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.

Alexandre Balmes est à la fois content et déçu des tags de WordPress et pour cause, les nouvelles fonctions ajoutées ne permettent leur utilisation que dans the Loop (la Boucle, la boucle d’affichage du contenu de WordPress).

Certes il y a des plugins qui produisent ce même effet (All in One SEO par exemple) mais c’est un peu comme acheter une crémerie juste pour manger un bon coulant : démesuré.

L’idée

L’idée de départ est de collecter la liste des tags employés sur la page et de l’injecter dans une balise META nommé keywords. WordPress est suffisamment bien fichu pour qu’on n’ait pas à tripatouiller son code.

On va donc décortiquer une fonction qui sera appelée systématiquement sur toutes les pages contenant potentiellement des tags, on aggrègera tout ça pour l’afficher dans l’entête de la page.

Le code

En attendant que j’en fasse un plugin à part entière un peu plus modulable, voici la démarche technique employée.

• Tags : META keywords : code est à copier/coller à la fin du fichier functions.php du thème employé sur votre installation de WordPress

/*
 * Petite vérification qui évite :
 * - de générer une erreur le jour où une telle fonction est introduite
 * - d'utiliser des ressources inutiles (dans l'admin, pas besoin de générer de balise keyword)
 */
if (!function_exists('get_all_tags_meta') && !is_admin()) :
/**
 * get_all_tags_meta()
 *
 * Génère une entête META 'keywords' contenant les tags utilisés sur la page
 */
function get_all_tags_meta()
{
  global $posts;
  //$tags contiendra tous les tags trouvés par la suite
  //Il est tout à fait envisageable de la pré-remplir à la main ou via les options de WordPress (get_option())
  $tags = array();
  //On sort de la fonction si :
  //- les posts n'existent pas (cas d'appel de fonction AVANT que the Loop soit effectuée
  //- il n'y a aucun post (erreur 404, recherche infructueuse, catégorie/tag vide etc.)
  if (!isset($posts) || empty($posts))
  {
    return false;
  }
  //On boucle sur chaque post disponible pour en extraire les tags
  for ($posts_length = count($posts), $i = 0; $i < $posts_length; $i++)
  {
    //Comme il peut y avoir un ou plusieurs tag par post, là encore on boucle
    //Les tags ne sont pas directement stockés dans $posts, il faut passer par l'API de taxinomie (wp_includes/taxonomy.php)
    foreach (get_object_term_cache( $posts[$i]->ID, 'post_tag' ) as $tag)
    {
      $tags[] = $tag->name;
    }
  }
  //Dédoublonnage du tableau final
  $tags = array_unique($tags);
  //On n'affiche l'entête que si elle n'est pas vide, voilà tout
  if (!empty($tags))
  {
    printf('<meta name="%s" content="%s" />', 'keywords', implode(', ', $tags));
  }
}
//On exécute la fonction sur le hook wp_head()
//On pourrait le faire sur wp_foot mais cette fonction n'est pas systématiquement incluses (à tort) sur tous les thèmes
add_action('wp_head', 'get_all_tags_meta');
endif;