La plupart du temps (et c’est une bonne chose), les plugins pour WordPress fournissent des fichiers contenant leur traduction dans un certain nombre de langues. Seulement voilà, on souhaite parfois adapter cette traduction pour un besoin spécifique. La solution la plus simple est alors de modifier directement le fichier correspondant à notre langue. Mais c’est une erreur et ce pour une raison évidente : lorsque vous (ou la personne qui passera derrière vous) lancerez la mise à jour du plugin, votre modification sera purement et simplement écrasée.

La meilleure solution est donc de surcharger la traduction avec votre propre fichier, que vous placerez au choix dans votre template ou dans un plugin maison.

Première chose à faire : relever le domaine d’application de la traduction. Pour ce faire, allez faire un tour dans le fichier php principal du plugin et cherchez une ligne similaire à celle-ci :

load_plugin_textdomain('domaine', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/');

Le premier paramètre de cette fonction est le domaine qui nous intéresse. Ouvrez ensuite le fichier functions.php de votre template (ou le fichier php de votre plugin maison), et copiez le code suivant :

add_action( 'after_setup_theme', 'changeLanguage' );
function changeLanguage(){
  unload_textdomain( 'domaine' );
  load_plugin_textdomain('domaine', false, '../themes/nomDeMonTemplate/languages/');
}

Le fait d’appeler l’action ‘after_setup_theme’ nous assure que la fonction changeLanguage() sera bien lancée après le chargement du plugin dont on souhaite modifier la traduction. La fonction unload_textdomain() va, comme son nom l’indique, décharger (et donc ne plus tenir compte de) la traduction fournie par le plugin. Puis on charge le nouveau fichier de traduction grâce à la fonction load_plugin_textdomain().

Une fois ce code placé au bon endroit, il ne vous reste plus qu’à copier/coller le fichier .po de la traduction originale à l’endroit de votre choix (que vous avez défini comme 3e paramètre de la fonction load_plugin_textdomain()), l’ouvrir, le modifier et le sauvegarder à l’aide du logiciel poedit. Et le tour est joué !

Désormais, vous pourrez mettre à jour les plugins installés sur votre WordPress sans crainte de perdre vos traductions maison.

crédit image

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 !

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 (( 42… La réponse ultime à la grande question sur la vie, l’univers et le reste)). 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é !

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.

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.