J’avais envie depuis longtemps de rendre hommage à la culture asiatique en générale et japonaise en particulier, à cause (ou grâce) à un art culinaire qui m’enchante depuis le premier Canard à l’Orange que j’ai mangé à l’occasion de mon 14ème anniversaire. Depuis, j’ai enchainé les Sushis et les Sashimis…

C’est dans une tentative de diète que j’ai eu l’idée d’intituler ce nouveau thème NoSushaï pour essayer d’arrêter !

Un thème Wordpress très léger

En parlant de diète, ce thème est particulièrement léger puisqu’il est composé uniquement des fichiers index.php, comments.php et functions.php. Pour la mise en page, je me suis laissé tenté par Boks, le générateur de grilles CSS qui s’est occupé de générer un fichier screen.css regroupant les fichiers compressés du framework CSS Blueprint.

NoSushaï en image

js 4 design : les meilleures ressources Javascript pour développeurs web front-end (avec parfois un soupçon de PHP)

NoSushaï, un thème Wordpress pour le blog du développeur web fron-end. Cliquez pour agrandir l'image.

J’espère que chemin faisant, je n’ai pas trop dénaturé la culture graphique asiatique.

Après quelques corrections

Il reste toujours un peu de travail sur un thème après sa mise en ligne et quelques modifications s’imposent ;)

Le thème NoSushaï après quelques modifications. Cliquez pour agrandir l'image.

Parmi les modifications apportées à NoSushaï il y a l’ajout d’une zone de widget pour l’encart publicitaire, le format de la date de publication des billets à côté des titres afin d’éviter les alignements disgracieux quand le mois est trop long, et pour finir, la couleur des titres dans la barre latérale qui était auparavant de la même couleur que les liens est passée en bleue turquoise pour éviter les confusions. Par ailleurs, je trouve que cette couleur s’harmonise mieux avec le rose.

Pas de Javascript ?

Ca peut sembler curieux pour un blog sur Javascript et jQuery, mais pour l’instant ce thème ne comporte aucun appel à Javascript en dehors du script Adsense et du script pour afficher les polices de caractère avec Typekit : l’objectif de js4design est de proposer des ressources, pas forcément d’en consommer !

En ce qui concerne les remarques sur le code de Wordpress, je partage en grande partie les frustrations de Palleas. Je suis également quelqu’un de perfectionniste qui préfère travailler avec des bons outils plutôt qu’avec des mauvais. Toutefois, certains arguments — comme vouloir à tout prix passer à PHP5 pour profiter d’une programmation orientée objet — sont discutables.

La programmation procédurale est plus performante que l’objet qui nécessite plus de ressources. Par ailleurs, PHP4 est encore largement utilisé dans le monde et je trouve plutôt positif qu’une organisation comme Wordpress tienne compte de cette forme d’accessibilité qui consiste à supporter (j’utilise l’anglicisme à dessein) les configurations obsolètes, à la manière de la prise en compte des vieux navigateurs comme IE6. Plus qu’une oeuvre de charité, c’est aussi une  démarche fondamentale lorsqu’on vise une audience mondiale.

Note : d’après le commentaire de Marie-Aude, il semble que l’équipe de Wordpress ai cessé d’assurer la compatibilité avec PHP4 depuis plusieurs versions déjà.

Ce qui m’amène à préciser que Wordpress a été conçu pour être utilisé par un public large, c’est-à-dire pas forcément féru d’informatique ou de programmation. Tout est fait pour qu’avec un minimum d’intérêt et de motivation, la ménagère de moins (ou plus) de 50 ans puisse publier des articles, installer elle-même sa page contact, créer ses rubriques, etc. C’est la même philosophie qui fait que la création d’un thème Wordpress est si simple et qu’un minimum de connaissances suffise pour se lancer dans l’aventure.

Bref, dans Wordpress, c’est le code qui est au service de l’auteur du blog et pas le contraire ! Ceci dit, Wordpress est une plate-forme de blog, alors pourquoi donc vouloir lui faire faire tout et n’importe quoi ? Ce ne sont pourtant pas les CMS offrant du code et une architecture respectant un standing de haut niveau qui manque !

Certains voient dans cette suprématie de Wordpress, un calcul marketing et une volonté d’écraser la concurrence comme le fait Google dans le secteur des moteurs de recherche. Pour ma part, cette supériorité s’explique aisément : il n’existe pas de CMS gratuit proposant un éditeur visuel et un système aussi simple et performant pour gérer les images que Wordpress. Il ne faut pas perdre de vue que la saisie et la mise en forme de textes et d’images sont le coeur et la raison d’être de tout CMS.

L’absence d’un éditeur visuel intégrant images, son, vidéos, etc. se fait cruellement sentir au moment d’expliquer aux clients que non, pour afficher les images de son choix, ça ne va pas être possible ou si peu… Mon article sur les étapes nécessaires pour avoir dans Drupal un confort similaire à Wordpress out of the box en témoigne.

Du coup, même si les besoins du client font pencher la balance pour l’installation d’un CMS plus costaud comme Drupal, j’ai quand même tendance à pousser Wordpress dans ses retranchements pour éviter que le client ne passe son temps à se battre contre son système de gestion et de publication de contenus au lieu de travailler avec ;)

Mes deux cents ;)

Notes (23/01/2010 à 13h25) : pour préciser mon opinion, j’ai bien compris que Palleas ne s’attaque pas à tous les utilisateurs de Wordpress mais seulement à ceux qui pensent être développeurs parce qu’ils ont copiés-collés un `if ( is_home() )` dans un thème Wordpress. Pourquoi pas. Le (petit) problème c’est que ces propos ne visent personne en particulier, donc, fatalement, tous les utilisateurs de Wordpress se sentent un peu visés, c’est la nature humaine (toujours le même problème).

Je vais revenir sur la manière dont Wordpress est codé. Mais avant, je demande aux développeurs d’ouvrir un peu les fenêtres et de prendre un bol d’air frais ! Ca fait des années que des amis développeurs (certainement les mêmes que Palleas) m’ont expliqués pourquoi ils trouvaient que Wordpress était mal codé et comment il faudrait faire pour obtenir quelque chose de mieux. Ce n’est donc pas nouveau et d’ailleurs au sein même de Wordpress il y a des débats qui se sont soldés par la création d’un nouveau système de blog bâti sur des fondations plus saines (programmation objet, etc.) par une équipe « dissidente ».

