Seulement voilà, lors de toute tentative de mise à jour, que ce soit du blog, d’une extension ou d’un thème, un écran de configuration de paramètres FTP apparaît. Comme nous sommes des feignants, on ne voudra en aucun cas ouvrir un serveur FTP, qui n’aurait d’ailleurs pour d’autre intérêt que de faciliter les intrusions dans votre système.

Où trouver l’information ?

En cherchant un peu, je suis tombé sur l’ensemble des directives de configuration de WordPress, dont les constantes liées au système de fichier.
Cette section précise ce qu’il faut savoir, même si c’est suffisamment technique pour perdre toute personne ne comprenant rien au code (et on ne leur en voudra pas).

Le problème vient du fait que si l’utilisateur propriétaire du système de fichier n’est pas le même utilisateur du serveur HTTP, WordPress bascule automatiquement en mise à jour via FTP.

L’astuce consiste à forcer WordPress en mode direct (système de fichier) et à donner les droits d’écriture au groupe propriétaire correspondant à celui du serveur HTTP (www-data pour Apache et Nginx sous Debian et Ubuntu).

Configuration de wp-config.php

Forcer le mode direct est très simple. Il suffit d’éditer le fichier wp-config.php, celui-là même qui contient les identifiants de connexion à la base de données et autres joyeusetés. Et d’y rajouter cette ligne, avant la première directive par exemple :

define('FS_METHOD', 'direct');

Enregistrez, et c’est plié.

Réglage des permissions

Côté permissions, ça peut également se régler en 2 coups de terminal. Partons du principe que le groupe propriétaire de votre serveur HTTP est www-data, à la base de votre installation WordPress, il suffit de faire ceci :

chgrp -R www-data wp-content/upgrade wp-content/themes wp-content/plugins wp-content/uploads
chmod g+wx wp-content/upgrade wp-content/themes wp-content/plugins wp-content/uploads

Cette manipulation attribue www-data comme propriétaire des répertoires que vous souhaitez rendre accessibles en écriture et ce, de manière récursive. Dans un second temps, elle attribute les droits d’écriture et d’exécution au groupe propriétaire (peu importe le nom du groupe).
Si vous êtes perdu(e) avec la commande chmod, un peu de lecture pour apprendre à le manipuler (ça sauve la vie).

Conclusion

A ce stade des choses, tout est fonctionnel : tentez d’installer une nouvelle extension, ça passera comme une lettre à la poste.
Si vous rencontrez des difficultés, c’est très certainement parce que les permissions des fichiers qui tentent d’être modifiées ne sont pas suffisantes pour le groupe propriétaire du serveur HTTP. Ajustez la procédure des permissions par rapport à votre besoin.

C’est pas sorcier, il suffisait de le savoir  :-)

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 ?

Qu’on se le dise : le compteur de lecteurs Feedburner par défaut est sympa mais s’intègre mal dans n’importe quel design de site Web. Lors de la refonte du thème graphique de ce blog, j’ai eu envie de remettre mon compteur d’abonnés Feedburner mais sous forme de texte. Même si le chiffre indiqué peut se révéler inexact, j’estime que c’est un indicateur intéressant sur la consultation d’un flux. Je suis également convaincu qu’à partir d’un certain nombre de lecteurs, ça facilite la conversion : si le nombre est élevé, c’est que le site est bien  … donc je m’abonne.

Bref, j’ai voulu implémenter ça de manière propre et peu gourmande avec WP-Cron, l’API Feedburner Awareness et la classe PHP 5 SimpleXML. Une poignée de lignes de code suffisent, pourquoi s’en priver ?

Le besoin

La plupart des exemples que l’on trouve sur le Web attaquent directement l’API Feedburner Awareness. Autrement dit, votre page ne s’affichera pas tant que l’API n’aura pas été appelée et son résultat interprété. Étant donné que cette valeur change 1 fois par jour, il vaut mieux aborder la chose différemment. C’est pourquoi je voulais :

• récupérer 1 à 2 fois par jour la valeur courante du nombre de lecteurs ;
• accéder à cette valeur simplement depuis mes templates (avec un appel à get_option() par exemple).

On y gagne sur tous les fronts : on ne ralentit pas l’affichage côté utilisateur, l’information est récupérée en arrière-plan, nos templates graphiques restent simples.

Activation du service Feedburner Awareness

La première chose à faire est d’activer l’API Awareness pour votre flux. Cette API permet de récupérer des statistiques sur un flux Feedburner au format XML. On y retrouve entre autre le nombre de lecteurs. On peut obtenir ces informations pour la date courante, la veille ou une plage de jours par exemple.

C’est vraiment simple à utiliser, la documentation Feedburner Awareness est complète dans son genre.

Activation du service Feedburner Awareness

Remarque : cette API s’active par flux Feedburner de manière individuelle et est désactivée par défaut.

Extraction du nombre de lecteurs

Dans un premier temps, on va récupérer le nombre de lecteurs pour son flux. On verra dans un second temps comment l’automatiser.

