Seulement voilà, parfois, on a besoin de personnaliser un peu ce code HTML. Par exemple, moi, j’avais besoin d’ajouter une classe sur les liens, ce qui n’a pas été prévu par WordPress. Qu’à cela ne tienne, me direz-vous, il suffit de réécrire la fonction ! Pas si simple, car celle-ci utilise un système très efficace mais relativement compliqué appelé Walker (que vous trouverez dans le fichier wp-includes/classes.php). Et croyez-moi, vous n’avez pas envie de réécrire tout ça !

Le léger hack suivant va permettre de nous en sortir facilement.

Tout d’abord, il faut repérer la classe qui génère le contenu HTML. Dans le cas de la fonction wp_list_pages(), il s’agit de la classe Walker_Page (qui se trouve aussi dans le fichier précédemment cité). Copiez la dans votre plugin ou dans le fichier functions.php de votre thème, en prenant soin d’en modifier le nom. Par exemple :

class Walker_Page_modified extends Walker { ... }

Profitez en pour adapter le code HTML à vos besoins. Maintenant, voyons comment dire à WordPress d’utiliser votre classe personnalisée. Tout se passe dans les paramètres de la fonction wp_list_pages() :

wp_list_pages(  array( 'walker' => new Walker_Page_modified() )  );

Et voilà, c’est aussi simple que ça ! Vous avez réussi à plier WordPress à vos besoins, et non le contraire.

Similarités avec la concurrence

Buzz est une sorte d’hybride de ses principaux concurrents, il a su en tirer le meilleur.

Comme Twitter :

• le système de following/followers : on peut se connecter à des flux buzz sans réciprocité (contrairement à Facebook),
• on peut s’adresser directement à quelqu’un en utilisant la syntaxe @nomducompte,
• le flux d’activité est public par défaut.

Comme Facebook :

• De Facebook, Buzz a surtout retenu les possibilités d’interaction. Il est en effet possible de commenter et d’apprécier chaque buzz, ce qui facilite les conversations,
• Le nombre de caractères pour chaque buzz n’est pas limité (ça peut être considéré comme un point faible pour ceux qui apprécient la concision des tweets, mais croyez moi, c’est souvent un calvaire d’exprimer correctement sa pensée en 140 caractères…),
• Il est possible de cibler chaque buzz pour qu’il soit visible uniquement par un ou plusieurs groupes d’utilisateurs.

Innovations intéressantes

Mais Buzz est plus qu’un simple patchwork de fonctionnalités des concurrents. Son point fort, c’est l’intégration intelligente de ses autres services.

• La page de votre profil buzz est en fait votre page de profil google.
• Il est également capable de récupérer les flux de vos sites via votre compte Feedburner, si vous en avez un. Il n’est donc plus nécessaire de configurer des services externes pour publier vos articles dans votre flux d’activité : Buzz le fait pour vous.
• De la même manière, il peut intégrer vos publications publiques issues de ses services Picasa, Google Reader, Youtube…
• Inclus dans Gmail, Buzz intègre fort logiquement la possibilité de partager un buzz par email.

Sérieuses lacunes

Google Buzz a beau compiler le meilleur de ses concurrents, il a encore de sérieuses lacunes :

• pas d’option de configuration avancée : la page de profil gagnerait par exemple à être plus personnalisable, en terme de look comme de contenu.
• pas de personnalisation pour la publication des flux RSS. Actuellement, Buzz affiche entièrement les articles dans le flux, ce qui ne serait pas très dérangeant s’il n’y avait cette possibilité de commenter. Au final, les buzzeurs liront vos articles et surtout les commenteront sans jamais se rendre sur votre site, ce qui déclenchera un inévitable éparpillement des conversations.
• pas d’API pour la gestion externe des contenus. Choix délibéré ou simple carence de jeunesse ? Probablement la seconde solution, car l’API est en partie ce qui fait la force de ses concurrents Twitter et Facebook. Il serait notamment possible de récupérer les commentaires pour les centraliser et ainsi corriger l’éparpillement des conversations… MAJ : Google Buzz a bien une API en cours de développement)
• pas de fonction rebuzzing : la grande force de Twitter, c’est la possibilité (inventée par les utilisateurs) de retweeter une information, c’est à dire la publier à son tour, en mentionnant l’auteur original. L’option est absolument nécessaire pour diffuser le plus largement possible.
• pas de lien externe pour buzzer : sur de plus en plus de sites, on trouve des liens pour diffuser facilement une information sur Facebook, Twitter ou autres services. Après une rapide recherche, ce genre de lien n’a pas l’air possible avec Google Buzz.