Ce projet s’appelle Habari (http://habariproject.org/en/) et tout un chacun peut le télécharger et contribuer à son développement. Je l’ai d’ailleurs installé à l’adresse http://css4design.com/factory. Je suis donc surpris de constater que des « vrais » développeurs continuent d’installer des Wordpress pour leurs besoins personnels, au sein de leur entreprise, ou pire encore, pour leurs clients alors qu’une alternative « cool » existe. S’ils continuent, c’est que le projet Wordpress dans son ensemble ne doit pas sentir si mauvais que ça :D

Pour en revenir au code, il faut que les développeurs purs et durs prennent conscience que tous les intervenant de la chaine de production d’un site web n’ont pas les même notions quant à la qualité du code ni les mêmes attentes. Il m’est souvent arrivé de pester contre des développeurs ravis d’avoir trouvé une solution élégante pour résoudre leurs problèmes sans s’inquiéter de savoir si les fonctions, classes, méthodes, etc. qu’ils avaient développées correspondaient aussi aux besoins des intégrateurs web en bout de chaine. Le syndrôme du : « j’ai fait mon boulot, ça marche chez moi » est un argument récurrent.

De ce point de vue, les fonctions (template tags) proposées par Wordpress pour les intégrateurs sont un modèle du genre et chaque fois que je le peux je les montre aux développeurs avec qui je dois travailler pour leur donner une idée de ce que sont des livrables « cool » du point de vue de l’intégration.

PS : je viens de tomber sur cet excellent article qui tombe bien à propos : Pourquoi je suis passé de Dotclear à Wordpress.

Ma connaissance de Drupal est proche de zéro : j’ai abordé cet article sous l’angle de celui qui a l’habitude d’utiliser Wordpress au quotidien. Il ne s’agit pas d’un comparatif entre Drupal et Wordpress : les deux CMS présentent des différences dans leur mode de fonctionnement dont vous aurez un bon aperçu en lisant l’excellent billet Drupal et WordPress : deux logiques proches, mais différentes de Marie-Aude.

Amadouer Drupal

La première chose à faire est de télécharger la dernière version stable de Drupal et de décompresser l’archive pour la copier sur votre serveur. Pour information, j’utilise un hébergement mutualisé chez PHPNET qui semble posséder les pré-requis nécessaires, ce qui peut ne pas être le cas partout.

Saisissez l’adresse de votre site web et suivez les étapes de l’installateur automatique. En ce qui me concerne, l’assistant s’est arrêté à l’étape de la saisie des informations permettant la connexion à la base de données MySQL. A ce niveau, deux problèmes au moins sont susceptibles de survenir (et sont comme par hasard survenus) :

1. Un caractère spécial dans le mot de passe peut empêcher la connexion à la base de données. Méfiez-vous donc des caractères : / @ + ( ) ? = & car vous risquez de ne pas aller très loin. Des caractères d’échappement sont prévus, mais sait-on jamais.

2. Il semble que l’installation automatique soit comme les antiobiotiques et qu’il soit nécessaire d’écrire en dur les éléments pour la connexion avec la base de données : nom de la base, nom d’utilisateur, mot de passe et nom du serveur dans le fichier /sites/default/default.settings.php qu’il faudra renommer en settings.php. Saisissez à nouveau ces informations dans l’assistant pour passer à l’étape suivante.

   Notes : Il ne faut pas simplement renommer le fichier. Il faut créer un fichier settings.php à côté du dossier default.settings.php soit en dupliquant et renommant ce dernier, soit en créant un fichier vide nommé settings.php

Lire Installation de Drupal.

Drupal, au pied !

Une fois que vous aurez posé la souris dans le menu Administer, la palanquée d’options et de paramètres disponibles vous fera prendre  conscience du potentiel de Drupal. N’ayez pas peur et suivez le guide pour avoir un Drupal fonctionnel à votre service plutôt que l’inverse !

Vous aurez besoin d’installer de nombreux modules parfois dépendants d’autres modules. C’est le prix à payer pour… la modularité. Et oui, la force de Drupal est d’être entièrement composé de modules ; les éléments de base du moteur ne sont finalement que des modules obligatoires.

L’installation de ces modules s’effectue en suivant généralement les étapes suivantes :

• Téléchargez et décompressez le module,
• Faites glisser le dossier du module vers le dossier modules de votre installation,
• Activez le modules et ses sous-modules éventuels dans le dossier Administrer › Construction du site › Modules,
• Personnalisez les paramètres dans Administrer › Configuration du site › Votre_Module.

Notes : Les pages permettant d’installer les modules sont assez peu friendly. Toutefois, les explications sont concises et claires ; les dépendances entre les modules sont bien indiquées et sont d’ailleurs rappelées dans la page permettant d’activer les modules. Les dépendances peuvent même s’activer automatiquement lorsqu’elles se trouvent toutes dans le dossier modules. C’est assez bien fait.

Des URLs propres

Tout se passe bien ? Ok, passons à la suite. Une des premières choses que je fais lorsque j’installe un CMS, c’est de jeter un oeil sur les paramètres permettant d’avoir des URL’s propres (sans le point d’interrogation). Dans Drupal, ça se passe dans Administer › Site configuration › Clean URLs.

La case Disabled est cochée et si tout va bien vous pourrez cliquer sur Enabled. Si ce n’est pas le cas, ouvrez le fichier .htaccess à la racine de votre installation et supprimez le commentaire # devant la ligne # RewriteBase / (ligne 107 vers la fin du document). L’adresse http://votresite.fr/?q=admin/settings/clean-urls se transforme alors en http://votresite.fr/admin/settings/clean-urls.

Drupal en français

Pour avoir Drupal en français, rendez-vous sur la page de téléchargement et choisissez votre traduction. Contrairement à Wordpress où un seul fichier est nécessaire pour la traduction de l’interface d’administration, vous verrez qu’il faut ajouter pas moins de 44 fichiers de traduction répartis dans 77 dossiers.

Heureusement, il suffit de faire glisser les dossiers décompressés aux emplacements adéquats sur votre serveur pour qu’ils fusionnent avec ceux qui sont déjà là (si vous travaillez sur Windows, prenez garde de ne pas remplacer les dossiers).

Assurez-vous ensuite que les modules Locales et Content Translation sont activés dans Administer › Modules. Allez ensuite dans Administer › Site Configuration › Languages et cliquez sur l’onglet Add Language et choisissez French dans le menu déroulant. Validez et sélectionnez French par défaut. Enregistrez la configuration et voilà ! Drupal est en français.

Lire Drupal 6 : comment installer la langue française.

Un éditeur WYSIWYG

Une fois Drupal en français, il est temps de passer à la rédaction des contenus. Dans Drupal, l’éditeur pour rédiger les pages ou les billets est livré en deux parfums :

1. Filtered HTML :  les adresses de pages web et de messagerie électronique sont transformées en liens automatiquement. Les tags HTML autorisés sont limités à  <a>, <em>, <strong>, <cite>, <code>, <ul>, <ol>, <li>, <dl>, <dt>, <dd>. Les lignes et les paragraphes vont à la ligne automatiquement.
2. Full HTML : les adresses de pages web et de messagerie électronique sont transformées en liens automatiquement. Les lignes et les paragraphes vont à la ligne automatiquement. Tous les tags HTML sont autorisés.

Notes : vous verrez plus tard qu’il est possible d’associer un éditeur selon les droits accordés aux utilisateurs de Drupal. Vous pourrez ainsi réserver la version Full HTML de l’éditeur aux administrateurs du site et la version Filtered HTML aux autres contributeurs. Point positif, le champs d’édition peut se scinder en deux pour créer un résumé ou un chapô.

Installer un nouvel éditeur visuel

Malgré tout, cet éditeur est un peu rustique comparé à ce que l’on a l’habitude de voir sur Wordpress. Pour avoir un éditeur digne de ce nom, il faut installer WYSIWYG API qui gère l’installation d’autres éditeurs comme TinyMCE ou FCKEditor, bien plus conviviaux. Et si vous en profitiez pour utiliser BBComposer ?

Notes : arrivés là, vous avez certainement eu l’occasion de voir la richesse des options disponibles dans Drupal. L’édition des articles ne fait pas exception et on commence déjà à voir des différences significatives avec Wordpress. Notamment en ce qui concerne les paramètres du menu qui permettent de donner un titre plus court pour faire apparaitre l’article dans un menu. Il est même possible de choisir le poids de l’entrée du menu pour préciser son emplacement.

Dès que le module wysiwyg est décompressé, faites-le glisser dans le répertoire modules de votre installation Drupal et activez-le dans Administrer › Construction du site › Modules › User Interface › Wysiwyg.

Cliquez ensuite dans Administrer et sur Par module (à côté de Par tâche) pour installer ou choisir un éditeur visuel à votre convenance. Vous avez le choix entre 9 éditeurs côté client :

1. jWYSIWYG
2. FCKeditor
3. markItUp
4. NicEdit
5. openWYSIWYG
6. TinyMCE
7. Whizzywig
8. WYMeditor
9. YUI editor

Notes : si vous installez FCKeditor, faites attention à ne pas télécharger la nouvelle version CKEditor 3.1, qui ne semble pas encore compatible avec le module wysiwyg. Descendez plus bas dans la page et choisissez FCKeditor 2.6.5. Ou dirigez-vous vers TinyMCE. Notez toutefois que si l’éditeur CKeditor n’est pas pris en charge directement par le module Wysiwyg, il est tout de même disponible comme module indépendant.

J’ai voulu installer openWYSIWYG, mais la version de démonstration m’indique que mon navigateur (Google Chrome) n’est pas pris en charge. C’est balot qu’un projet open source ne prenne pas en charge un produit basé lui aussi sur de l’open source :/

Une fois l’archive décompressée, créez le répertoire /sites/all/libraries et copiez le dossier tinymce. Lorsque vous cliquerez sur Administrer › Configuration du site › Wysiwyg, vous aurez la possibilité d’associer TinyMCE au format d’entrée Filtered HTML ou Full HTML (ou les deux). Comme vous le devinez sans doute, il est bien entendu possible d’associer un éditeur visuel différent par format d’entrée. Il suffit de répéter les étapes précédentes pour comparer TinyMCE avec FCKeditor, par exemple, qui dispose d’une interface en français, ce qui n’est pas négligeableNotez que si l’éditeur CKeditor (nouvelle version de FCKeditor) n’est pas pris en charge directement par le module Wysiwyg, il est tout de même disponible en tant que module indépendant..

Modifier les préférences de tinyMCE ou FCKeditor

Le point fort de Drupal dans sa gestion des éditeurs wysiwyg, c’est sa capacité de pouvoir associer un éditeur différent selon les contributeurs en fonction de leurs besoins ou des restrictions que vous voudrez leur imposer, ou de modifier les préférences d’un même éditeur visuel selon les contributeurs pour affiner encore plus la gestion des droits.

Pour cela, retournez dans le module wysiwyg et modifiez le format d’entrée pour accéder aux options Paramètrage de base, Boutons et plugins, Apparence de l’éditeur, Nettoyage et sortie et CSS. Notez que seuls les boutons cochés seront activés au final ; ils ne s’ajoutent pas à ceux qui sont définis par défaut, mais constituent en quelque sorte un nouveau package. En gros, il manque une case Tout sélectionner ;)