Le principe est simple : on appelle une URI avec son identifiant de flux Feedburner (exemple dans mon cas : http://feeds.feedburner.com/LaCaseDeLoncTom). On lui spécifie 2 dates : la veille et l’avant-veille. Pourquoi ? Car les données de la veille ne sont pas toujours existantes : les compteurs sont actualisés à 11h heure française. L’idée est de pouvoir se mettre un nombre de lecteurs sous la dent.

define('FEEDBURNER_URI', 'LaCaseDeLoncTom');
function oncletom_update_feed_readers()
{
  $uri = sprintf('https://feedburner.google.com/api/awareness/1.0/GetFeedData?uri=%s&dates=%s,%s',
    FEEDBURNER_URI,
    date('Y-m-d', strtotime('-2 day')),
    date('Y-m-d', strtotime('-1 day'))
  );
  $http = new WP_Http();
  $readers = (int)get_option('feed_readers');
  $response = $http->get($uri);
  $xml = new SimpleXMLElement(WP_Http::chunkTransferDecode($response['body']));
  $feed = (array)$xml->feed;
  foreach (array_reverse($feed['entry']) as $entry)
  {
    if ((int)$entry['circulation'])
    {
      $readers = (int)$entry['circulation'];
      update_option('feed_readers', $readers);
      break;
    }
  }
  return $readers;
}

Quelques remarques :

• j’ai utilisé la classe  WP_http qui fournit une abstraction d’appel à des ressources distantes. C’est le plus propre pour fonctionner sur la majorité des installations ;
• j’inverse le tableau des résultats car ils sont triés par ordre chronologique croissant par défaut  ; nous voulons l’information la plus fraîche d’abord ;
• on aurait pu utiliser un paramètre de fonction pour fournir l’URI du flux mais dans l’étape d’après, il se trouve qu’on ne pourra lui en passer … dommage ;
• on aurait également pu remplacer la constante par un appel à un get_option() et pourquoi pas, récupérer l’ID depuis un réglage du plugin Feedburner FeedSmith.

Programmation d’une tâche planifiée avec WP-Cron

On en arrive à la partie sympa : programmer cette récupération du nombre d’abonnés pour qu’on n’ait pas de travail manuel à faire. L’idéal est de placer ceci dans un plugin. Personnellement je l’ai inséré dans le hook switch_theme() de mon thème pour économiser un fichier/plugin.

//dans un fichier wp-content/plugins/oncletom-awareness-cron.php
/*
Plugin Name: Simple Feedburner Awareness
Description: Asynchroneous feed readers collector scheduled twice a day.
Author: Oncle Tom
Version: 1.0
Author URI: http://case.oncle-tom.net/
Plugin URI:
  This plugin is released under version 3 of the GPL:
http://www.opensource.org/licenses/gpl-3.0.html
*/
register_activation_hook(__FILE__, 'oncletom_awareness_cron_activate');
register_deactivation_hook(__FILE__, 'oncletom_awareness_cron_deactivate');
add_action('oncletom_cron_twicedaily_hook', 'oncletom_update_feed_readers');
function oncletom_awareness_cron_activate()
{
  add_option('feed_readers', 0, '', 'yes');
  wp_schedule_event(time(), 'twicedaily', 'oncletom_cron_twicedaily_hook');
}
function oncletom_awareness_cron_deactivate()
{
  delete_option('feed_readers');
  wp_clear_scheduled_hook('oncletom_cron_twicedaily_hook');
}

Vous vous souvenez encore de notre fonction oncletom_update_feed_readers() ? Et bien on pourrait la rajouter dans ce plugin pour tout avoir au même endroit. L’organisation de votre code vous appartient

Quoiqu’il en soit, une fois le plugin activé, tout est prêt : il ne reste qu’à intégrer le compteur d’abonnés dans le thème. C’est notre prochaine étape.
Juste une remarque : la fonction wp_schedule_event() prend comme dernier argument un nom de hook et non un nom de fonction.

Intégration dans le thème

C’est la partie la plus simple et pour cause, un simple appel à get_option('feed_readers') nous retourne le nombre d’abonnés. On ne pouvait pas faire plus rapide

<p>J'ai <?php echo get_option('feed_readers') ?> abonnés</p>

Conclusion

WordPress fournit tous les mécanismes pour accéder aisément à des données de manière asynchrone. Il ne nous a pas coûté grand chose de collecter le flux XML et de l’enregistrer. En le faisant ainsi en arrière plan, on évite toute gêne pour l’utilisateur et tout traitement superflu exécuté en affichage.

Assez étonnamment, je n’ai croisé aucune extension dans le catalogue WordPress. J’espère que ça vous dépannera et que votre thème graphique appréciera !
Mise à jour : aucun plugin n’était tagué awareness ; FeedBurnerCount, Feed Subscriber Stats et Feedburner Text Count produisent très probablement le même résultat que le contenu de cet article.

Je me décide à passer un coup de peinture sur ce blog quasiment 2 ans après le CSS Summer Refresh organisé par Alsacréations. À vrai dire, j’avais ce projet dans les cartons depuis septembre 2008 mais le plus difficile a été de trouver le talent graphique. C’était également l’occasion de dire au revoir aux navigateurs Web de seconde zone, à savoir Internet Explorer 7 et moins.

Le besoin

Mon besoin était le suivant :

• Thème graphique
  • durable et peu lassant
  • usage de transparence
  • toujours sur des tons marrons
  • inspire la modernité tout comme le côté rustique et soucieux de la nature
  • structure en grille pour intégrer avec Blueprint
• Fonctionnalités
  • intégration d’un lifestream (intégré entre temps)
  • intégration de Feedburner via son API Awareness
  • intégration d’un bandeau Flickr qui s’étend sur toute la largeur de l’écran, peu importe la résolution employée
  • utilisation du blog comme vitrine : suppression de ma dernière page HTML manuelle (autrefois accessible sur oncle-tom.net)
• Compatibilité
  • navigateurs modernes … c’est à dire rien en dessous d’Internet Explorer 8
  • intégration avec HTML 5
  • pas d’utilisation de GIF mais de PNG 6 et PNG 24
• Autre
  • soucis de performance (peu d’éléments graphiques, utilisation des sprites)

Finalement c’est Lesly qui s’est chargé de la création graphique. Vous pouvez d’ailleurs consulter la maquette graphique originale sur son portfolio. Quant à moi, j’ai réalisé toute l’intégration CSS/HTML dans WordPress.

L’intégration

Tout d’abord, qu’est ce qui a changé par rapport à la maquette ?

• les polices de caractère : hormis le titre, seules des polices standards ont été employées. J’attendrai le support des polices personnalisées en CSS 3 à moins de partir sur une solution à base de SVG (encore que j’ai des doutes sur l’accessibilité d’une telle méthode) ;
• moins d’éléments graphiques : les punaises, les effets papiers ont été supprimés. Rien que le papier et le scotch de la partie « À propos » pesaient plus de 60Ko ;
• abandon temporaire du featured content : les solutions actuelles étaient trop lourdes et j’étais trop impatient pour passer quelques heures de plus … donc c’est temporaire
• l’ajout des pages en lieu et place du fil d’ariane : j’en avais besoin pour présenter différents contenus statiques ;
• le pied de page : peu de widgets WordPress offrent un degré de personnalisation suffisant pour arriver à ce résultat. C’est donc temporisé là aussi en attendant de trouver chaussure à mon pied

Aperçu pleine page

Pour le reste je me suis fait plaisir avec notamment l’utilisation de coins arrondis (border-radius) basés sur les implémentations de Gecko et Webkit. Désolé pour les utilisateurs d’autres navigateurs car j’en ai usé et abusé afin d’éviter l’utilisation d’images.

J’ai également joué avec l’API de WordPress pour générer les vignettes des articles. Je sais bien qu’on peut définir des tailles d’images mais ça ne vaut que pour les médias nouvellement mis en ligne. J’en ai profité pour n’afficher dans le listing que l’extrait du billet. Pas l’intro, seulement l’extrait (excerpt). J’ai lu récemment un article qui parlait de la chose et ça m’a paru plus approprié. Je peux désormais écrire le texte qui me convient pour attirer la lecture vers un article sans pour autant que ça ait de répercution sur son contenu une fois affiché en pleine page.

Je suis en revanche toujours dubitatif sur l’API de WP Cron : ma tâche a beau être enregistrée et planifiée, j’ai l’impression qu’elle ne s’exécute jamais … contrairement aux recherches de mises à jour de plugins & cie. Quelqu’un a déjà joué avec et rencontré pareil problème ?
Mise à jour : j’ai résolu le problème et détaillé la marche à suivre dans l’article affichage personnalisé de ses lecteurs Feedburner. Je planifiais une fonction et non un hook. Cela fonctionnait mais ne produisait fatalement pas de résultat

Au final je n’ai même pas eu à placer la moindre ligne de JavaScript : tout est fait à partir de sélecteurs CSS. Mon seul regret : l’absence de sélecteur adjacent … « précédent ». Pour le menu du haut, je voulais pouvoir styler les éléments de menus ayant comme élément suivant une liste d’élément (<ul>).

Au final

J’ai mis à peu près 2 jours pour tout intégrer et optimiser. Je n’ai pas encore tenté l’optimisation à coup de PNG 8 grâce aux quelques Ko gagnés avec pngcrush. Il faudrait également que je réunisse quelques images dans un seul et même sprite pour gagner encore quelques dizièmes de seconde en temps de chargement.

Rapport YSlow

J’en ai profité pour tester l’utilisation de mod_expires et mod_gzip chez OVH en mutualisé (avant de tout migrer sur serveur dédié) : ça marche plutôt très bien. Si ça vous intéresse, je peux en faire un billet dédié. D’ici là, n’hésitez pas à bouquiner High Performances Web Sites qui reste une référence en la matière. J’attends d’ailleurs sa suite avec impatience : Even Faster Web Sites: Essential Knowledge for Frontend Engineers.

Quoiqu’il en soit, le fait d’avoir eu la pleine utilisation des sélecteurs CSS a été géniale : la vie est grandement facilitée. inline-block évite de nombreuses bidouilles à base de flottants. J’ai hâte qu’une version de Blueprint sorte en se basant uniquement sur les sélecteurs avancés et non des flottants pour disposer de mises en forme plus complexes tout en étant facile d’accès.

Si vous rencontrez des problèmes, surtout n’hésitez pas à les signaler, par le biais des commentaires ou par email

En attendant, je retourne sur mon projet éprouvant du moment !

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 …

Il existe cependant une méthode alternative reposant sur Subversion (SVN). C’est la méthode idéale pour tout développeur WordPress ou gestionnaire de blogs. C’est celle que j’emploie depuis la version 2.6 grâce notamment à la constante WP_CONTENT.

Explications et application concrète.

Avant toute chose, sachez que ce tutorial est optimisé pour les personnes qui versionnent entièrement leur projet. Il n’est pas question ici d’avoir une arborescence libre et de procéder à des checkout un peu partout. C’est possible mais pas du plus grand intérêt.

L’avantage évident ici est de pouvoir déployer son blog n’importe où en un rien de temps.

Structure des fichiers

Installer WordPress en tant que dépendance SVN revient à mélanger 2 techniques :

• Installer WordPress dans son propre répertoire
  
• Installer WordPress proprement depuis SVN

Je suis pénible donc je n’ai pas spécialement envie de modifier un fichier core ou autre chose que wp-config.php. Tout le contraire de ce qu’indique la première méthode.

La seconde explication m’a toutefois posé légèrement problème puisqu’un peu brutale et posant soucis chez OVH.

Celles et ceux qui voient la capture d’écran ci-dessus peuvent constater que tout WordPress a été déplacé dans un sous-répertoire wordpress au même niveau que wp-content.
On ne garde à la racine que le fichier .htaccess et wp-config.php.

Sur le répertoire racine, j’ai appliqué ces propriétés pour WordPress 2.7 :

• svn:ignore :
  

  wp-config.php

• svn:externals :
  

  wordpress http://svn.automattic.com/wordpress/branches/2.7

Je ne versionne volontairement pas le fichier wp-config.php car c’est le seul fichier susceptible de changer d’une instance à une autre. Je le récupère depuis wordpress/wp-config-sample.php et je le personnalise selon mes besoins.
Et puis versionner des mots de passe … qui y tient ?

Configuration

Après cette restructuration, on aura toutefois besoin de configurer 2-3 bricoles. Vraiment rien de méchant promis.

Le .htaccess

Voici ma configuration. Elle peut être aisément déportée dans votre déclaration de Virtual Host pour des raisons de performance. Sur un serveur mutualisé vous n’avez en général pas accès à ce dernier type de configuration.

<IfModule mod_rewrite.c>
Options -Multiviews -Indexes +FollowSymlinks
RewriteEngine On
RewriteBase /
# Moving to dependency
RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . wordpress/index.php [L]
</IfModule>
# BEGIN WordPress
# END WordPress

Ce fichier est très inspiré de la configuration SVN proposée sur le Codex WordPress. Seulement voilà, cette renvoie tout sur index.php … et omet ainsi tous les accès aux fichiers situés à la racine, avec entre autre :

• wp-cron.php
• wp-link-opml.php
• wp-trackback.php
• xmlrpc.php

Je vous fais grâce des contrôleurs de flux (Atom, RSS & cie) et des appels en directs à index.php effectués par certains plugins.

Donc non on ne peut pas vraiment se passer de ces fichiers. D’où ces 2 règles :

• RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
  

  On capte tous les fichiers PHP (les contrôleurs) originellement situés à la racine de WordPress.

• RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]

  Et là c’est pour le confort de conserver les adresses initiales … mais aussi pour éviter de modifier un bout de paramétrage dans l’admin. Le jour où vous décidez de rebasculer à l’ancien système, ça se fera sans douleur

