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 …

High Performance Web Site, sous-titré Essential Knowledge for Frontend Engineers, est ce genre de livre à lire au moins une fois à défaut de le posséder. Il résume en à peu près 120 pages 14 points d’optimisation d’un site Web.

C’est d’autant plus intéressant que l’approche se base sur les mécanismes et non sur de l’optimisation de code. Ainsi dans la plupart des cas, vous n’aurez « que » du paramétrage serveur à faire.

Ce livre fait étrangement penser aux conseils de haute performance prodigués par le Yahoo! Developer Network et repris par l’extension Firefox pour Firebug, j’ai nommé YSlow.
C’est normal : ce livre est écrit par un ingénieur de Yahoo!, probablement un de ceux qui ont participé à la rédaction du guide de performances.

Pourquoi acheter High Performance Web Sites ?

On serait tenté de ne pas acheter le livre puisqu’une bonne partie de ses conseils sont repris sur le guide de haute performance cité plus haut.

Sachez toutefois que cet ouvrage va plus loin dans le détail, prend bien le temps de présenter ses tests de performance pour illustrer et de justifier l’application de leurs méthodes. La plupart des relevés de mesure sont effectués sur une dizaine de sites allant de Google à Amazon.

J’achèterais ce livre si j’étais :

• un administrateur système chargé d’héberger 1 ou plusieurs sites Web
• un technicien/webmaster en charge d’un site à plus ou moins fort trafic
• un développeur Web soucieux des performances de ses productions
• toute personne avare en kilo-octets superflus
• toute personne voulant accélérer les temps de réponse de son ou ses sites Web

Les 14 points d’optimisation

High Performance Web Sites axe son discours sur 14 points :

1. Limiter le nombre de requêtes HTTP
2. Utiliser un Content Delivery Network (CDN)
3. Utiliser une entête Expires
4. Compresser les composants avec Gzip ou Deflate
5. Placer les feuilles de style en début de page
6. Placer les scripts JavaScript en bas de page
7. Éviter les expressions CSS (Internet Explorer)
8. Placer les scripts JavaScript et les feuilles de style dans des fichiers externes
9. Réduire le nombre d’appels à des DNS différents
10. Minifier le JavaScript et les CSS
11. Éviter les redirections
12. Supprimer les doublons de scripts
13. Configurer ETags
14. Permettre la mise en cache des appels Ajax

Il prend cependant le soin de bien expliquer les mécanismes d’HTTP et les intérêts à améliorer les performances frontend.

Le livre termine sur un comparatif des 14 points sur 10 sites, notation YSLow comprise, dont Amazon, Google, CNN, eBay, Wikipédia et Yahoo!.

La mise en pratique

J’étais déjà sensibilité à presque tous les points pour avoir lu ces fameuses 14 règles en utilisant l’extension YSlow et Firebug. Cependant après la lecture du livre j’ai eu davantage de clés et des exemples probants pour me convaincre de les mettre en œuvre.

On peut appliquer la majorité des points et les points pertinents en 1 heure. En effet, tout site ne peut se permettre d’utiliser un CDN pour accélérer les temps de réponse autour du globe.

Personnellement j’ai mis en place une compression Gzip directement au niveau d’Apache au lieu d’utiliser une compression effectuée en PHP (avec Gzip aussi). J’ai couplé cet effort avec la minification JavaScript et la désactivation des ETags.

J’avais déjà au préalable externalisés mes CSS et JavaScript, placé au bon endroit (mais seulement les appels externes au DNS principal en bas de page) et sans doublon.

C’est bête à dire mais le résultat s’est vraiment senti avec des chargements de page incroyablement plus rapides. YSlow est effectivement un compagnon idéal pour la mise en application de ces éléments avec son analyse des performances et des composants.

Conclusion

J’ai dévoré High Performance Web Sites grâce à sa simplicité de rédaction, les nombreux exemples et surtout, les explications enrichissantes. Elles sont mises en application sur Yahoo! et certes, même si on peut se dire qu’on n’a pas de site de leur envergure, leurs conseils sont toujours bons à prendre.

