Cuisine interne

En réponse à une demande par courriel, parce que ces informations peuvent peut-être servir à quelqu'un d'autre mais aussi parce qu'avec le temps, j'ai tendance à oublier comment j'ai fait ceci ou cela, voici des explications détaillées sur trois éléments des archives individuelles de ce carnet (pour les billets) et sur la manière dont j'ai utilisé le logiciel Movable Type pour les mettre en place.

• Quelques prérequis
• Contrôle de l'indexation par les robots des moteurs de recherche
• Contrôle de l'affichage des publicités Google Adsense
• Affichage de la liste des billets connexes

Notes : il s'agit de bricolages réalisés par un bricoleur et non par un informaticien ; ces astuces s'appliquent à une version de Movable Type antérieure à la version actuellement distribuée (j'utilise la version 3.01D sur ce carnet) ; je pense (sans avoir vérifié), que la version 3.1 et les versions postérieures permettraient de résoudre certaines des questions que j'ai tenté de traiter avec ces bricolages d'une manière plus sure et plus élégante ; il existe peut-être même des plugins pour se simplifier la vie, mais je ne les ai pas recherchés ; même s'il n'existe aucun plugin, notez bien que les solutions que j'utilise ne sont certainement ni très sures, ni très élégantes, ni très économes en ressources, pensez-y si vous vouliez les essayer.

Prérequis

Utilisation de PHP

Les bricolages expliqués ici utilisent PHP. La version installée sur le serveur qui héberge ce site est postérieure à PHP 4.0., et je ne me suis pas posé la question de la compatibilité de ces astuces avec les versions antérieures de ce langage de script.

Les fichiers correspondant aux billets sont interprétés comme des scripts PHP

Pour que les astuces expliquées ici fonctionnent, il faut que les pages individuelles des billets soient interprétées comme des scripts PHP. Ce site est hébergé sur un serveur pour lequel l'extension standard indiquant les fichiers à interpréter comme des scripts PHP est .php. Comme il s'agit d'un serveur mutualisé, je ne peux pas en modifier la configuration, et comme j'avais commencé à bloguer avant de me creuser la tête sur ces bricolages, j'avais balancé dans la nature tout un tas de billets avec l'extension .html.

Les fichiers portant l'extension .html sont interprétés comme des scripts PHP

Pour pouvoir faire interpréter par le serveur les fichiers correspondant à mes billets comme du PHP, j'avais au moins deux possibilités :

• Changer, dans la configuration de Movable Type, l'extension des fichiers correspondant aux archives individuelles des billets de .html en .php. Cette solution n'était pas très satisfaisante, car pour faire les choses proprement, j'aurais dû gérer les redirections, c'est à dire indiquer au serveur que lorsqu'une ancienne adresse URL en .html était demandée par un client, il fallait lui indiquer la nouvelle adresse se terminant par .php en lui envoyant des indications de redirection. Je trouvais ça tordu et pénible, et je me suis dit que si je voulais un jour renoncer à mes trucs de bricolo et ne plus utiliser PHP, il serait bien plus simple d'avoir gardé les mêmes adresses URL.
• Indiquer au serveur que les fichiers portant l'extension .html devaient être interprétés comme des scripts PHP. C'est cette solution que j'ai choisie.

Ce site Web est hébergé sur un serveur Apache : j'ai simplement utilisé un fichier .htaccess dans lequel j'ai placé l'instruction suivante :

AddType application/x-httpd-php .html

J'ai placé ce fichier tout en haut du répertoire archives/ , dans les sous-répertoires duquel sont placés mes billets : tous les fichiers portant l'extension .html placés à ce niveau ou plus bas dans cette branche sont interprétés comme des scripts PHP, mais pas les fichiers placés dans les autres répertoires ou à la racine.

Mon souci était la consommation excessive de ressources du serveur par mes bricolages, et comme je n'y connais quasiment rien dans ce domaine, j'ai pensé que cette précaution m'éviterait peut-être de me faire insulter par mon administrateur (comme il n'a pas réagi jusqu'à maintenant, j'imagine que mes trucs ne sont pas trop gourmands en ressources).

Notez que la page principale est elle-aussi interprétée comme un script PHP, mais dans ce cas, j'ai tout simplement indiqué à Movable Type que je souhaitais nommer mon index principal index.php, au lieu de index.html, et le serveur est configuré de telle manière que lorsqu'un client demande http://www.azurs.net/mercredi/ , la machine lui sert index.html si ce fichier existe, et index.php, interprété comme un script PHP si index.html n'existe pas.

Contrôle de l'indexation par les robots des moteurs de recherche