Enfin, pourquoi avoir poussé les commentaires WordPress vers le bas ? Tout simplement pour éviter que nos règles personnalisées soient écrasées par WordPress lors d’une mise à jour des permaliens. Nos règles primeront toujours ainsi.

Le fichier wp-config.php

Dans le fichier wp-config.php, nous n’allons rien modifier. Nous allons juste ajouter forcer 2 paramètres. Ils indiqueront à WordPress où se trouve le véritable répertoire wp-content (renommable mais je ne jouerai pas avec).

Le blog

Bon j’ai menti un peu toute à l’heure en indiquant qu’on ne toucherait qu’à wp-config.php. Cependant la modification est on ne peut plus mineure et ne concerne que l’upload de medias.

En effet si on ne touche pas à l’emplacement des fichiers envoyés, WordPress considère qu’ils sont uploadés dans wordpress/wp-content/uploads. C’est fort gênant mais heureusement, en préfixant le chemin par ../ ou en tapant un chemin absolu tout rentrera dans l’ordre.

À noter qu’il s’agit du seul paramétrage hors d’un fichier. Si j’avais pu m’en passer je l’aurais fait.

Dépendance SVN pour la traduction

C’est en tombant sur un autre article traitant de svn:externals pour WordPress que j’ai été interpelé sur la prise en charge des langues via SVN également.
Le système n’est pas parfait puisqu’on ne peut gérer qu’une seule langue par ce biais là. Ça ne conviendra donc pas aux blogs multilingues.

