Des conférences de choix

Les thématiques abordées sont une nouvelle fois intéressantes. Si leur titre n’est pas forcément attirant, la qualité des intervenants fait qu’à n’en pas douter, on va encore en prendre plein les yeux : suffit de lire le programme.

Parmi celles qui retiennent toute mon attention :

• Intégrateurs, montez au front !
  Notamment parce que j’ai participé à l’enquête sur le dialogue entre webdesigner et intégrateur et qu’il s’agit d’une pierre angulaire de la réussite graphique d’un projet.
• Un seul Web
  Car l’an dernier j’avais été épaté par la présentation des nouveautés CSS3 de Daniel Glazman.
• CSS peut-il être orienté objet ?
  Parce que je crois beaucoup aux nouvelles méthodes de réutilisation et de conception CSS ; cette approche combinée à d’autres outils CSS est à mon avis la meilleure qui soit.
• CSS3 : Future Style Now
  Parce qu’il est toujours bon de savoir comment utiliser les technos que l’on utilisera dans pas trop longtemps.
• WCAG 2.0, Flash, PDF, Javascript et les autres sont dans un bateau
  Une bonne piqûre de rappel sur l’accessibilité et les différentes boîtes noires qui sont devenus des standards de facto.
• Les nouveaux standards du web et leur implémentation dans les navigateurs modernes
  Le titre parle de lui-même

C’est sans compter sur les ateliers techniques où là, je n’ai pas encore fait mon choix … la concurrence est rude

Atelier technique sur Gears

Il y a toutefois un atelier où je suis sûr d’être présent, c’est celui-ci : le Web en Offline avec Gears et HTML 5, à 14h00 pour la digestion . Et pour cause, je l’animerai … enfin, encore faut-il que j’en termine la présentation. En voici la description officielle :

Gears est un outil Open Source, majoritairement connu pour permettre à une page Web d’être consultable en étant déconnecté du réseau. Ce plugin pour navigateur Web propose pourtant d’autres briques utiles dans d’autres contextes, notamment les performances et le traitement d’un nombre important de données. C’est un outil unique permettant de créer des applications fonctionnelles hors-ligne et cross-brower sans avoir à recours à du client lourd (type application iPhone).

La présentation se focalisera sur la présentation des composants, des exemples d’utilisation mais aussi sur les contraintes et les choix de stratégie à adopter dans son code pour éviter la création d’usines à gaz.

L’atelier concluera sur l’avenir et HTML 5 dans la mesure où les travaux de Gears sont désormais intégrés à la spécification HTML 5.

Mais globalement, l’atelier s’articulera autour des points suivants :

• présentation des modules de Gears
• contraintes d’ergonomie
• implications en terme d’architecture de code
• débat ouvert avec l’assemblée

Le choix sera difficile avec en même temps un atelier de David Larlet et Charles McCathieNeville … où j’aurais aimé également être présent.

À samedi … et jeudi et vendredi pour d’autres

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.

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 …

Cela fait maintenant plus d’1 an que j’utilise Twitter. Passée l’appréhension du gadget puéril, je l’ai finalement converti en outil de communication, de réseautage et de veille … comme beaucoup de ses utilisateurs d’ailleurs.

Seulement voilà, les pannes à répétition sont, à mon sens, en train de ruiner un service qui aurait pu être encore plus ravageur qu’il ne l’a été. Plusieurs concurrents s’y sont essayés, aucun ne l’a encore détrôné.

À part peut-être Jaiku, si Google réussit son coup.

Jaiku, Twitter : micro-blogs et/ou messagerie instantanée délocalisée

Entre messagerie instantanée asynchrone et micro-blogs, mon cœur balance.

Toutefois le dénominateur commun de Twitter, Jaiku, Plurk, Pownce et toute la clique ce sont les messages en 140 caractères adressés au monde entier.
En soi c’est assez amusant de constater que cette limite a été adoptée pour tenir sur 1 SMS (tant en envoi qu’en réception) … alors que nous sommes sur le Web. Cet exercice aura le mérite de favoriser le partage d’URL et d’améliorer l’esprit de synthèse de beaucoup.