High Performance Web Sites est un concentré de bonnes pratiques, simples à mettre en œuvre. Pourquoi s’en priver ?

Ces optimisations ne sont évidemment pas les seules à mettre en place pour que tout fonctionne bien : il faut aussi produire du code HTML propre, du JavaScript optimisé, du code application qui ne soit pas redondant.

C’est un bon début et des pratiques à généraliser.

Firebug fait partie de mes extensions préférées depuis un bon moment. Je l’estime aujourd’hui même plus importante que l’extension Web Developer, c’est dire.

J’ai pourtant constaté que la plupart de ses utilisateurs la sous-exploitait en se limitant à la console pour consulter les erreurs et éventuellement à l’inspecteur HTML pour remonter rapidement dans l’arborescence des balises en 1 clic. C’est bien mais pas assez.
Firebug est tout simplement énorme ! Suffisamment énorme pour gagner un temps incroyable dans le développement d’applications JavaScript et pour mieux comprendre les incohérences des CSS dans une page, entre autre.

Je vous offre aujourd’hui mon cadeau de Noël pour gagner en productivité et maîtriser cet outil ô combien indispensable.

Le plus amusant dans l’histoire c’est que le site officiel de Firebug dévoile (succinctement certes) tous les petits plus qui simplifient la vie. Je vais m’atteler à les éplucher en fonction des domaines d’utilisation :

1. pour le HTML et les CSS
2. pour le JavaScript
3. pour gagner en performances

Firebug pour le HTML

L’inspection HTML

J’apprécie l’inspection HTML car elle me permet de retrouver simplement le code lié au visuel. Après avoir activé l’inspecteur, je survole l’élément sur lequel je veux travailler, je clique dessus et le volet Firebug se fige dessus en m’indiquant toutes ses propriétés CSS, le modèle de boîte et ses propriétés DOM. On en reparle tout de suite après.
L’inverse est également possible. C’est à dire qu’en survolant le code, la correspondance visuelle dans la page est établie. C’est rudement pratique pour repérer des éléments qui sortent du flux. Ça l’est d’autant plus que les différentes marges (internes, externes, bordures) sont elles aussi mises en surbrillance.

Le gros atout de cet inspecteur c’est également l’édition à la volée de toutes les balises ! Idéal pour tester diverses classes d’un objet ayant un impact visuel fort sur son affichage. Cet outil présente un gain de temps énorme par rapport à la modification du code dans son éditeur et un petit coup de touche F5 dans la foulée.

Il faut également retenir que toute balise est sélectionnable en cliquant sur son nom (div, h3 etc.). Cela a a pour effet de mettre à jour le panneau latéral de Firebug. Panneau latéral qui est également fort utile.

L’inspection CSS, Layout et DOM

Le panneau latéral de l’inspecteur HTML se compose de 3 onglets, tous très utiles.

Inspecteur CSS

Les propriétés CSS affichées concernent uniquement l’objet actif et c’est ce qui en fait sa force. Ce panneau indique en effet la cascade CSS en cours ce qui permet de comprendre rapidement pourquoi sa feuille de style n’est pas appliquée comme il faudrait. Elle a la bonne idée de mentionner quelle feuille de style est utilisée et quelle ligne. De quoi corriger ça dans son éditeur favori rapidement.

Ou pas. En effet l’inspecteur CSS permet, tout comme l’inspecteur HTML, de modifier les propriétés à la volée et sans fioriture. Si je précise sans fioriture c’est parce que l’éditeur à la volée de Web Developer rend parfois l’affichage de la page bancale en décalant des éléments. Là vous pouvez totalement compter sur l’éditeur intégré et ce n’est pas un luxe !
Désactiver, supprimer, modifier ou ajouter des propriétés sont quelques-unes des actions que vous pourrez effectuer à même la page.

Là encore c’est une des parties où les gains de temps sont énormes. On peut en effet modifier ses CSS et les tester tout en observant l’impact immédiat de ses modifications.