La technique consiste à transformer wp-content/languages en svn:externals.
Ça donnerait ceci pour la version française de WordPress 2.7, au niveau du svn:externals du répertoire wp-content :

languages http://svn.automattic.com/wordpress-i18n/fr_FR/branches/2.7/messages/

Simple et efficace mais ça reste encore de la bricole.

Cas particulier : plugins et i18n

Je vous expose le problème mais malheureusement vous ne pourrez pas y faire grand chose. Par contre ami développeurs, pour rendre votre code de plugin 100% portable, merci de prendre note

Le chargement des traductions s’effectue à l’aide de la fonction load_plugin_textdomain(). Elle prenait seulement 2 paramètres jusqu’à l’arrivée de WordPress 2.6. Ça n’a pas été crié sur les toits mais elle prend désormais 3 … et c’est du 3ème argument qu’il faut utiliser désormais :

1. $domain : l’espace de nom des traduction (inchangé)
2. $abs_rel_path : chemin relatif par rapport à l’emplacement de WordPress (déprécié, on y mettait PLUGINDIR.'/'.dirname(plugin_basename(__FILE__)) en général)
3. $plugin_rel_path :  chemin relatif par rapport à l’emplacement des plugins (c’est qui nous intéresse ; dirname(plugin_basename(__FILE__)) nous suffira désormais)

Vous trouverez un exemple sur le Codex, du côté de l’internationalisation des plugins.
Un exemple de code pérenne :

load_plugin_textdomain('votreplugin', dirname(plugin_basename(__FILE__)), dirname(plugin_basename(__FILE__)));

Et si jamais vous utilisez votre plugin en lien symbolique ça ne fonctionnera pas … mais on s’éloigne du sujet

Et pour WordPress Mu ?

Je ne m’attarderai pas dessus mais les manipulations sont sensiblement les mêmes. Je n’ai pas encore eu l’occasion d’essayer mais j’ose imaginer qu’il n’y a pas tant de différences que ça

Conclusion

Le jour où vous souhaitez migrer vers une autre version majeure de WordPress, c’est simple : il suffit de changer les externals vers le tag adéquat.

Pourquoi ne pas utiliser le trunk directement me demanderez-vous ? Le trunk de WordPress est plutôt instable puisque c’est là que se construit la prochaine version de manière systématique. L’utilisation des branches permet de bénéficier des correctifs sans avoir à modifier le moindre external.
Si vous avez un grand besoin de stabilité, alors utilisez les tags qui sont en principe figés.

On remarquera aussi que malgré son âge, WordPress commence à peine à proposer des solutions d’industrialisation.
Les liens symboliques sont en effet très mal gérés. Tentez d’utiliser un seul répertoire source pour plusieurs blogs avec des liens symboliques et tout s’effondre.