Pourquoi interdire l'indexation de certains billets ?

Je m'inquiète souvent de l'influence de ce que je peux poster ici sur les résultats fournis par les moteurs de recherche à leurs utilisateurs. Depuis que j'ai ajouté quelques informations sur le contexte dans lequel il faut considérer les billets, les choses semblent s'améliorer (je reçois moins de commentaires ou de courriels montrant qu'un visiteur venant d'un moteur de recherche s'est mépris sur ce qu'il a lu). Dans certains cas, interdire l'indexation par les robots farceurs ou par certains robots farceurs particulièrement impertinents reste nécessaire.

Comment décider individuellement de l'indexation de certains billets par les moteurs de recherche ?

Pour résoudre ce problème, je devais avoir la possibilité de désactiver simplement et ponctuellement l'indexation par les moteurs de recherche pour un billet donné.

Utilisation du champ Keywords de Movable Type

J'ai écrit un petit script qui réagit à une instruction placée dans le champ Keywords de Movable Type. Ce script est un bout de code PHP inséré dans le fichier correspondant à un billet lorsque Movable Type construit ou reconstruit la page individuelle de ce dernier.

La valeur de la variable indiquant s'il faut ou non indexer est renseignée à ce moment là, et non de manière dynamique. En pratique, cela signifie que si je veux désactiver l'indexation sur un billet, il faut que j'aille renseigner le champ Keywords de ce billet, puis que je sauvegarde les modifications pour indiquer à Movable Type qu'il faut reconstruire le fichier.

3 cas

J'ai distingué trois cas :

• Lorsque le champ Keywords contient l'instruction noindex, le billet ne doit pas être indexé par le redoutable Googlebot : une balise méta GOOGLEBOT est placée à l'intention de ce robot dans l'entête (entre les balises HEAD) de mon fichier, elle prend la valeur NOINDEX. Dans le fichier que construit Movable Type pour un billet de ce type, la ligne : <meta name="googlebot" content="noindex" /> est ajoutée entre les balises HEAD.
• Lorsque le champ Keywords contient l'instruction allnoindex, le billet ne doit être indexé par aucun robot farceur courtois (c'est à dire par aucun robot farceur comprenant et respectant le protocole d'exclusion des robots). Une balise méta ROBOTS est placée dans l'entête de mon fichier, elle prend la valeur NOINDEX. Dans le fichier que construit Movable Type pour un billet de ce type, la ligne : <meta name="robots" content="noindex" /> est ajoutée entre les balises HEAD.
• Lorsque le champ Keywords ne contient ni l'instruction allnoindex, ni l'instruction noindex, rien n'est ajouté entre les balises HEAD et l'indexation peut se faire normalement (cas général).

En pratique, pour faciliter la relecture de mon modèle d'habillage d'interface (template) pour les archives individuelles, j'ai placé ces quelques lignes de code dans un module de modèle d'habillage d'interface (template module) nommé indexation qui contient le code suivant :

<?php
$variable="<$MTEntryKeywords remove_html="1"$>";
if ($variable=="noindex") {echo "<meta name=\"googlebot\" content=\"noindex\" />";}
if ($variable=="allnoindex") {echo "<meta name=\"robots\" content=\"noindex\" />";}
?>

L'appel du module indexation lors de la construction par Movable Type des fichiers correspondant aux billets est déclenché par la ligne suivante placée avec les autres balises méta, entre les balises HEAD, dans le modèle d'habillage d'interface pour les archives individuelles (billets) :

<$MTInclude module="indexation"$>

Notez que les lignes de code que contient le module indexation pourraient tout aussi bien être placées directement dans le modèle d'habillage d'interface de mes archives individuelles. Notez aussi que la variable $variable est renseignée à la construction ou à la reconstruction des fichiers correspondant aux billets. J'ai utilisé un nom générique pour cette variable car je me sers du champ Keywords pour d'autres bidouillages, comme je l'explique plus loin dans ce billet.

Contrôle de l'affichage des publicités Google Adsense

Sur certains billets, je voulais ajouter des liens promotionnels Google Adsense. J'ai procédé de la même manière que pour l'inclusion ou l'omission d'une balise méta contrôlant l'indexation par les robots farceurs. Dans ce cas, si le mot pub est présent dans le champ Keywords de Movable Type, une bannière s'affiche.

Les seules différences avec le truc précédent sont :

• la position du module de modèle d'habillage d'interface correspondant, placé dans le modèle d'habillage d'interface à l'endroit du code source où je souhaite voir apparaître le morceau de javascript qui provoque l'affichage des annonces Adsense,
• le fait que le morceau de code contenu dans ce module ne sert qu'à tester la présence de l'instruction requise dans le champ Keywords de Movable Type, le contenu effectivement inclus si cette condition est vérifiée est placé dans un fichier séparé (adsense.inc, qui contient mon code Adsense).

