C’est là que Reply and Email intervient ! Grâce à ce plugin que je viens de développer, fini d’être spammé dès qu’un nouveau commentaire arrive sur un billet où l’on s’est inscrit il y a des années…

Comment ça marche ?

Dans votre administration WordPress, vous pouvez activer les commentaires imbriqués. Cette option très pratique permet de classer visuellement les conversations. Si cette option est activée, bien évidemment, Reply and Email l’utilise pour fonctionner.

Mais peut-être ne souhaitez-vous pas activer les commentaires imbriqués ? Et je le comprends très bien, car c’est mon cas (on ne va cependant pas disserter ici des avantages et inconvénients de cette option). Alors soit, si cette option n’est pas activée, Reply and Email fonctionnera tout de même ! Dans ce cas, le plugin ajoutera de manière automatique (ou non, au choix) un lien « répondre » qui ajoutera le code suivant dans le champ de commentaire :

@<a href="#comment-23" rel="nofollow">Julien Appert</a>:

Pour tout le monde, ceci est un lien vers le commentaire d’origine. Pour le plugin, c’est une balise qui permet d’identifier le commentaire auquel on répond, et ainsi faire tourner la moulinette de la réponse par mail.

On peut le tester ?

Bien entendu ! Déjà, vous pouvez voir ce que ça donne ici même. Si ça vous tente, vous pouvez même télécharger la version 0.1 de Reply and Email pour la tester chez vous.

Pour le moment, je ne publie pas le plugin sur wordpress.org. Je vais déjà attendre vos retours, et il faut que je me penche sur la traduction en anglais… D’ailleurs si ça branche l’un d’entre vous de m’aider à ce niveau, je suis preneur (je suis plutôt Molière que Shakespeare, si vous voyez ce que je veux dire).

Mais enfin, peut-être qu’elle vous dérange plus qu’autre chose, cette barre. Et après tout, vous êtes maître chez vous. Voici donc une ligne de code à placer dans le fichier functions.php de votre thème :

show_admin_bar( false );

Et la barre disparait !

Tout d’abord, il convient de désactiver les flux eux-mêmes :

add_action('do_feed', 'disable_feed', 1);
add_action('do_feed_rdf', 'disable_feed', 1);
add_action('do_feed_rss', 'disable_feed', 1);
add_action('do_feed_rss2', 'disable_feed', 1);
add_action('do_feed_atom', 'disable_feed', 1);

function disable_feed(){
     wp_die('Les flux RSS pour ce site sont désactivés.');
}

Grâce au code ci-dessus, les différentes pages de flux afficheront uniquement votre message.

Ensuite, il faut supprimer les liens d’abonnement. Si vous êtes parti d’un thème existant pour réaliser votre site, il y a de fortes chances que vous trouviez la ligne suivante, quelque part dans le fichier functions.php :

add_theme_support( 'automatic-feed-links' );

Si c’est le cas, supprimez la ligne et les liens pour s’abonner aux flux disparaitront.

Dernier point, le flux des commentaires. Lorsque vous affichez un article avec WordPress, le flux des commentaires de l’article s’ajoute à la liste des abonnements. Vous souhaitez le supprimer ? Copiez le code suivant :

function remove_rss() {
    return;
}
add_filter('post_comments_feed_link','remove_rss');

d’

Et là je me suis dit stop ! Passons à une méthode plus pérenne, passons à font-face.

Rapide historique

Par défaut, un navigateur va utiliser les polices d’écriture présentes sur l’ordinateur de l’internaute pour afficher le texte d’un site web. Ce qui explique que nous soyons assez limités en terme de diversité d’écriture, car les polices disponibles sur tous les ordinateurs ne sont qu’une poignée. Il y a encore quelques années, pour rompre la monotonie, nous utilisions des images. Le problème : des sites plus lourds à charger et des textes impossibles à analyser pour les moteurs de recherche.

Puis les scripts tels que Cufon sont apparus. Le principe : vous affichez du vrai texte sur votre site web, et une surcouche javascript passe par dessus pour transformer la police d’écriture. L’inconvénient : le javascript doit être activé sur le navigateur de l’internaute… et il faut régulièrement mettre à jour le script pour assurer sa compatibilité avec les nouvelles versions de navigateurs.

Le tant attendu font-face

Or, depuis quelques années, il existe une règle css censée nous changer la vie : font-face. Elle permet d’afficher une police d’écriture personnalisée que vous aurez préalablement chargée sur votre site web. Par conséquent, au lieu d’aller chercher une police sur l’ordinateur de l’internaute (sans assurance de la trouver), le navigateur va simplement chercher la police sur votre site. Mais cette règle css n’a été implémentée qu’assez récemment sur les navigateurs modernes (tandis qu’Internet Explorer le gère depuis sa version 4.0).

Font-face est disponible depuis :

• Firefox 3.5
• Opera 10
• Safari 3.1
• Chrome 3.0
• Internet Explorer 4

Comment utiliser font-face

A présent que font-face est largement disponible, il est donc possible de l’utiliser ! Comment ? Voici les 3 lignes de code css indispensables :

@font-face {
    font-family: 'Police';
    src: url('police.eot'); // IE
	src:local("Police"),url('police.ttf') format('truetype');
}

Vous aurez remarqué qu’IE nécessite un format de fichier particulier. Les autres navigateurs feront leur affaire avec le format truetype, mais certains vont préférer d’autres formats de police que vous pouvez également fournir de la manière suivante :

url('police.woff') format('woff'),
url('police.svg') format('svg');

Ensuite pour faire appel à cette police, utilisez la méthode traditionnelle :

h1{ font-family:"Police", Arial, sans-serif;}