Voir Install FCKeditor Using WYSIWYG API.

Insérer des images dans Drupal, mission impossible ?

Quand on a l’habitude de Wordpress, il semble tout naturel de télécharger une image depuis le web ou à partir de son poste de travail pour l’afficher où bon nous semble dans un article. C’est encore plus vrai depuis Wordpress 2.9 qui autorise quelques traitements sympathiques sur les images.

Dans Drupal, c’est comment dire… Bref, c’est pas évident. La documentation précise bien qu’il est possible d’insérer une image dans un contenu via FTP puis d’utiliser la balise HTML img, mais quelque chose me dit que ça ne va pas plaire à tout le monde. Heureusement, il existe plusieurs solutions pour y remédier (ou pas).

Module Image (Bof)

Le pitch : le module Image permet aux utilisateurs ayant les permissions adéquates d’uploader des images dans Drupal, de les afficher individuellement en page d’accueil, de les insérer dans un article ou encore de les grouper dans une galerie et de créer automatiquement des miniatures de différentes tailles.

Faites glisser Image dans le dossier modules de votre installation et activez-le dans Administrer › Construction du site › Modules puis Image. Vous remarquerez à cette occasion que Drupal installe automatiquement les fichiers de langue pour les modules qui en possèdent. Frambi-framboise sur le gâteau, le module Image crée pour nous les répertoires /sites/default/files/images et /sites/default/files/images/temp.