Malgré tout mon enthousiasme pour Twitter, je n’ai pour l’instant envie que d’une chose : un service stable. Autrement dit :

• des flux RSS / une API qui répond 99,9% du temps : quand je regarde mes twit une fois par heure et que je constante une désespérante « erreur inconnue » dans le widget Netvibes … no comment
• un service qui ne s’effondre pas une page sur 2 en plein milieu de journée
• un service qui communique sur ses problèmes : déjà 3 semaines que le client IM est hors-ligne. C’est pourtant le deuxième client Twitter le plus utilisé

Pourquoi Jaiku est mieux que Twitter

Jaiku ne bénéficie pas du même engouement que Twitter, peut-être pas à tort. Son adoption a été fortement freinée par le rachat de Google en 2007. Ce rachat a placé Jaiku en inscription sur invitation.
Parallèlement à ça, très peu de nouveautés ont fait leur apparition sur le service.

Et avec ça je tente de vous convaincre que Jaiku est mieux ? Et pourtant :

• automatisation de l’intégration de vos flux (RSS, Twitter, Last.fm etc.) avec une présentation des plus sympathiques (exemple ci-dessus avec Flickr, mon service photo préféré)
• une interface Web beaucoup plus agréable : identification facile des source des données, différenciation de nos messages et des flux aggrégés, filtrage des sources de flux
• une API plus sécurisée : parce qu’il ne faut jamais, ô grand jamais donner son mot de passe, cette hérésie est remplacée par une clé unique (mais malheureusement pas regénérable)
• les « channels » ou groupes de discussion. Ils facilitent la création de conversation liées à une thématique ou à des sites/services Web. Pratique pour éviter la schizophrénie du multi-compte.

Pourquoi Twitter est mieux que Jaiku

Malgré tout, Twitter possède une bonne avance, notamment grâce à son énorme base d’utilisateurs :

• immense parc d’applications, tant en terme de mashups que de clients pour twitter. Au hasard : TwitBin, Thwirl, TwitterVision, Summize, TwitterShare, TwitLinks etc.
• une API simple et complète (mais du coup, pas sécurisée : donner son mot de passe n’est pas recommandable)
• une prise en main immédiate : pas de fioriture, tout est simple
• fonctionnalité de veille sympathique : « track ». Recevez tous les twit qui contiennent tel ou tel mot
• affichage affiné avec la possibilité de n’afficher que les réponses qui nous sont faites (@replies)

Comment Jaiku peut surpasser Twitter

Twitter conserve fonctionnellement pas mal d’avantages qui justifient encore son utilisation et sa forte adoption. C’est en subissant les pannes répétées et en lisant plusieurs articles, dont «Can Twitter Be Saved» que j’ai sérieusement mis en doute la capacité à Twitter à accompagner ses utilisateurs de manière pérenne.

Jaiku n’avance plus certes mais en surface uniquement. Si Google est malin tout autant que les créateurs de Jaiku, ils ont toutes les clés pour détrôner Twitter et transformer l’essai.
Voici ce que j’aurais aimé voir sur Jaiku pour migrer définitivement dessus :

• une interface internationalisée (i18n) pour faciliter l’adoption dans tous les pays et éviter de laisser l’outil entre les mains des seuls geeks
• intégration d’un ou plusieurs outils au choix de compression d’URL, comme is.gd ou tinyurl
• import de contacts depuis Facebook, Twitter et pourquoi pas, son carnet d’adresse Gmail (par l’API bien sûr)
• forte intégration dans Google (Google News, Google Alerts, Gmail, Google Calendar, Google Talk/Jabber, iGoogle et widgets etc.)
• utilisation de l’infrastructure Google (on parle d’App Engine entre autre)

Après, ma seule crainte ce sont les habituels travers de Google, abandon de service, manque de suivi et opacité de service.

Je garde bon espoir pour Jaiku. À tel point que je suis même en train de produire un widget Netvibes pour Jaikuter depuis n’importe où