La preuve en est aussi avec le manque de ressources disponibles sur le Web et traitant ce sujet. Ça m’étonnerait d’être le premier à vouloir déployer du WordPress via SVN.
Les choses s’améliorent mais pour le côté code is poetry, on en est encore loin.

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.

J’ai récemment lu une astuce pour afficher sa blogroll sur une page à part et ça m’a donné envie de réagir à la solution proposée.

Gérer sa blogroll sur une page dédiée est une bonne idée car ça évite de surcharger inutilement ses barres latérales de liens, surtout s’ils sont nombreux. Cette séparation permet également d’avoir davantage de liberté pour les présenter et les styler. Ce n’est pas un mal pour apporter un souffle d’originalité.

En revanche la solution du copié/collé n’est pas à mes yeux une véritable solution car :

• soit on gère sa blogroll dans le module de blogroll et on doit systématiquement copier/coller le résultat dans une page
• soit on gère directement la blogroll dans la page dédiée ; le module de gestion perdant alors totalement son intérêt

Je suis feignant donc je n’aime pas faire le travail 2 fois alors je propose une solution qui fonctionnera chez vous. C’est d’ailleurs celle que j’emploie depuis la refonte de ce blog … c’est à dire bientôt 1 an.

Les modèles de page WordPress

Il existe peu de différences entre une page et un article dans WordPress :

• les articles sont datés, n’ont pas de hiérarchie et peuvent être dans 1 ou plusieurs catégories
• les pages ne le sont pas datées, ont une hiérarchie et ne peuvent pas être dans une catégorie

Les pages possèdent également un autre atout : on peut leur appliquer un modèle de présentation. Cette pratique est adaptée à toute présentation où vous souhaiteriez afficher davantage que le seul texte saisi depuis l’interface d’administration.

La notion des templates de pages est bien expliquée dans le Codex WordPress. Petit rappel synthétique néanmoins.

Un template de page correspond à un fichier créé dans le répertoire du thème de votre choix (celui que vous utilisez de préférence). Autrement dit ça correspond à un fichier comme ceci : wp-content/themes/<votre thème>/<votre template>.php.

Ce fichier de template doit obligatoirement comporter une entête de description. Sans elle, pas de sélection possible depuis la page de rédaction. Cette entête doit correspondre à ceci :

<?php
/*
Template Name: <Nom du template>
*/

La dernière étape avant son utilisation consiste à tapoter un peu de code PHP pour aboutir à votre souhait. N’hésitez pas à parcourir la documentation de WordPress pour produire un code pérenne et utiliser au maximum les fonctionnalités proposées par WordPress.

Un modèle de page WordPress pour Blogroll

Notre besoin initial tombe à point nommé puisque nous avons justement besoin d’un template de page pour gérer sa blogroll depuis son module d’administration sans avoir à mettre à jour manuellement quelconque autre page que ce soit

La première étape consiste à créer un nouveau template dans le thème employé par votre blog. Si vous utilisez le thème de base, le thème default, nous allons créer le fichier suivant :
wp-content/themes/default/template-blogroll.php.

Pour remplir ce fichier, nous allons devoir accéder aux éléments contenus dans la blogroll. Ça tombe bien puisqu’il existe pour ça la fonction wp_list_bookmarks().
À ce stade, notre template devrait ressembler à ça :

<?php
/*
Template Name: Liens
*/
get_header() ?>
<h2><?php the_title() ?></h2>
<?php the_content() ?>
<ol id="page-blogroll">
  <?php wp_list_bookmarks() ?>
</ol>
<?php get_sidebar() ?>
<?php get_footer() ?>

Une fois enregistré, le modèle apparaît dans le sélecteur de modèle (uniquement sur les contenus de type Page) :

Ça y’est, vous avez votre page dédiée aux liens sans travail de recopie supplémentaire.

Un modèle imparfait

Attention toutefois puisque créer un modèle signifie que WordPress ne va utiliser QUE ce modèle pour la présentation. Autrement dit il va falloir toute reproduire jusqu’au titre de la page si vous le désirez.

L’exemple ci-dessus est minimaliste à ce sujet pour la simple et bonne raison que le balisage dépendra uniquement du thème employé. Ça explique pourquoi les modèles sont à définir au cas par cas.

Pour bien reproduire le thème, plusieurs possibilités :

• vous vous débrouillez vous-même pour comprendre comment est construit l’affichage du thème
• vous connaissez quelqu’un qui se débrouille avec WordPress et vous lui demandez de le faire (pas la peine de me demander)

Conclusion

Les modèles de page (ou templates) est une fonctionnalité assez méconnue mais pourtant ô combien utile pour les utilisations suivantes :

• utilisation tournée CMS
• affichage différent pour certaines pages uniquement, sans vouloir créer un thème spécifique
• création de pages plus riches allant au-delà de la simple présentation de contenu rédigé

Si vous vous débrouillez bien, vous aurez un résultat comme sur ma page de liens, les liens de l’Oncle Tom.
Et n’oubliez pas, dès que vous pensez « spécifique », pensez modèle de page

Si seulement TiBo avait imaginé que son blog@bordeaux avait semé les germes de BlogCamp France … et pourtant c’est le cas.

Je vais évangéliser en faveur de cette association toute fraîche de promotion des blogs auprès des blogueurs … mais aussi ceux qui ne le sont pas (encore). Je vais également tâcher d’expliquer les motivations de mon implication et pourquoi ça vaut bien quelques cernes marquées. Il y a des tabous à lever … et des bonnes pratiques à apporter

BlogCamp, qu’est-ce que c’est ?