Malheureusement, tout ne fonctionne pas comme sur des roulettes : le tableau de bord indique que Image Import et ImageMagick advanced options ne sont pas configurés correctement. Pour le premier, le message précise que le répertoire d’import n’a pas été configuré et pour le second, qu’il n’a pas été installé correctement.

Pour spécifier le répertoire d’import, je vais donc dans Administrer › Configuration du site › Images et dans le doute j’indique/home/temporaire/upload. Pour ImageMagick je me contente de le désactiver dans Administrer › Configuration du site › Boite à outils image. En attendant de voir si tout est OK au niveau de mon hébergement je me contenterai de la librairie GD.

Bref, après toutes ces péripéties j’ai toujours bien envie d’afficher une image. Or, il semble que ce module ne fait qu’ajouter un type de contenu Image à côté des Pages et des Story. Ce qui ne correspond pas vraiment à mes besoins (Je n’exclus pas, bien évidemment, le fait d’être passé à côté de quelque chose d’essentiel). Mais au moins avons-nous déjà la possibilité d’uploader des images dans Drupal, ce qui n’est pas rien ;)

ImageField (Bof)

Dépendant des modules CCK et FileField, ImageField fournit un uploader dans la lignée du module Image vu plus haut. Des modules complémentaires permettent de générer des miniatures, de saisir des méta-données en plus des traditionnels alt et title, de recadrer les images ou encore de télécharger des images par lot.

Une fois que vous aurez copié ces modules, vous vous apercevrez que CCK est un gros morceau : il bénéficie d’un menu pour ses dépendances dans la liste des modules. Ne sachant pas encore de quoi j’aurais exactement besoin, j’ai tout coché. Mais impossible d’activer le module FileField à cause de l’absence du module getID3 (gestions des informations contenus dans les fichiers audios). Dans le doute, je l’installe. Un message d’erreur m’avertit que je n’ai pas installé la bibliothèque getID3 dans le dossier sites/all/libraries/getid3/.

Mais nous ne somme pas au bout de nos peines car à la lecture de la documentation de ImageField, il semble nécessaire d’installer les modules ImageCache et ImageAPI qui n’était nécessaire que pour la version 5.x de Drupal…

Une fois ImageCache installé, mis à jour et assimilé dans les grandes lignes (les plus pressés regarderont directement la vidéo Maintainable Image Gallery), vous pourrez vous rendre sur Administrer › Construction du site › ImageCache pour voir les possibilités du module. J’ai également installé le module Views qui de toutes façons fait partie des incontournables de Drupal (pendant que vous y êtes, installez également le module d’aide avancé pour Views).

Une fois que vous aurez terminé le tutoriel Imagefield – how to set up and make a basic view vous aurez plus ou moins la même chose qu’avec le module Image présenté plus haut…

Lire Préparer Drupal pour la manipulation d’images.

IMCE (Yeah!)

Le module IMCE permet d’uploader des fichiers et des images avec la gestion des répertoires distants en prime. Le tout compatible avec FCKeditor, TinyMCE et WYMEditor. Pour éviter certaines incompatibilités entre les éditeurs et/ou certains modules, il est préférable de passer par le module IMCE Wysiwyg bridge qui facilite l’intégration du module IMCE dans les éditeurs visuels TinyMCE et FCKeditor pour le moment.

Pour éviter de tout mélanger, je vous conseille de désactiver le module Image installé précédemment et d’installer IMCE et IMCE Wysiwyg bridge puis de jeter un oeil sur les options de IMCE dans Administrer › Configuration du site › IMCE.

Pour accéder à ce qui nous intéresse, une dernière étape est nécessaire : cocher la case IMCE dans la liste des boutons et plugins de l’éditeur visuel TinyMCE dans Administrer › Configuration du site › Wysiwyg !

Faites la même chose pour FCKeditor pendant que vous y êtes, histoire de passer rapidement d’un éditeur visuel à l’autre. L’idéal étant de créer deux nouveaux formats d’entrée en plus de Filtered HTML et de Full HTML pour leur associer nos deux éditeurs visuels nouvellement installés.

Le résultat de nos manipulations prend la forme d’une icône Browse ou d’un bouton Parcourir le Serveur juste à droite du champs URL de l’image (quand on a cliqué sur l’icône Insérer/modifier l’image). Un clic sur ce bouton affiche enfin la boite de dialogue qui permet d’uploader, de générer les miniatures et d’envoyer le tout à l’éditeur qui se chargera d’afficher l’image dans l’article, enfin !

Notez que le module IMCE est également disponible pour le module CKeditor.

Ca ne marche toujours pas ?

Que l’image s’affiche correctement dans l’éditeur ne signifie pas qu’elle s’affichera dans votre article une fois publié… La raison est que même si vous spécifiez un éditeur visuel comme FCKeditor, le comportement par défaut est de filtrer les balises HTML à la manière de Filtered HTML. Pour y remédier, rendez-vous dans Administrer › Configuration du site › Formats d’entrée et décochez la case filtre HTML.

Drupal 7 (Yeah?)

La prochaine version de Drupal devrait gérer nativement les images avec des champs Image pouvant être ajoutés aux contenus et auxquels peuvent être attachés des effets tels que le redimensionnement, le recadrage, etc. Cette version est actuellement en Alpha1.

Notes : cette prochaine mouture de Drupal marquera un tournant dans l’ergonomie du CMS qui devrait avoir été amélioré de manière significative par rapport à la version 6.15 que je teste actuellement.

En attendant la suite des tribulations d’un Wordpressien en Drupalie…

Malgré la longueur de ce billet, l’installation de Drupal est moins compliquée qu’il n’y parait. Les problèmes que j’ai rencontrés vous seront sans doute épargnés. L’installation des différents modules prend du temps et de nombreux aller-retours sont nécessaires pour installer, activer ou modifier les paramètres.