La question est : où trouver ces formats de fichiers ? Vous pouvez par exemple acheter la police sur le site MyFonts, où vous trouverez ces différents formats dans le zip téléchargeable. Mais si vous avez en votre possession un fichier ttf ou oft, faites un tour sur le site Fontsquirrel, qui met à votre disposition un « @font-face generator », lequel vous fournira les versions converties de votre police.

Je vous conseille également d’aller lire la présentation d’Yves Van Goethem, qui vous apportera quelques informations complémentaires, notamment en terme d’optimisation.

Fatal error: Out of memory (allocated 31981568) (tried to allocate 3528484 bytes)

Le service technique de 1&1 a répondu à mon mail d’insultes d’appel à l’aide en m’expliquant comment augmenter la mémoire allouée jusqu’à la valeur ô combien vertigineuse de 40MB. Ouch. Comment dire. Ça ne sera pas suffisant.

Bon, qu’à cela ne tienne, je me suis remonté les manches et j’ai trouvé une solution bâtarde, c’est à dire à mi-chemin entre la mise à jour manuelle et la mise à jour automatique. Pourquoi ne pas faire simplement une mise à jour manuelle, allez-vous me demander ? Simplement parce que celle-ci prend trop de temps et est fortement génératrice de stress (même quand on sait comment s’y prendre). Bref, ma solution est la suivante :

1. Télécharger le fichier zip de la dernière version de WordPress
2. L’uploader via FTP dans un dossier de WordPress (j’ai choisi wp-content, mais ça peut être n’importe où)
3. Modifier le fichier wp-admin/includes/class-wp-upgrader.php  :

Rendez-vous à la ligne 878 (class Core_Upgrader, function upgrade), à savoir au niveau du code suivant :

$download = $this->download_package( $current->package );

Et remplacez le par ceci :

if($current->package == 'http://fr.wordpress.org/wordpress-3.0.4-fr_FR.zip')
 $download = '/chemin/vers/le/fichier/wordpress-3.0.4-fr_FR.zip';
 else
 $download = $this->download_package( $current->package );

Théoriquement, on devrait pouvoir se contenter de la ligne 2, mais je préfère prendre mes précautions.

L’exemple est évidemment à adapter avec la version de WordPress idoine. Si vous ne connaissez pas le chemin exact de votre site, c’est simple, vous l’avez à la fin de la « Fatal error » mentionnée plus haut. Après cela, lancez à nouveau la mise à jour automatique. Miracle, ça passe tout seul !

Le fichier que vous venez de modifier sera évidemment remplacé par la mise à jour, donc ne vous étonnez pas, il vous faudra recommencer cette manipulation à chaque fois que vous voudrez mettre à jour le core (et accessoirement, revenir sur cet article pour copier/coller le code )

Je suis de plus en plus souvent amené à développer sur du WordPress en mode multisite, c’est à dire avec une gestion de blogs multiples. En général, le schéma est le suivant : un site général d’un côté (couplé avec BuddyPress pour les aspects sociaux) et des blogs d’utilisateurs de l’autre côté.

Immanquablement vient alors la question des plugins. On peut être amené à en installer plusieurs pour le fonctionnement du site général, mais on ne veut pas forcément que les utilisateurs puissent avoir également accès à tous ces plugins sur leurs blogs…

Par défaut, WordPress gère deux modes de gestion des plugins : l’activation simple et l’activation sur le réseau. Si vous activez un plugin sur le réseau, il sera alors installé d’office partout, sans possibilité pour les utilisateurs de le désactiver. Cela peut être utile, dans certains cas, mais c’est malheureusement le contraire de ce que l’on voudrait ici ! Quant à l’activation simple, elle permet à chaque utilisateur de choisir quel plugin il désire utiliser sur son blog. En résumé, si vous installez un plugin sur un WordPress multisite, tout le monde y aura accès, soit par obligation, soit par choix.

Par conséquent, pour filtrer les plugins disponibles sur les blogs d’utilisateurs sans avoir à se restreindre sur le site général, il faudra passer par l’installation… d’un plugin.

Si vous travaillez sur une version moderne de WordPress (3.0 ou plus), vous pouvez utiliser le très bon Exclude Plugins, développé par un certain ITX.

Si vous devez faire avec un vieux wpmu (par exemple un 2.9), Exclude Plugins ne pourra rien pour vous, car sa compatibilité ne descend pas jusque là. Mais je ne vais pas vous laisser en plan comme ça. Avec WordPress, on trouve toujours une solution, vous pensez bien. Je vous suggère alors l’installation de Plugin Commander, qui fonctionne à partir de WordPress 2.8. Oh il fonctionne aussi avec les versions plus récentes, mais après avoir testé les deux plugins, je dois vous avouer une nette préférence pour Exclude Plugins (mieux développé, mieux structuré, à mon avis).

Voilà pour l’astuce, c’est cadeau ! J’en profite pour m’excuser auprès de tous ceux qui ont commenté sur ce blog à propos de mes différents plugins. Je peine à trouver le temps de m’en occuper, et donc à vous répondre. J’espère trouver le temps bientôt. Oh, et sinon, j’ai cru comprendre que la prochaine version de WordPress inclurait une fonctionnalité inspirée de Link to Post… A vérifier !

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

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 .

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 <?php bloginfo('url'); ?> 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 <body> :

<?php
if (current_user_can('administrator')){
 global $wpdb;
 echo "<pre>";
 print_r($wpdb->queries);
 echo "</pre>";
}
?>

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 :

<?php
 /*
 Plugin Name: Disable Autosave
 */
 function disable_autosave() {
 wp_deregister_script('autosave');
 }
 add_action( 'wp_print_scripts', 'disable_autosave' );
 ?>

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

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