BlogCamp est un rendez-vous mensuel entre blogueurs dans l’esprit des BarCamp bien connus des technophiles. La seule différence est que dans un BlogCamp on parle blog life et pas forcément que de nouvelles technologies et d’Internet. Tous les blogueurs ne sont en effet pas des professionnels du Web (si, si).

Le décor est planté, reste à le comprendre.

Quand on constate que les 2/3 des blogs se paraphrasent entre eux, que les blogs sont associées à des récits puérils (y compris jusqu’au niveau des entreprises) et qu’à Bordeaux il manquait un tissu social numérique, l’idée de BlogCamp est née. L’idée d’une réunion conviviale où les outils et les connaissances seraient mis à disposition du public, blogueurs ou pas. L’essentiel étant d’être curieux et intéressé par ce phénomène auréolé de stéréotypes.

BlogCamp, le rendez-vous des blogueurs … et de ceux qui ne le sont pas

Les stéréotypes parlons-en. Ils gravitent autour de 2 expressions phares :

• Je suis blogueur
• Blogosphère

Le blogueur est une personne comme vous et moi : normale. Le blogueur n’est pas un être surnaturel ou un superhéros venu de Krypton pour sauver l’internaute lambda d’un ennui mortel. Être blogueur c’est avant tout une idée de partage, aussi maladroite soit son expression.

Ça rejoint d’ailleurs très bien l’idée que l’on forge de la blogosphère : fermée de l’extérieur, en circuit fermé de l’intérieur. En clair ça sent le moisi. Comment inciter les gens bien intentionnés et peu connaisseurs de se lancer dans un blog en pensant qu’il faut être fort et avoir de bonnes relations ?

C’est pour ça que BlogCamp s’adresse à celles et ceux qui ont un blog ou qui n’en ont pas mais qui souhaiteraient en avoir un.

Le contenu et les conversations au cœur des rendez-vous

BlogCamp cherche à créer du contenu en diffusant des bonnes pratiques, en dispensant des ateliers techniques et en réservant du temps aux échanges entre participants. Un soin tout particulier est apporté pour intégrer les nouvelles têtes afin de les mettre à l’aise.
Chaque mois ce sont des conférences, avec des intervenants extérieurs ou pas, pour éduquer les esprits :

• les blogs ne sont pas des sapins de Noël : la dizaine de widgets des barres latérales n’ont pas à exister
• l’identité d’un blog ça se construit : nous donnons les pistes à explorer
• le référencement d’un blog peut être facilité avec un minimum de bonnes pratiques

Bien d’autres concepts sont à aborder et leur orientation dépendra des sensations perçues lors des différentes interventions. L’idée est que tout participant y trouve son compte, apprenne des choses et mûrisse dans son approche du blog. Le kikoolol de SkyBlog a suffisamment hanté les consciences.

BlogCamp, le concept déclinable clés en main

La face cachée de BlogCamp c’est la réflexion dans sa conception : tout a été pensé pour que le concept soit facilement déclinable et facilement reproductible dans une autre ville de France.
BlogCamp c’est aussi une solution packagée clés en main avec nom de domaine, hébergement, emails, ressources (wiki, diaporamas, cartes de visite etc.) et toute la synergie médiatique. Quelques détails sont encore à régler mais en l’espace de quelques minutes, un nouveau BlogCamp peut se créer en France en un minimum d’efforts.

Pour cela, BlogCamp repose essentiellement sur du logiciel libre et des standards ouverts. Internet est né grâce à cette ouverture, les blogs doivent poursuivre sur cette voie.

La troisième session de BlogCamp Bordeaux se tiendra le vendredi 29 février 2008 à 19h00. J’espère y rencontrer un maximum de personnes désireuses d’en savoir plus sur les blogs et leur utilisation.
Profitez-en, c’est gratuit et c’est pas votre pouvoir d’achat qui rechignera

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;

WordPress 2.3 est sorti, accompagné de sa traduction française. C’est un fait et je conseille aux aventuriers de toujours mais alors toujours faire une sauvegarde de leurs fichiers et de leur base de données avant de se lancer dedans. Compte-rendu d’une migration qui s’est passée sans trop de problèmes et point rapide sur quelques correctifs appliqués pour rendre le tout fonctionnel.

Préparatifs de mise à jour

La meilleure solution pour migrer en cas de doute c’est d’avoir de vrais amis et qui ont déjà réalisé ce genre d’intervention. Ca évite de faire des choses sans les comprendre et de flinguer son blog en se rendant compte après coup que … ben pas de sauvegarde. La sauvegarde c’est obligatoire (il peut toujours y avoir un pépin) et concerne aussi bien la base de données que les fichiers.
Pourquoi ? Parce que si la mise à jour ne se fait pas, on peut revenir en arrière et reprendre sa vie comme si de rien n’était.

Le plus souple pour sauvegarder/restaurer est de passer par des instructions en ligne de commande. phpMyAdmin c’est bien mais bien souvent limité à des restaurations de 2Mo (sauf les dernières versions qui se débrouillent pour reprendre au dernier point d’arrêt) :

mysqldump -h votre hôte MySQL -u utilisateur -p votre base de données > sauvegarde.sql

La restauration se fait en un clin d’œil par cette autre commande :

mysql -h votre hôte MySQL -u utilisateur -p votre base de données < sauvegarde.sql

La sauvegarde de vos fichiers peut également se faire rapidement en vous plaçant à la racine du répertoire WordPress (vous devez voir le répertoire wp-admin sous vos yeux) :

tar -czf sauvegarde.tar.gz *

Remarque : mieux vaut ne supprimer ces sauvegardes que lorsqu’on est sûr que tout fonctionne après la mise à jour. De même, il faut faire attention à ce que ces sauvegardes ne soient pas accessibles au public sinon un simple téléchargement dévoile le mot de passe de la base de données. Prudence donc.