Les critiques concernant l’ergonomie perfectible de Drupal (qui va être radicalement modifiée avec l’arrivée de la version 7) sont sans doute un moindre mal au regard des possibilités. Et puis, entre nous, si vous trouvez que Drupal est trop riche, c’est peut-être que Wordpress ou votre CMS préféré suffit à votre bonheur ^_^

Toutefois, la saisie et la mise en forme de textes et d’images sont le coeur et la raison d’être de tout CMS et l’absence d’un éditeur visuel intégrant images, son, vidéos, etc. se fait cruellement sentir. D’autant plus que les solutions proposées par la communauté Drupal n’offrent pas le même confort d’utilisation que ce qu’on trouve dans Wordpress 2.9 où le module d’upload et d’édition d’image est une petite merveille. Mais la version 7 pointe son nez et tout ces inconvénients ne seront sans doute qu’un mauvais souvenir ;)

Quelques liens

• Drupalfr
• Kolossaldrupal
• Biboo
• Drupalistic
• Learn By The Drop

BBComposer et Wordpress

Dans Wordpress, par exemple, il suffit de passer l’éditeur de texte en mode HTML (au lieu du mode Visuel) et de cliquer avec le bouton droit de la souris pour sélectionner BBComposer et choisir le langage de votre choix (XHTML 1.0, par exemple). Il ne reste plus qu’à saisir votre texte et à l’enrichir avec les balises appropriées.

Une fois le langage sélectionné, la zone d’édition de BBComposer apparait. Comme vous pouvez le constater les options sont nombreuses.

La fenêtre d'édition de BBComposer et la barre latérale pour utiliser des styles CSS en ligne. Cliquez pour agrandir l'image.

Des « super blocs » et des listes de définition

La plupart des éditeurs présents sur le marché se contentent de créer des balises de manière linéaire. BBComposer se distingue encore en permettant la création de super blocs avec les balises blockquote et div.

A propos de blockquote, la plupart des éditeurs ont oublié qu’une deuxième balise de type block était nécessaire comme :

<blockquote>
    <p>La citation</p>
</blockquote>

Des styles pour avoir la classe

Grosse cerise sur le gâteau, il est possible d’ajouter une ou plusieurs classes CSS sur chaque élément, y compris sur un super bloc div. Ceci peut être très intéressant lors de la rédaction d’articles de type magazine pour obtenir une mise en forme différente selon le sujet sans passer systématiquement par le mode HTML pour saisir les balises.

Je pense notamment à la possibilité d’ajouter une classe wrapper ou clearfix à un super bloc pour rétablir le flux après avoir mis des éléments en float: left ou float: right à supposer que vous ayez déjà une classe .float-left et .float-right à votre disposition dans votre fichier style.css.

Des styles en ligne à profusion

Avantage ou inconvénient, une barre latérale propose une foultitude d’option de formatage qui se traduisent par l’insertion de styles en ligne comme <p style="text-align: center;">blabla</p>.

Petite digression…

Même si je trouve que les styles en ligne, c’est pas bien dans le cadre du développement d’un site web (au niveau de l’architecture des pages), je trouve que BBComposer offre une solution simple pour permettre aux clients qui le souhaitent d’enrichir leurs textes. Bien sûr, c’est la porte ouverte à toutes les fenêtres et le risque est grand de voir une typo différente par ligne et 4 couleurs dans le même paragraphe… ;)

… Revenons à nos moutons !

Outre le formatage du texte, la palette des styles propose de définir ou modifier les propriétés margin et padding ainsi que l’arrière-plan, la position absolute ou encore float avec les options clear nécessaires pour rétablir le flux après les éléments flottants.

Documentation

Un des point-clés d’une application se trouve dans sa documentation. A cet égard, BBComposer nous gâte :

• Vidéo de présentation,
• Page pour l’installation,
• Manuel de l’utilisateur.

Une application extensible

BBComposer est extensible. Parmi les extensions disponibles, je vous encourage à tester l’extracteur sémantique de mots-clés KGen :

KGen est un générateur de mots-clés qui permet d’analyser les mots contenus dans une page et de déterminer ceux qui, pour les moteurs de recherche, auront le plus d’importance.

Voici une vidéo de présentation.

Pour Conclure

Je suis loin d’avoir fait le tour de BBComposer et sa richesse demande un peu d’adaptation, mais le confort procuré par les super blocs et la possibilité d’attribuer une classe à n’importe quel élément valent le détour.

La nature de BBComposer lui permettra de trouver sa place dans votre boite à outil puisqu’il ne vous obligera pas à supprimer votre éditeur préféré. Vous pourrez même le proposer à vos lecteurs qui pourront ainsi enrichir leurs commentaires (à supposer que votre CMS autorise l’utilisation des balises HTML ou BBCode dans cette zone).

Les utilisateurs de Wordpress pourront sans peine l’utiliser dans la zone d’édition des billets pour palier les manques de l’éditeur TinyMCE installé par défaut, notamment l’absence de la balise code, bien pratique lorsqu’on a l’occasion de parler des langages du web !

J’avais déjà un doute en regardant l’organisation des différents fichiers composant le thème : sous prétexte de généricité, on trouve des appels de fonctions pour tout et n’importe quoi. Comme je n’aime pas vraiment construire sur des fondations douteuses (ou que je maitrise mal), je suis parti d’une page blanche en ce qui concerne le marquage HTML et le fichier functions.php. Pour les CSS, je me suis laissé tenté par Boks pour le calcul de la grille de mise en page.

Dans la foulée, j’ai modifié la structure de mes permaliens, supprimé le répertoire /blog, et je suis allé prévenir Google de toutes ces modifications via Google Webmaster Tools.

WTF! (Wordpress Theme Framework)

Amélioration notable des performances : les pages se chargent beaucoup plus rapidement.

Quelle ne fut pas ma surprise en voyant que les pages de mon site se chargeaient en 5 à 10 secondes avant le changement de thème pour passer à moins de 2 secondes ensuite, alors que j’ai ajouté des miniatures au début des billets en page d’accueil et des visuels de manière plus systématique dans les articles !

Statistiques de l’exploration