Le module en question, nommé publicite, contient les lignes suivantes :

<?php
if ($variable=="pub") {
include ('/include/path/adsense.inc');
}
?>

/include/path/ est le chemin vers le fichier adsense.inc à définir en fonction de la configuration de PHP sur le serveur qui héberge ce site.

Affichage de la liste des billets connexes

Chaque billet est associé à au moins une catégorie principale. Au bas des pages individuelles de chaque billet, des liens vers les autres billets récemment publiés dans cette catégorie s'affichent.

Je cherchais une solution qui permette la mise à jour de ces liens sans avoir à reconstruire toutes les pages chaque fois qu'un nouveau billet était publié ou qu'un billet modifié changeait de catégorie principale.

Utilisation de Magpie RSS

Pour arriver à mes fins, j'ai utilisé le parser Magpie RSS : comme je disposais déjà de fils de syndication pour chaque catégorie, je me suis dit que le plus simple était, en quelque sorte, de « syndiquer » mon propre contenu en utilisant ces fils.

La mise en place de Magpie RSS est très simple (beaucoup plus simple que je ne le pensais au départ), et bien documentée.

Récupération des billets connexes

Pour récupérer mes billets connexes, il me suffit de passer les références du fil de syndication de la catégorie principale de chaque billet à un petit script qui utilise Magpie RSS.

Les fils de syndication de chaque catégorie se trouvent dans un répertoire archives/xml/cats/ et sont nommés de la manière suivante :

cat_nom_de_la_categorie.xml

nom_de_la_categorie correspond au contenu de <MTEntryCategory dirify="1"$>. Dans le modèle d'habillage d'interface des billets, j'ai inclus, à l'endroit où je souhaite voir apparaître les liens connexes, les lignes suivantes :

<ol>
<?php
$categorie=<MTEntryCategory dirify="1"$>;
include('/include/path/liensconnexes.php');
?>
</ol>

$categorie est la variable contenant la catégorie principale du billet concerné, elle permet de récupérer l'adresse du fil de syndication. liensconnexes.php est un petit script qui contient les quelques lignes suivantes :

<?php

define('MAGPIE_DIR', '/include/path/to/magpie/dir/');
define('MAGPIE_CACHE_ON', 1);
define('MAGPIE_CACHE_AGE', 172800);
define('MAGPIE_CACHE_DIR', '/include/path/to/magpiecache/dir/');

require_once(MAGPIE_DIR.'rss_fetch.inc');

$url = "http://www.azurs.net/mercredi/archives/xml/cats/cat_".$categorie.".xml";
$rss = fetch_rss( $url );
foreach ($rss->items as $item) {
$href = $item['link'];
$title = $item['title'];
$content = $item['description'];

echo "<li><a href=\"".$href."\">".$title."</a> : ".$content."</li>";
}
?>

liensconnexes.php retourne la liste des billets présents dans le fil RSS de la catégorie $catégorie, sous la forme d'une liste d'éléments délimités par les balises <li> et </li>, qui contiennent le titre de chaque billet, un lien vers sa page individuelle, et sa description. Je définis cette liste d'éléments comme une liste ordonnée, et je la place entre deux balises <ol> et </ol>.

Après quelques essais, j'ai choisi d'utiliser le CACHE et de ne rafraîchir l'affichage que toutes les 48 heures environ (MAGPIE_CACHE_AGE est fixé à 172800 s.).

Pourquoi ?

Euh... C'est une bonne question !

• Parce que c'est mon bon plaisir.
• Parce que j'aime bien l'idée qu'un visiteur arrivé directement sur un billet accède, s'il est suffisamment intéressé ou trop déçu par ce qu'il aperçoit pour glisser tout en bas de la page, à des liens qui devraient, en principe, le conduire vers des pages internes et externes traitant du même sujet.
• Parce qu'il faut aider les robots farceurs. Les algorithmes de classement des moteurs de recherche tiennent généralement compte, pour évaluer une page donnée, du contenu des autres pages pointant sur elle. J'ai dans l'idée que ces liens connexes et les résumés associés facilitent le travail des moteurs et améliorent la qualité des résultats, à la fois pour les liens externes, que les robots rencontrent, dévorent et apprécient en premier parce qu'ils sont placés plutôt vers le haut des pages individuelles, et pour les liens internes. Ça reste à vérifier.

• Thomas,
•  29 septembre 2004, 19:00,
• pour bricoler.

Haut de page