Julien Appert

Link to Post : nouveautés pour la version 1.0

Julien Appert — Sat, 05 Jun 2010 07:53:43 +0000

Eh bien, cela fait un certain temps que je n’ai pas posté ici. Quasiment trois mois… Il faut dire que ces derniers mois n’ont pas été de tout repos, professionnellement parlant. Ce qui est plutôt un bon signe à vrai dire.

Bref ! Il y a quelques semaines déjà, j’ai développé une mise à jour du plugin Link To Post. Mais je ne l’avais pas encore mise sur le dépôt WordPress, ce qui est à présent chose faite.

Comme je sens que vous trépignez d’impatience, voici directement…

…Les nouveautés

1. Tout d’abord, et je commence par le moins intéressant pour vous, j’ai complètement réorganisé le code du plugin. Le résultat est beaucoup plus simple à maintenir et à traduire.

2. Ensuite, j’ai décidé de regrouper les différents éléments sur une même page. Dans l’ancienne version, vous aviez un bouton « link to post » pour les articles, et un « link to page » pour les pages. Désormais, vous aurez un seul et unique bouton « link to post » à partir duquel vous pourrez lier le type de contenu de votre choix.

3. Enfin, j’ai ajouté de nouveaux éléments à lier. En plus des articles et des pages, vous pouvez désormais faire des liens vers des catégories et des mot-clés. Cerise sur le gâteau, la configuration du plugin vous permet de définir quel onglet vous voulez ouvrir par défaut.

Dans le futur

A terme, j’envisage un peu plus de flexibilité pour ce plugin WordPress :

1. Vous pourrez choisir les onglets à afficher. Si vous voulez lier uniquement des pages, vous pourrez afficher l’onglet des pages et cacher les autres.

2. Surtout, le plus gros du travail consistera à vous permettre de définir vous-même un type de contenu à lier. Etant donné que la version 3.0 de WordPress permettra de créer plus facilement de nouveaux types de contenu, cette évolution du plugin me semble nécessaire. Mais… ça va demander un peu de travail, donc du temps. Ne vous attendez pas à ce que ça arrive la semaine prochaine !

En attendant, profitez bien de cette nouvelle version, et comme d’habitude, n’hésitez pas à faire remonter les bogues. Je tâcherais de les corriger le plus rapidement possible.

Link To Post 1.0

Ne communiquez pas sur les plugins installés

Julien Appert — Thu, 11 Mar 2010 20:54:40 +0000

Juste un court article en réaction au dernier billet de Thierry Roget, où il mentionne les plugins WordPress installés sur son blog. Pour ma part, j’aurais plutôt tendance à conseiller de ne pas communiquer à ce sujet. Pourtant, en tant que développeur de plugins, je dois bien vous l’avouer, j’apprécie quand un blogueur évoque un de mes bébés.

Alors pourquoi ce conseil qui va à l’encontre de mes intérêts ? Simplement pour que votre site ne soit pas piraté. Si WordPress corrige régulièrement ses failles, ce n’est pas forcément le cas de tous les développeurs de plugins. Nombre d’entre eux codent en dépit du bon sens et une bonne partie n’effectue plus de mise à jour depuis des années. Communiquer sur les plugins installés sur votre blog, c’est dire haut et fort à tous les hackers de la Terre : « vous voyez ce plugin plein de trous de sécurité ? Je l’ai installé, alors faites-vous plaisir surtout ! »

Voilà qui est dit. Mais surtout, que ça ne vous empêche pas de faire un petit billet de temps en temps sur les incroyables plugins que je mets à votre disposition .

Optimiser WordPress, encore, toujours…

Julien Appert — Thu, 11 Mar 2010 11:19:49 +0000

J’ai déjà évoqué la question ici, il existe de nombreux moyens pour optimiser votre installation WordPress et, ainsi, gagner en performances. Aujourd’hui, je vais partager avec vous deux astuces, la première concernant votre base de données, et la seconde, moins essentielle, à propos de la sauvegarde des articles.

Voir et analyser les requêtes effectuées

Pour afficher une page, WordPress doit effectuer un certain nombre de requêtes dans la base de données. Une partie de celles-ci est générée par WordPress lui-même, mais le thème utilisé va jouer un rôle important, c’est pourquoi il est recommandé de remplacer certains appels de fonction par des données en dur. Par exemple, remplacer par http://monsite.com.

L’astuce que je vais vous donner vous permettra de voir précisément les requêtes effectuées pour chacune de vos pages. Ouvrez votre fichier wp-config.php et ajoutez-y le code suivant :

define('SAVEQUERIES', true);

A partir de maintenant, toutes les requêtes seront sauvegardées dans une variable, ce qui aura une influence négative sur les performances. Aussi, activez cette ligne uniquement pour l’analyse, ne la gardez pas en permanence.