Changements pour jQuery

Depuis la version 2.2, WordPress effectue une transition de la librairie JavaScript Prototype vers jQuery. Si cette dernière est toujours disponible, il y a eu du changement puisque la directive jQuery.noConflict() est activée.
La documentation à propos de noConflict() est explicite sur sa signification. Au lieu d’utiliser jQuery avec la fonction dollar ($()), il faut passer par la fonction jQuery().

La solution à apporter à vos scripts qui se basaient dessus est simple : rechercher/remplacer (CTRL+H en général sur les éditeurs de texte) $( par jQuery(.

Problème avec Simple Tagging

Simple Tagging était une solution intuitive et sympa de gestion de tags avant que ce concept ne soit intégré nativement dans la version 2.3 de WordPress. J’appréciais sa saisie prédictive et j’envisageais de l’utiliser pour suggérer des articles connexes. Malheureusement ce plugin n’est plus compatible (y compris dans sa version 1.7) et il faudra attendre sa refonte prévue et en cours de réalisation.

Problème avec SEO Title Tag 2.0RC2

SEO Title Tag permet de choisir des titres complémentaires à vos pages. Le soucis c’est qu’il entre en conflit avec WordPress 2.3 en cas d’utilisation native des tags (et uniquement dans ce cas là). Lors de l’affichage des articles par tag, une erreur souille votre écran.
Concrètement SEO Title Tag s’embrouille en pensant que le plugin Ultimate Tag Warrior est installé et tente de faire appel à une de ses fonctions. D’où l’erreur. J’ai proposé ma solution sur le site officiel mais je la partage à nouveau ici.

Il faut modifier le fichier seo-title-tag.php, se rendre à la ligne 285 et faire en sorte que

} elseif(function_exists('is_tag') && is_tag()) {

devienne

} elseif(function_exists('is_tag') && is_tag() && isset($utw)) {

Testé et approuvé.

Point rapide sur les tags

WordPress 2.3 apporte sa propre gestion des tags. La question récurrente est qu’utiliser, tags ou catégories ?. Les deux mon capitaine. Utilisez toujours les catégories pour classer vos rédactions. Les tags sont là pour affiner ce classement en ajoutant des correspondance. Dans un registre plus fromager, les catégories correspondraient au type de lait de fromage (vache, brebis, chèvre etc.) et les tags seraient des compléments (bleu, pâte molle, pâte pressée etc.).

Du coup je déconseille d’utiliser le convertisseur de catégories en tags. Ca ruinerait toute classification et vos lecteurs s’y perdraient.

La logique de WordPress était d’introduire son propre moteur de gestion de tags et que les plugins complètent leur gestion en vous facilitant la vie pour que chacun les gère comme il le sente. Et c’est plutôt malin et bien pensé.

WordPress c’est bien. Bien utiliser WordPress c’est mieux !
Si je trouve l’installation de base de cette plateforme de rédaction plus qu’aboutie, certains plugins sont indispensables pour améliorer votre blog, son suivi et sa présence sur Internet. Je me permets donc de partager ma sélection des plugins que je trouve utiles pour une utilisation quotidienne :

• Akismet
• Dofollow
• Feedburner FeedSmith
• FlickrRSS
• Full Text Feed
• Google Analyticator
• Google XML Sitemaps
• SEO Title Tag
• Simple Tagging
• Subscribe to Comments
• WP-PostViews
• WordPress.com Stats

Ca en fait n’est-ce pas ? Tous ne vous seront pas indispensables (notamment si vous ne jouez pas avec Flickr ni Google Analytics) mais peut-être que la lecture de ce billet vous en apprendra davantage et créer des envies

Akismet

Une de mes plus fortes motivations pour migrer de Dotclear à WordPress était la présence d’Akismet, antispam évolué et mutualisé. Pourquoi mutualisé ? Parce que le travail est déporté sur les serveurs d’Akismet sur lesquels sont « branchés » des milliers de blogs. Autant dire que si un spam est déclaré au service, tous les sites utilisant Akismet en sont protégés.
C’est redoutable et ça m’a permis d’éviter de perdre du temps à modérer les messages en carton qui innondaient le blog. A l’heure actuelle, ce ne sont pas moins de 20 000 spams qui m’auront été épargnés. En l’espace de 12 mois, c’est appréciable.

Dofollow

Les référenceurs et les personnes sensibilisées au référencement Web se doivent de savoir que WordPress ajoute la valeurnofollow à l’attribut rel des liens hypertextes de vos commentaires. Pour rappel, il s’agit d’un microformat spécifiant aux moteurs de recherche de ne pas tenir compte du-dit lien. Ceci a pour effet de ne pas prendre en compte l’éventuelle relation entre votre site et un site tiers pour des raisons évidentes de spam.

Les spams étant très bien écartés, autant laisser ce flux de liens sortants faire son effet.
Seul bémol : ce plugin n’a pas d’interaction avec le widget officiel qui continuera à arborer un rel="nofollow". Un petit plus sympathique qui incitera peut-être davantage au commentaire sur votre blog

Feedburner FeedSmith

Feedburner est un service permettant de mesurer l’utilisation de vos fils RSS et Atom. Combien de personnes suivent mon fil RSS ?, Combien de nouveaux abonnés aujourd’hui ? ou encore Quels sont les articles les plus cliqués ou lus depuis les agrégateurs ? seront le genre de questions pour lesquelles vous obtiendez enfin des réponses.

Sa configuration est aisée comme tout et il serait dommage de se passer d’un outil statistique doublé d’outils de republication d’une telle envergure.
Pour information, j’ai également publié un billet expliquant comment migrer un flux RSS vers Feedburner pour celles et ceux ne pouvant installer ce plugin.

FlickrRSS

Vous utilisez le service de gestion et de partage de photos Flickr ? Une bonne idée est d’intégrer vos photos directement sur votre blog de manière « propre », c’est à dire sans passer par un médaillon en Flash ou JavaScript ; ceci bien sûr dans l’intérêt de pénaliser le moins de monde possible.

Son gros atout est la personnalisation du plugin et son widget : peu d’efforts pour un bon résultat.

Full Text Feed

Depuis une certaine version de WordPress (la 2.1 me semble-t-il), quand bien même on paramètre le blog pour afficher des flux intégraux (contenant l’intégralité des billets et non un court extrait), à partir du moment où un billet est précédé d’un chapô, seul celui-ci est publié dans le flux RSS.
Comme vous pouvez vous en douter, ce plugin remet les pendules à l’heure et c’est bien dommage qu’une telle option ne soit pas proposée par défaut dans WordPress.

Google Analyticator

Google Analytics est un formidable outil statistiques de sites Internet générant des rapports clairs au sein d’une interface qui l’est tout autant. Sans pub et sans logo affiché sur les sites audités, c’est pour moi le meilleur outil gratuit tant en terme de mesures que d’outils fournis.

Si jamais vous décidez de suivre votre audience par ce service (Feedburner propose un service similaire mais moins complet, on peut imaginer que tôt ou tard une fusion sera opérée à ce niveau), Google Analyticator permet de placer le traceur sans avoir à toucher le code des différents thèmes de votre blog. Il permet même de vous exclure des statistiques pour refléter au mieux le parcours de vos visiteurs.

Google Sitemaps Generator

Les sitemaps ont été initiées par Google afin de mieux signaler de nouveaux contenus ainsi que l’architecture de votre site. Depuis le format a été adopté par d’autres géants de la recherche sur Internet (Yahoo!, Ask etc.). En toute honnêteté, je pense qu’un site bien construit n’a pas besoin de sitemap pour être bien référencé mais comme l’installation du plugin est facile et ne demande aucune attention post-installation, pourquoi s’en priver ?

A réserver aux aficionados du référencement.

SEO Title Tag

Encore un plugin pour référenceurs ! Un blog gagne à être vu et SEO Title Tag est justement là pour ça. Il offre la possibilité de personnaliser son titre de page que ce soit pour une page statique, un billet, les pages d’archives, les catégories ou toute autre URL gérée par WordPress.

L’intérêt ? Eviter d’avoir des titres à rallonge affichés sur votre blog tout en bénéficiant de titres de pages plus longs et optimisés pour votre référencement. Un exemple concret est ce billet même. Regardez le titre au-dessus du texte (Les meilleurs plugins pour WordPress) et le titre affiché dans la barre de titre (Les meilleurs plugins pour WordPress : Akismet, Feedburner, FlickRSS, SEO Title Tag, Simple Tagging) … ça parle tout seul

Simple Tagging

Encore un plugin pour référenceurs ? Hélas pour ceux qui s’en fichent, tant mieux pour ceux qui s’y intéressent. Les tags (ou labels ou encore mots-clés – mais ça rappelle l’époque de la bulle Internet) viennent en complément des catégories de WordPress.
Le plugin est astucieux et pratique puisqu’il propose une saisie prédictive, suggère des tags et permet de voir des billets relatifs. Il faudra cependant mettre les mains dans le cambouis pour tirer pleinement parti de ses possibilités (lister des billets par tag notamment).

Attention cependant, avec l’arrivée de WordPress 2.3, la gestion des tags sera directement intégrée et ne nécessitera pas de plugin (si ce n’est pour en étendre leurs fonctionnalités). Je vous conseille donc d’attendre la sortie de cette version. Je conseille ce plugin aux personnes qui ne migreront pas vers WordPress 2.3 mais aussi parce que je l’utilise depuis quelques semaines. Son utilisation m’a offert une visibilité dans certains moteurs comme Technorati.

Subscribe to Comments

Cette fois ce plugin s’adresse à toutes et à tous mais surtout à vos visiteurs. Qui n’a jamais répondu à un commentaire et oublié de revenir sur un site pour voir si d’autres personnes avaient réagi ? Plein de monde dont moi. Difficile de s’abonner à tous les flux RSS de commentaires de sites sur lesquels on est actif car c’en deviendrait impossible à gérer.

Heureusement Subscribe to Comments ajoute une petite boîte à cocher au niveau du formulaire des commentaires et ceci dans le but de notifier les auteurs de commentaires que de nouvelles réponses ont été publiées. Vraiment, vos visiteurs apprécieront et leur retour sur votre blog n’en sera que facilité.
Du côté administration, il y a quelques statistiques sur les billets présentant le plus d’abonnés, les derniers abonnés etc.

WP-PostViews

Une bonne petite extension narcissique mais qui permet de mesurer rapidement l’intérêt que portent les visiteurs à votre contenu. Comptabiliser le nombre de lectures de chaque article et afficher ce nombre est son dada. Il faudra cependant triturer un petit peu le code des thèmes dans lequel vous voulez intégrer le plugin après activation. Les instructions sont cependant suffisamment claires pour y parvenir avec un faible bagage technique.

WordPress.com Stats

Enfin on termine sur des statistiques, encore une fois me direz-vous. Celles-ci sont fournies par l’éditeur de WordPress à partir du moment où vous disposez d’une clé API WordPress (c’est le cas si Akismet est activé et configuré sur votre blog). Il fournit un onglet supplémentaire dans votre tableau de bord et résume les liens entrants vers votre blog, les billets les plus lus du jour, les liens externes cliqués et de la veille ainsi qu’une courbe de progression de votre audience.
Je pense que c’est un bon plugin pour débuter et suffisamment complémentaire avec Google Analytics et Feedburner pour ne pas avoir à s’en passer.

Qui a dit que le spam c’était le Mal ?