Voici quelques captures d’écran de la page Diagnostic de Google Webmaster Tools concernant les 90 derniers jours qui englobent les données récoltées avec le thème Thematic (jusqu’à mi-novembre) et le nouveau thème pour la suite. L’absence de données autour du 11 novembre s’explique aisément : j’ai oublié d’insérer le script Google Analytics dans mon thème sur cette période ^_^v

Hasard du calendrier ou relation de cause à effet, le volume global des pages explorées augmente à partir de mi-novembre.

Nombre de pages explorées par jour

Mettez votre blog au régime parce qu’il le vaut bien ;)

Nombre de Kilo-octets téléchargés par jour.

Désengorgez le réseau avec des pages profilées comme des fusés !

Temps de téléchargement d'une page en millisecondes.

Le temps, c’est de l’ergonomie

Qu’il s’agisse d’optimiser ses fichiers CSS, sa base de données, ses fichiers HTML ou Javascript, les performances web ont fait couler beaucoup de pixels en 2009 et nul doute que ça continuera en 2010.

L’ami Google, toujours prompt à encourager chez les autres les pratiques qui vont dans le sens de ses affaires, envisage de prendre en compte le temps de chargement pour le classement d’une page web dans les SERP’s.

Or, le choix d’un thème pour Wordpress se limite souvent au nombre de colonnes ou à des éléments bassement matériel comme la couleur du fond ou la présence de coins arrondis ^^

J’espère que ce billet vous donnera envie d’améliorer les performances de votre site ou de votre blog pour offrir une meilleure expérience de navigation à vos lecteurs, parce qu’ils le valent bien !

Les Widgets présents dans Wordpress sont bien pratiques et j’en fait un usage relativement intensif.

Cliquez pour agrandir l'image.

Après avoir vérifié la correspondance entre les intitulés des zones du fichier functions.php et les zones de Widgets déclarées dans les fichiers du thème, j’en suis arrivé à la conclusion que Wordpress n’appréciait tout simplement pas mes intitulés ou plus précisément la présence du tiret (-) précédent un chiffre. Mon problème semble réglé en utilisant header1, header2 et sidebar1 et sidebar2.

Notez que ce problème n’est pas propre à la version 2.9 et existait avec la version 2.8.6. Si de votre côté vous avez l’occasion de tester ce comportement, faites-le moi savoir pour voir si ça vaut le coup de remonter ce supposé bug.

Merci d’avance. J’en profite pour vous souhaiter de Joyeuses fêtes de fin d’année \o/

Voici le code à ajouter dans votre template Wordpress si vous voulez afficher ou masquer la grille en production. Si vous travaillez en local (ou si vous n’utilisez pas Wordpress), supprimez le code PHP :

<?php if ( is_user_logged_in() ) : ?>
    <a id="displayGrid" href="#displayGrid">Afficher/masquer la grille</a>
<?php endif; ?>

// Affichage de la grille si connecte
$("#displayGrid").click(function() {
    $("html").toggleClass("display-grid");
});

.display-grid #container {
    background: url(pix/grid.png);
}

#displayGrid {
    position: fixed;
}

Mise en page alternative

Avec un peu d’astuce et d’espièglerie vous trouverez rapidement de nombreuses applications à cette astuce. Je pense notamment à la possibilité de proposer une mise en page CSS alternative aux visiteurs.

Grille de mise en page

La grille de mise en page est divisée en 16 colonnes de 42 pixels séparées par une gouttière de 18 pixels pour une largeur de 942 pixels

Ces proportions ont un rapport avec le fait que 42 — comme chacun sait – est la réponse à toutes les questions ;) Je voulais surtout sortir des sentiers battus, c’est-à-dire des designs en 960 ou 950 pixels que l’on trouve généralement dans les frameworks CSS. S’il suffisait de tomber sur des dizaines entières pour avoir des proportions harmonieuses, ça se saurait ! En matière de web design, quelques pixels de plus ou de moins peuvent faire la différence.

Grille horizontale ou verticale ?

Établir une grille verticale n’est pas difficile en soi : il suffit de s’assurer que les valeurs de line-height, de padding et de margin top et bottom, etc. soient des multiples de l’interlignage de base. Dans mon cas, la taille par défaut est de 14px pour le corps du texte et 1.5em pour l’interlignage, soit 21px de hauteur de ligne. Facile, d’autant plus que la plupart des frameworks CSS possède une section typography qui fait presque tout le le travail…

Le problème, c’est que si je trouve que l’alignement des blocs sur une grille horizontale est harmonieux, je suis rarement satisfait par la verticale. Non pas que globalement l’harmonie n’y est pas, mais lorsqu’on se met à lire une page web au lieu de la regarder, il y a souvent des espaces à revoir. Par ailleurs, je n’ai pas envie de m’assurer que la hauteur de mes images est elle aussi un multiple de ma grille verticale…

16 colonnes à la une ?

Ce n’est pas tout d’avoir 16 colonnes à disposition, encore faut-il organiser le contenu dans le respect de l’ergonomie et de la lisibilité globale et résister à la tentation d’utiliser toutes les combinaisons permises par la grille. Tout comme il ne faut pas multiplier le nombre de polices de caractère, il ne faut pas trop disperser l’attention du lecteur.

La page d’accueil

Une grille,  c’est bien à condition qu’on ne voit pas qu’elle ! Pour cela, j’ai divisé le header en 4 blocs de largeurs inégales tout en faisant en sorte que le point d’équilibre se situe au mileu de la page.

Des blocs inégaux, mais équilibrés

A la une

Ensuite, un article mis en avant occupe toute la largeur disponible tout en étant lui-même découpé en deux blocs de 8 colonnes chacun. Un pour le résumé de l’article et un pour le visuel qui l’accompagne.

Les champs personnalisés (custom fields) en ont encore sous le pied

Cliquez sur l'image pour l'agrandir

Ce dernier est ajouté via les champs personnalisés. Ils ont mauvaise presse depuis quelques temps mais sont d’une efficacité redoutable lorsqu’il s’agit d’ajouter plusieurs éléments en rapport avec l’article comme c’est le cas ici avec le visuel et sa légende, avec la possibilité d’avoir des éléments par défaut. Le tout est de ne pas en abuser.