Inspecteur du modèle de boîte (Layout)

Le modèle de boîte CSS peut vite devenir pénible à gérer et plus particulièrement quand on visualise mal le cumul des différentes marges.
Dans tous les cas c’est appréciable de pouvoir constater les marges en présence et encore, de pouvoir modifier leurs dimensions à la volée. Firebug a la bonne idée de colorer les marges intérieures (padding), extérieures (margin) et les bordures (border) d’une couleur différente.

Il a également la bonne idée d’afficher une double règle millimétrée au survol du panneau layout. Très pratique dans le cas de design en grilles ou nécessitant un certain rythme de visualisation.

Inspecteur DOM

Ah l’inspecteur DOM ! S’il n’existait pas il faudrait l’inventer. Firefox proposait déjà un tel outil à la différence près qu’il était moins pratique d’utilisation.
L’inspecteur DOM m’est moyennement utile dans le cas d’une simple inspection du code HTML bien que ce soit toujours pratique de visualiser la présence ou pas d’objets JavaScript dans tel ou tel élément. C’est fortement appréciable pour la librairie Prototype étant donné les dégâts causés par son extension du DOM à gogo.

Firebug pour le JavaScript

L’inspecteur JavaScript

C’est l’autre outil indispensable de Firebug. Avec lui, c’en est fini des alert(mavariable);. L’inspecteur DOM prend avec lui toute son utilité.

J’illustre sur l’image ci-dessus l’utilisation des points d’arrêt (breakpoints). Il suffit d’un clic à gauche d’un numéro de ligne pour en placer/retirer un. Concrètement quand l’exécution du JavaScript arrivera au premier point d’arrêt, elle va se stopper.
Quel intérêt ? Observer. En agissant ainsi, vous avez la main sur toutes les variables connues au sein de votre code/fonction. Très utile pour connaître les paramètres passées à la fonction et détecter les erreurs. C’est pour cette raison que les alert() deviennent inutiles : tout est à portée de main. Vous ne pesterez plus contre un undefined mal placé

En parallèle de ça, l’inspecteur DOM est à utiliser pour visualiser d’un coup d’œil les différentes variables actives ainsi que leur arborescence. Comme tout est cliquable, l’inspecteur vous transporte sur n’importe quel objet pour en étudier le contenu.

La console Firebug alias console.*

La console Firebug est l’autre tueuse d’alert() et s’utilise de deux manières.

La plus accessible est d’interagir avec. Vous saisissez votre code, la console l’exécute et retourne le ou les résultats. Encore une fois les objets sont cliquables et navigable au travers de l’inspecteur DOM.
La console est utile pour utiliser des fonctions sorties du contexte de l’initialisation : il devient tout à fait possible de piloter des éléments après le chargement de la page. Ça évite encore une fois des F5 inutiles et consommateurs de temps.

L’autre manière d’utiliser la console c’est de ne pas l’utiliser. Ou pas de manière active tout du moins puisqu’elle est également un objet JavaScript (console) utilisable dans votre code auquel sont rattachées plusieurs fonctions au nom explicite :

• console.log() : affiche une information standard
• console.info() : affiche une information de type « information »
• console.warn() : affiche une information de type « avertissement »
• console.error() : affiche une information de type « erreur »
• console.debug() : débogue le contenu d’un objet directement dans la console

Autrement dit, si l’inspecteur ne suffisait pas, au lieu de lancer un alert(mavariable) (potentiellement dangereux dans une grande boucle qui n’a jamais cliqué 50 fois sur « OK » à cause de ça ?), il vaudra mieux utiliser console.log(mavariable). Il y a de quoi faire, surtout avec la possibilité de créer des groupes de messages et l’utilisation de la syntaxe printf.

Et top du top, en cas d’erreur JavaScript, la console affiche un petit cercle rouge qui rappelle fortement le point d’arrêt. Normal puisque c’en est un. Un clic et on évite de rechercher la ligne problématique dans le code. Encore une fois, du temps de gagné.