Conclusion

Google Buzz semble un nouveau service très prometteur, comme souvent avec Google. A mi-chemin entre l’efficace simplicité de Twitter et la grande diffusion de Facebook, il pourrait rapidement devenir un outil incontournable, à condition de corriger les quelques erreurs de jeunesse qui seront, sinon, de sérieux freins à l’adoption massive du service.

PS : ne perdez pas une seconde, testez le service en vous abonnant à mes buzz à partir de mon profil public.

Cela dit, si tout se passe comme prévu, il devrait y avoir du neuf d’ici à la fin de la semaine. Je suis notamment en train de peaufiner un nouveau plugin WordPress. Après Editable Comments pour l’édition des commentaires, je m’attaque à la connexion externe (Facebook, Twitter…), dans le genre de ce que fait WP Facebook Connect, mais en mieux (en tout cas, à mes yeux, j’espère que ce sera également votre cas).

Vous pouvez d’ores et déjà le tester sur ce blog, où je viens d’activer une version alpha

Restez connectés !

Ma réponse ne tiendrait pas dans un commentaire, alors je vais le faire ici.

Qu’est-ce qu’un développeur wordpress ?

Commençons par le début : un développeur wordpress, ça n’existe pas. Wordpress est un outil, pas une technologie. Développeur wordpress est donc un raccourci maladroit signifiant : je suis développeur web spécialisé dans l’utilisation de Wordpress. Comme les raccourcis, même maladroits, ont le mérite d’être courts, je vais continuer l’article en parlant de développeur wordpress, mais gardons à l’esprit la véritable définition.

Que signifie développer pour wordpress ?

Ajouter des fonctions php issues du codex dans les fichiers d’un thème, ce n’est pas être développeur. C’est être, disons, un intégrateur aux compétences élargies, c’est à dire capable de lire une documentation et d’en tirer le code dont il a besoin.

Alors à partir de quand peut-on se dire développeur wordpress ? C’est simple : quand on crée son propre code. Là, il y a deux manières. Soit vous comblez un besoin ponctuel en créant une fonction dans le fichier prévu à cet effet dans votre dossier de thème (functions.php), soit vous répondez à un besoin plus général en créant un plugin. C’est votre cas ? Bravo, vous êtes développeur wordpress !

Passons à la seconde partie, à savoir le coup de gueule contre wordpress en général.

Wordpress, une merde bien faite

C’est vrai, wordpress n’est pas superbement codé. Il n’a pas été totalement réécrit depuis… depuis… l’a-t-il déjà été ? En conséquence de quoi, il est plein de codes dépassés. Diantre, du PHP 4 ! En dehors de ça, wordpress a quelques avantages non négligeables par rapport à des concurrents mieux codés :

• Son extensibilité : je ne connais pas de CMS aussi extensible que WordPress. Quand j’ai besoin de réaliser quelque chose que WordPress ne sait pas faire, ou fait mal à mon goût, je trouve quasiment toujours un moyen d’y parvenir sans toucher au coeur de la bête, simplement en utilisant les nombreux filtres et actions prévus pour ça.
• Son interface d’administration : comparée à certaines dont je ne citerai pas le nom cent fois maudit, l’administration de wordpress est simple, très simple. Tout en restant efficace. C’est une qualité indéniable, déterminante quand on sait que les clients finaux, pour la grande majorité, n’ont jamais utilisé d’interface d’administration auparavant. Le seul hic, c’est que cette interface est difficilement modifiable sans toucher directement aux fichiers.
• Son intégration : les thèmes pour wordpress sont très simples à créer, et les fonctions permettant d’accéder aux données sont en général bien faites ou, sinon, aisément contournables. Ce n’est pas le cas de bien des CMS…

Le meilleur compromis

Alors certes, Wordpress, par la qualité de son code, ne serait peut-être pas le premier choix d’un développeur. Mais c’est le meilleur compromis que je connaisse entre les différents intérêts du développeur, de l’intégrateur et du client final. Une merde, peut-être, mais une merde rudement efficace !

jQuery("<div>", {
 id: "foo",
    css: {
        height: "50px",
        width: "50px",
        color: "blue",
        backgroundColor: "#ccc"
    },
    click: function() {
       $(this).css("backgroundColor", "red");
    }
}).appendTo("body");

Je suis déjà fan. La liste des fonctionnalités ajoutées à jQuery 1.4 est disponible sur le site jquery14.com.

Who loses the browser wars? Developers.

“Qui perd la guerre des navigateurs ? Les développeurs.” J’ai trouvé la réflexion intéressante et sujette à discussion.