Les miniatures

En revanche, l’affichage de la miniature qui flotte au début des résumés des articles est confié à l’excellent get_post_images() proposé par Mehdi Kabab. Ce script est composé d’un jeu de fonctions à mettre dans functions.php. A noter que  timthumb est prêt à être utilisé pour redimensionner les images afin d’alléger la page. A ce propos, je regarderais plus tard ce que Wordpress 2.9 à dans le ventre en matière de miniatures.

Les billets et la sidebar

Sur la page d’accueil, les billets et la navigation alternative sont à égalité

Cliquez pour agrandir l'image.

J’ai ensuite centré les éléments sur deux blocs principaux occupant 8 colonnes chacun en page d’accueil : un bloc pour l’affichage du résumé des articles et un autre pour la barre latérale qui se divise encore en deux à la fin pour accueillir des contenus de faible largeur, comme les listes de lien, par exemple.

Le footer

Pour le pied de page, je suis parti sur un découpage en 4 colonnes occupant toute la largeur pour rompre avec la monotonie (parfois nécessaire pour une lecture tranquille) et relancer l’attention. C’est peut-être subjectif mais je trouve qu’un découpage en 4 colonnes pour le footer donne un ancrage à la page dans son ensemble. D’autres informations suivent sur la largeur de la page ou la moitié, comme le colophon par exemple.

Un footer en 4 colonnes pour asseoir la page avec un retour de flamme pour inciter à poursuivre la lecture. vers le haut.

La page des articles

Lorsqu’on se trouve dans la page affichant l’article seul, l’article mis en avant disparait ; les proportions changent pour améliorer la lisibilité du billet : 11 colonnes pour le texte et 5 colonnes pour la barre latérale.

Intégration de la grille

Pour rebondir encore un peu sur les questions récurrentes concernant l’utilité d’un framework CSS lors de la phase d’intégration HTML & CSS, je rappelle qu’il est tout à fait possible de travailler avec une grille pour le placement des différents blocs sans pour autant utiliser un framework, comme je le suggère dans Framework CSS sémantique ? Comment je vois les choses.

C’est d’ailleurs ce que j’ai fait ici. Au lieu d’utiliser Blueprint et son fichier grid.css pour caler les blocs sur la grille de base, j’ai opté pour Boilerplate créé par l’un des concepteurs de Blueprint qui propose — mieux qu’un framework — un redesign CSS global ! A charge pour l’intégrateur web d’ajouter les règles CSS de son choix pour que la page web suive la maquette !

Et HTML5, il pue du bec ?

Lorsque j’ai commencé à travailler sur Illustrator, j’avais en tête de réaliser l’intégration en utilisant au maximum les nouvelles balises proposées par HTML5. Comme vous pouvez le voir, à l’exception du Doctype et d’une balise time qui doit trainer quelque part, je suis resté au bon vieux XHML 1.0 ou XHML5 si vous préférez. Les raisons sont à la fois triviales et complexes :

• Triviales — malgré ce que j’ai lu — et écris sur ce blog également — sur le fonctionnement du script html5shiv pour qu’Internet Explorer reconnaisse les nouvelles balises, le résultat est parfois aléatoire. Dans mon cas, les problèmes de mise en page rencontrés sur IE8 disparaissaient en basculant sur le mode compatibilité avec IE7… Un comble, qui a suffit pour que j’envoie balader toutes les balises sémantiques.

• Complexes — en parlant de sémantique, je me suis bien pris la tête avec ses histoires de header, footer, nav et aside. Sur le papier, c’est assez simple. En revanche, je me suis heurté à des problèmes d’interprétation in real life.

En effet, les balises header et footer ne concernent pas uniquement l’en-tête et le pied du document HTML. Ainsi, au sein d’un article, on peut regrouper le titre et le nom de l’auteur dans une balise header et réserver une balise footer pour les meta-informations comme la date de publication, les tags ou les catégories.

Pour compliquer encore un peu les choses, si l’envie vous prend de mettre une date juste en dessous du titre de l’article, vous pourrez également utiliser un balise footer quand bien même elle serait placée juste en dessous du header de l’article et au-dessus du texte du billet. Et oui, puisque on vous dit que c’est sémantique et que ça n’a rien à voir avec la position ou l’apparence des éléments !

Pour faire court, au bout d’un moment, pour ne pas différer encore la mise en ligne du nouveau thème et prendre le temps de la réflexion pour apprendre les bonnes manières pour baliser correctement un document en HTML5, j’ai repris quelques cuillères à soupe de div !

Peu d’éléments graphiques

Un logo en flamme ?

C’est un logo en flamme, on étudie notre stratégie internet.

So 1997, non ? Pour ceux qui s’en souviennent, il s’agit d’un clin d’oeil concernant une publicité pour les solutions internet d’IBM (voir le pitch). La flamme est un des rares éléments graphiques présent dans le design. L’idée est de laisser le champ libre pour le contenu qui contiendra du texte, des images et des mises en exergues de texte, ce qui sera largement suffisant pour détourner l’attention des plus distraits ;)

Une autre flamme couchée sur le côté répond à la première dans le footer en direction des éléments de copyright et dans un mouvement circulaire pour diriger l’oeil du lecteur vers la partie Miscéllanées.

Les articles sont le nerf de la guerre

Laisser parler le contenu et laissez-lui une chance de se transformer en message

La raison de cette relative pauvreté dans les visuels de la maquette, c’est que je compte travailler graphiquement certains articles pour accentuer le style magazine du blog. Il s’agit de soigner le traitement éditorial et visuel des textes plutôt que multiplier les accroches, les visuels imposants, voire les fils d’information en continu en page d’accueil ! En matière de mise en page, comme dans beaucoup d’autres, il faut laisser parler le contenu pour lui laisser une chance de se transformer en message.

Améliorer les performances globales

Même si les performances web sortent du cadre de cet article, il est intéressant de noter que depuis quelques temps Google met la pression sur tous les fronts concernant les questions liées à la rapidité d’affichage des sites web. De l’amélioration des protocoles réseaux existants, à la mise en place d’outils d’évaluation du temps de chargement des pages, Google devrait intégrer ces données dans son algorithme pour favoriser les pages répondant plus rapidement aux attentes des utilisateurs. Le chemin du designer web est tracé et l’intégrateur doit suivre le mouvement (ou le contraire).