Maintenant, ouvrez le footer.php de votre thème et ajoutez les lignes suivantes avant la fermeture du :

";
 print_r($wpdb->queries);
 echo "

"; } ?>

Une fois connecté en tant qu’administrateur, ce code affichera en bas de vos pages un tableau dont chacune des entrées détaillera : la requête exacte, le temps qu’elle a pris et l’arborescence des fonctions ayant provoqué cet appel. Testé ici-même, le code m’indique 28 requêtes pour la page d’accueil, et 42 pour un article¹. Ce qui est probablement perfectible…

Se passer des sauvegardes automatiques

Nous avons vu dans mon précédent article sur l’optimisation qu’il était possible de désactiver les révisions (point 6). Mais WordPress continue à effectuer des sauvegardes automatiques de vos articles en cours de rédaction. C’est très pratique, sauf lorsque vous créez du contenu en masse. Par exemple, dernièrement, il m’a fallu créer une arborescence d’une vingtaine de pages. La mécanique est simple et rapide : ajout du titre, choix de la page parent, et hop, j’enregistre. Sauf que ce dernier point est ralenti à cause de la sauvegarde automatique : je dois attendre la fin de son exécution pour publier. Frustrant, à la longue.

Pour ne plus avoir à affronter ce problème, deux solutions :

1. Modifier l’intervalle de sauvegarde automatique. Toujours dans le wp-config.php, ajoutez le code suivant :

define( 'AUTOSAVE_INTERVAL', 60 );

Avec de la chance, vous aurez le temps de créer votre page et de l’enregistrer avant qu’une sauvegarde auto soit lancée.

2. Désactiver totalement la sauvegarde automatique. Là, il va falloir créer un plugin tout simple. Créez un fichier dans votre dossier plugins, nommez le, par exemple, disable-autosave.php, et insérez le contenu suivant :

Grâce à ce plugin, le fichier javascript qui gère la sauvegarde auto ne sera plus appelé : vous en êtes libéré !

42… La réponse ultime à la grande question sur la vie, l’univers et le reste

Redéfinir les listes HTML générées par WordPress

Julien Appert — Fri, 19 Feb 2010 12:26:21 +0000

WordPress dispose de fonctions très pratiques pour afficher le contenu. Pour afficher la liste des pages disponibles de manière hiérarchique, il suffit d’utiliser la fonction wp_list_pages(), qui va générer toute seule le code HTML nécessaire, avec les listes imbriquées.

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.

Google Buzz, un produit hybride, prometteur mais encore lacunaire

Julien Appert — Thu, 11 Feb 2010 12:43:33 +0000

Avec son Google Buzz, Google cède à la mode des statuts et s’attaque directement au fond de commerce de Twitter et Facebook. En intégrant directement son service dans l’interface de Gmail, il commence de fait avec un potentiel énorme d’utilisateurs, à savoir tous les utilisateurs actuels du webmail. Voilà qui devrait faire de Google Buzz un produit moins élitiste que Twitter, et donc très utile pour la promotion de vos sites web…

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.

Bientôt du neuf dans mes plugins WordPress

Julien Appert — Mon, 08 Feb 2010 17:23:57 +0000

Pas beaucoup d’articles, en ce moment, sur le blog. Il faut dire que j’ai un peu la tête dans le guidon, ce qui est plutôt une bonne chose, au final.

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 !

WordPress n’est pas fait pour les développeurs !

Julien Appert — Sat, 23 Jan 2010 12:44:31 +0000

Avant-hier, Palleas a lancé un coup de gueule contre les « développeurs wordpress » et contre wordpress en général (« wordpress, c’est de la merde »). Si vous n’avez pas lu l’article, je vous conseille d’aller y jeter un œil avant de continuer la lecture de celui-ci.

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 !

Créer des éléments HTML avec jQuery 1.4

Julien Appert — Fri, 15 Jan 2010 14:37:49 +0000

Si vous avez déjà essayé d’ajouter des éléments HTML avec javascript, vous le savez : c’est la croix et la bannière ! Pour faciliter cette action, la dernière version de jQuery (1.4) propose une nouvelle syntaxe appelée : Quick Element Construction. C’est d’une simplicité déconcertante :

jQuery("", {
 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.

Qui perd la guerre des navigateurs ?

Julien Appert — Sat, 09 Jan 2010 07:40:14 +0000

Cet article est une réaction à un tweet de @davidwalshblog (relayé par @geekarlier) :

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 !

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

Lunascape, le navigateur qui inclut Firefox, Chrome et Windows Explorer

Julien Appert — Mon, 04 Jan 2010 15:52:52 +0000

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’est 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.