Qu’est-ce que la guerre des navigateurs ?

Petit rappel des faits. Il y a environ dix ans, après une âpre concurrence avec le navigateur Netscape, Internet Explorer est devenu LE navigateur incontournable, en suprématie totale sur le marché grâce à l’immense force de frappe de Microsoft et surtout à la forte imbrication du navigateur avec son système d’exploitation Windows.

EN 2001, Microsoft sort la version 6 d’Internet Explorer et décide d’arrêter là, stoppant net l’innovation du secteur après le K.O. de son principal concurrent. Mais en 2004 sort Firefox 1.0, un navigateur innovant (il est le premier à utiliser les onglets) créé par la fondation Mozilla à partir du code source complètement revu et corrigé de l’ancien Netscape. Face au succès de ce petit nouveau, Microsoft décide de remettre au travail son équipe de développement et sort IE7 fin 2006, provoquant par la même occasion une nouvelle course à l’innovation dans le secteur des navigateurs web.

En 2008, c’est au tour de Google. Le géant des moteurs de recherche sort Google Chrome, un navigateur simple et épuré basé sur le code source de Safari¹, le navigateur d’Apple (alors disponible uniquement sur Mac disponible pour Windows quelques mois avant Chrome). Son succès est jusqu’ici assez mitigé mais ses parts de marché pourraient augmenter considérablement, Google ayant dernièrement mis en place une campagne de publicité impressionnante (affiches dans la rue et le métro, pleines pages dans des journaux papier, encarts sur des sites web à forts trafics, etc).

La guerre des navigateurs, c’est donc cela : une course aux parts de marché, basée sur une innovation et une promotion permanente de la part des différents protagonistes.

Qui y gagne ?

Les utilisateurs, assurément. Ils sont la cible à convaincre, les concurrents mettent donc tout en place pour améliorer leur ergonomie et proposer des outils toujours plus performants.

Qui y perd ?

D’après @davidwalshblog, les développeurs. Bien. J’imagine qu’il inclut dans ce terme les intégrateurs, bien que ce soit deux métiers différents. Je comprends son point de vue, mais je ne le partage pas complètement. Pourquoi ? Une conséquence de cette guerre d’innovations est que les navigateurs proposent des fonctionnalités différentes (ou des manières différentes de les aborder) et sortent parfois du carcan des standards pour marquer leur différence. Le problème, pour un professionnel du web, c’est que ses réalisations doivent fonctionner pareillement au moins sur les supports les plus répandus. En tant qu’intégrateur (pour l’affichage) et développeur (pour les fonctionnalités dynamiques en javascript), je n’ai pas le choix : je dois vérifier mon travail sur Firefox, Internet Explorer et Chrome. Pire, comme je l’ai déjà évoqué maintes fois dans mes articles, je dois prendre en compte les différentes versions ! Car une autre conséquence de la guerre des navigateurs est une mise à jour rapide et régulière de ces logiciels. Si tout le monde utilisait un navigateur à jour, ce ne serait pas un problème. Malheureusement, c’est loin d’être le cas.

A titre d’exemple, voici un aperçu de l’équipement des lecteurs d’apperisphere.com, le mois dernier :

Vous le voyez, ça fait beaucoup de configurations différentes à prendre en compte si l’on veut que tous puissent avoir un rendu correct.  En cela, c’est exact, les développeurs et intégrateurs perdent un temps considérable à ménager la chèvre et le chou.

Un mal nécessaire pour un progrès de civilisation

Mais pour moi, cela n’est qu’un dommage collatéral ; tout travail induit forcément une certaine pénibilité, des contraintes. Ce n’est pas pour autant que nous sommes perdants. Car, au fond, qui voudrait sérieusement revenir au web d’avant Firefox ? Quel métier terne aurions-nous ! L’innovation technologique est une des données qui fait de nos métiers des métiers de passionnés. Le web est en perpétuelle évolution. Personne ne sait précisément où il va, il n’y a personne pour diriger la barque, mais tout le monde peut participer à construire son avenir.

Depuis la voiture et le téléphone, Internet est, à mes yeux, la seule évolution technologique importante induisant un véritable progrès de notre civilisation². Et la guerre des navigateurs en est une composante essentielle. Alors certes, les développeurs blasés y perdent peut-être, au final, mais les passionnés comme moi y gagnent beaucoup !

1. comme le fait fort justement remarquer Florent, il utilise en réalité le moteur de rendu de Safari, à savoir Webkit
2. en plus de l’invention du Kinder Bueno