Une des clés pour améliorer les performances se trouve dans la charte graphique

A cet égard, une visite récente sur Google Webmaster Tools m’indiquait un temps moyen de chargement de 4.2 secondes par page avec le thème Wordpress Hybrid. (thème minimaliste sans aucune image que j’avais laissé tel quel en attendant). La surprise est venue aujourd’hui, avec un temps moyen de chargement divisé par deux depuis l’installation du thème actuel ! Sans compter la marge de progression : si j’ai commencé à réunir les fichiers CSS dans style.css et il reste la même chose à faire avec les fichiers Javascript.

Application de la grille pour les images des articles

Cette fois, j’ai essayé d’utiliser les outils proposés par Wordpress pour l’affichage des légendes des images. Voici tout d’abord un exemple d’une image accompagnée d’une légende à laquelle j’ai ajouté un hors-texte sous la forme d’une balise d’en-tête de niveau 6 (h6) qui flotte à droite de l’ensemble composé par l’image et sa légende (ou tout simplement du texte comme je l’ai utilisé plus haut). Il est aussi possible de faire flotter ce hors-texte à côté d’une  image qui ne serait pas accompagné d’une légende.

Parmi les contraintes qui s’imposent lors d’un redesign (6 ou 7 de mémoire sur ce blog en plus de 3 ans), l’historique de la base d’articles existants et les différentes tailles d’images qui les composent n’est pas à négliger. Pas question que les anciens articles voient leur mise en page partir en sucette ! Ce qui est certainement le cas pour certains d’entre eux ; des interventions manuelles seront nécessaires pendant un certain temps… No pain, no gain!

C’est tout pour le moment

Il reste encore beaucoup à dire sur la mise en place du thème. Comme je viens d’installer la beta 2 de Wordpress 2.9, je vais laisser passer un peu de temps pour découvrir les nouvelles fonctionnalités avant de les introduire dans le thème.

Je reviendrais vers vous pour une deuxième partie de cet article qui est déjà bien assez long (je m’étais promis de faire court) où j’aborderais les aspects plus techniques comme les boucles Wordpress que j’ai utilisées, etc.

N’hésitez pas à intervenir dans les commentaires pour me signaler les éventuels dysfonctionnements qui auraient échappés à ma vigilance ou simplement me dire tout le mal que vous pensez de ma nouvelle charte graphique ;)

Stay tuned and mind the gap!

• The Ultimate Wordpress Developer Toolbox — Wordpress est un CMS formidable grâce à l’immense communauté qui n’a de cesse de partager le savoir autour de la plate-forme. Mon coup de coeur de la semaine revient à tripwiremagazine dont je vous recommande le flux RSS pour ne rien rater.

  Pour en revenir cettte boite à outils ultime pour les développeurs Wordpress, vous y trouverez des plugins pour formater le code de vos exemples, d’autres permettant de parser du code PHP au sein même des articles (runPHP, EzStatic3 ou PhpExec) , des ressources pour créer des thèmes Wordpress, comment afficher des champs personnalisés (Custom fields) à l’extérieur de The Loop ou bien n’afficher que les billets avec un champs personnalisé spécifique, et bien plus encore.

• WP Smart Image — L’affichage d’une miniature tirée des illustrations d’un billet est indispensable pour tous thème magazine qui se respecte. Si les champs personnalisés (Custom Fields) ne vous conviennent pas, tournez-vous vers ce plugin très complet qui permet même de choisir l’image en question (si vous cocher la case Activate editor box dans les options du plugin. via Geekeries

  Que cela ne vous empêche pas de jeter un oeil sur Récupération avancée des images d’un article pour tester la fonction wp-get_post_images() que j’utilise actuellement sur ce blog.

• File Browser — Cet explorateur de fichiers remplacera occasionnellement votre client FTP et votre éditeur de texte préféré. Via Geekeries.

• Serve Default to IE6 — A l’heure où l’on remet de plus en plus en question le support de IE6 dans le webdesign, Nathan Rice propose une solution simple et élégante : afficher le thème par défaut si le visiteur utilise Internet Explorer 6 épicétou !. Incompatible avec WP-Super-Cache.

• Multiple Loops and Multiple Columns — Le billet détaille le nécessaire pour que la première boucle affiche les billets de 1 à 5, la deuxième, ceux de 6 à 10 et la dernière ceux de 11 à 15. Chaque boucle (Loop) dans sa colonne, le code HTML et CSS pour mettre en page les colonne en prime ! Profitez-en pour lire Triple Loop for WordPress.

• Liens et astuces pour développer vos plugins Wordpress — Avec toutes ces vidéos, ces liens, ces slides, etc. la création de plugins ne devrait plus avoir de secret pour vous si vous connaissez PHP !

• Bien construire ses plugins Wordpress — Tout dans le code de Wordpress est là pour faciliter la création de plugins, ce qui ne garantit pas leur qualité. En effet, de nombreux plugin semblent codés avec les pieds : manque de sécurité, ergonomie douteuse, etc. Cette vidéo présentée par Will Noris fait le point sur les bonnes pratiques de développement pour avoir des plugins performants, sûrs et évolutifs.

• Broken Link Checker — Une fois installé, ce plugin parcours vos billets à la recherche de liens brisés. En option, vous pouvez appliquer une déclaration CSS pour les distinguer en attendant d’éventuelles corrections ultérieures. A titre d’information, ce blog comporte pas moins de 264 liens brisés sur un total de 3 755 liens uniques sur l’ensemble des 344 billets rédigés depuis plus de 3 ans et 2 mois. Via Christophe Logiste.

• Guide de référence des Templates tag pour Wordpress — Ce guide réunit les appels de fonctions avec leurs paramètres sous une forme plus synthétique que le Codex. Note : le lien date un peu (bookmarké en novembre 2008).

• Wavr — Les heureux possesseurs d’un accès Google Wave pourront embarquer une wave dans un billet avec le Shortcode [wave id="wave-id"]. Encore en bêta, le but de ce plugin est d’implémenter toute l’API Google Wave afin de l’utiliser dans Wordpress. Un bouton pour TinyMCE est disponible pour intégrer vos Waves. Via Descary.