Firebug pour les performances

Après avoir bien développé, Firebug propose de mieux développer. L’extension magique propose quelques outils sympathiques pour rapidement déceler les problèmes, notamment de scripts trop gourmands ou à optimiser.

Le traceur réseau

Avec le traceur réseau c’est simple, tout ce qui est chargé sur la page est chronométré. Si un élément est systématiquement long à charger en tête de liste, pourquoi ne pas essayer de le déplacer dans le bas de la pile ? Je pense notamment aux appels vers des fichiers JavaScripts externes. Les appeler en bas de page permet d’éviter des gels de page. C’est ce que YSlow nous recommandera

Outre une petite prévisualisation des contenus, le traceur affiche aussi les statuts des contenus s’ils sont différent du statut 200 (found). Et de surligner ça en rouge en cas de fichier introuvable.

J’aime beaucoup le traceur pour le suivi des requêtes XHR (appels AJAX). Un clic sur un appel affiche à la fois les entêtes, les données transmises au serveur et sa réponse. Fini les requêtes AJAX qui ne produisent rien sans qu’on puisse savoir pourquoi. Le clic droit sera également un fidèle allié, notamment pour ouvrir l’appel AJAX dans un nouvel onglet. C’est plus lisible pour déboguer quand même

Le profileur JavaScript

Le profileur (profiler) JavaScript s’utilise un peu à la manière de la console : de manière active ou au travers de l’objet console.

Le profileur enregistre tout ce qui se passe entre le moment où il est enclenché et le moment où il est stoppé. Il va ainsi dénombrer toutes les appels (calls), leur durée d’exécution et leur fichier d’origine, entre autre. L’idée est bien entendu de voir ce qui consomme le plus d’appels et de temps pour savoir si ce comportement est normal ou pas. À ce stade là, difficile de pousser la granularité du profileur plus loins.

Sauf en utilisant le profileur directement dans le code comme on a déjà pu le faire pour les logs. console.profile() et console.profileEnd() seront vos amis. C’est vraiment l’idéal pour profiler l’exécution d’une fonction, voire même les portions de code exécutée en son sein.

L’extension YSlow

L’extension YSlow est une extension pour Firefox mais elle nécessite toutefois la présence de Firebug. Elle s’articule autour de trois critères.

Il y’ a d’une part la surveillance des performances. YSlow se base sur la liste des bonnes pratiques établies par Yahoo! (14 à l’heure actuelle). YSlow passe ces critères en revue et accorde une note en conséquence. Si certaines sont difficiles à tenir, c’est un bon moyen de s’intéresser à de nouvelles pratiques d’optimisation et de performances.

Le second critère est affiché dans le panneau stats. Il s’agit de la capture d’écran ci-dessus. Certes il s’agit d’un simple tableau mais dont les chiffres sont intéressants à étudier. YSlow analyse la page pour un premier et un second chargement. La différence entre les deux ? C’est que le cache est passé par là et normalement, je dis bien normalement, le second chargement se doit d’être beaucoup plus rapide.
Si ce n’est pas le cas, il y a de l’optimisation à faire et cela peut aussi signifier du côté serveur Web. Pas forcément du développement donc.

Enfin on termine sur une partie complémentaire aux stats : les composants (components). Elle distille des informations plus verbeuses que le traceur réseau de Firebug en se focalisant sur les E-Tag, la présence ou pas de compression, la date de validité du cache ainsi que la taille des objets.

Conclusion

J’espère avoir éclairé quelques lanternes sur l’utilisation de Firebug. Cette extension est suffisamment puissante pour gagner en confort de développement ; il serait dommage de s’en priver. On gagne du temps, du confort et surtout, de la qualité de développement.
À noter qu’il existe aussi Firebug Lite. Il s’agit d’un script JavaScript compatible avec les principaux navigateurs du marché mais comme le Lite l’indique, les fonctionnalités sont plutôt limitées. Seule la console JavaScript persiste.