Mon titre n’est pas tout à fait exact : le navigateur Lunascape, développé par des japonais, inclut Gecko, Webkit et Trident, qui sont les moteurs de rendu respectifs des navigateurs sus-cités. Le principe est intéressant pour les intégrateurs. Grâce à Lunascape, on peut facilement (via une unique interface) vérifier le rendu final de notre travail sur les plus importants navigateurs du marché. Le logiciel intègre d’ailleurs des outils de deboguage assez utiles. Il est également possible de l’étendre avec des modules complémentaires… enfin, si vous comprenez le Japonais, car malheureusement, le site hébergeant les plugins est accessible uniquement dans cette langue.

Bref, Lunascape pourrait devenir l’outil ultime pour les intégrateurs de tous pays… s’il gérait les versions. Car le gros problème des intégrateurs, ce n’est pas vraiment d’afficher correctement leur travail sur les différents navigateurs. Globalement, les dernières versions respectent suffisamment les standards pour que leur rendu soit similaire. Non, le gros problème, c’est que leur travail s’affiche correctement Y COMPRIS dans les versions précédentes ! C’est-à dire au moins Firefox 2, Firefox 3, IE 6 et IE7. Et là, Lunascape n’ait d’aucune utilité puisqu’il n’inclut que les dernières versions des moteurs de rendu.

Dans l’état actuel des choses, Lunascape n’est qu’une curieuse nouveauté prometteuse. Pour la production, je reste donc fidèle à IETester et à mes différentes instances de Firefox.

• “Edit comment” permet de choisir avec précision comment afficher le lien de modification mais nécessite de fastidieuses adaptations de la page comments.php du thème,
• “WP Ajax Edit Comments” est très complet et ne nécessite aucune modification de thème, malheureusement le lien de modification est généré automatiquement sans possibilité de personnalisation.

Comme on n’est jamais mieux servi que par soi-même, j’ai donc décidé de créer mon propre outil, personnalisable et accessible : le plugin Editable Comments. Vous trouverez plus d’informations sur son fonctionnement sur la page dédiée, mais sachez déjà qu’il permet de gérer l’affichage du lien grâce à l’appel d’une fonction et que le formulaire de modification est affiché soit via une fenêtre modale javascript, soit sur une page distincte. Par défaut, la fenêtre modale est activée, mais le plugin fonctionnera automatiquement en mode “page distincte” si le javascript est désactivé sur le navigateur du commentateur.

L’administration du plugin vous permet de gérer le mode d’affichage du formulaire ainsi que la durée limite pendant laquelle l’auteur d’un commentaire peut le modifier.

Voilà, on va dire que c’était mon cadeau de noël pour la communauté WordPress. Bonne utilisation !

Les relations entre graphistes web et intégrateurs ne sont pas toujours roses bien que leur travail soit totalement interdépendant. Idéalement, ces deux corps de métier devraient échanger régulièrement (et même en dehors des projets web) afin de mieux comprendre leurs préoccupations respectives et ainsi apprendre à respecter les choix et le travail de l’autre.

Cliquer ici pour voir la vidéo.

Le hic, avec un site WordPress, c’est que les différents plugins installés génèrent bien souvent leurs propres appels de fichiers externes. Résultat, on se retrouve très rapidement avec des dizaines de fichiers supplémentaires dans l’entête de nos pages.

Pour remédier à ce problème, deux solutions. La première est fastidieuse. Elle consiste à récupérer tous les fichiers ajoutés par ces plugins et à les combiner soi-même dans un fichier unique. Il faut ensuite modifier chacun de ces plugins pour annuler les appels… et c’est là que ça se gâte, car si vous mettez un jour l’un de ces plugins, il faut recommencer toute la manipulation !

La deuxième solution : utiliser le plugin External Files Optimizer, qui s’occupe de tout ça pour vous. Le principe est simple. Il analyse le résultat des fonctions wp_head() et wp_footer() pour en extraire tous les appels de fichiers css et js, puis il récupère leur contenu et le combine dans un fichier unique pour chacun des deux types. Enfin il compresse le tout via gzip pour diminuer le poids final.

Grâce à External Files Optimizer, vous optimisez de manière automatique la vitesse d’affichage de votre site WordPress. Prenez ce site par exemple. Grâce à l’outil Page Speed développé par Google, on peut très simplement analyser les performances d’une page. Sans l’optimiseur, ma page d’accueil fait appel à 59 ressources dont le transfert total représente 394,7kB. Une fois le plugin activé, elle passe à 44 ressources pour 189,2kB. Mieux non ?

Pour télécharger le plugin, rendez-vous sur la page External Files Optimizer.