Statistifier un site Wordpress
Le mardi 03 novembre 2015 par Benjamin BoudoirJ'ai eu quelques surprises en statifiant un site évenementiel, je me suis dit que partager ces infos seraient une bonne chose.
Création du mirroir
On commence par un petit script qui fait un joli mirroir :
#!/bin/bash
destination=$HOME/static-websites/
domain=$1
wget --page-requisites --mirror --no-parent --convert-links --execute robots=off \
-P $destination \
$domain
Et voilà.
Sauf que bon. Dans mon cas il s'agit d'un site évènementiel... Avec un joli calendrier. Et du multilingue....
Bref, en récupérant le site comme ça, je me retouvais avec de nombreuses pages inutiles comme :
- index.html?eo_month=1677-10
- index.html?lang=en&eo_month=1812-02
Bref, j'ai pas trop envie de les conserver. Heureusement, wget nous permet d'éviter de télécharger certaines pages correspondant a des patterns définis. Petite blague, la version Debian de GNU Wget est compilée sans le support de PCRE, mais les regexp POSIX sont suffisantes pour faire ce qu'on veut. Dans mon cas, conserver uniquement 2015 est largement suffisant :
#!/bin/bash
destination=$HOME/static-websites/
domain=$1
wget --page-requisites --mirror --no-parent --convert-links --execute robots=off \
--reject-regex 'eo_month=([0,1,3-9][0-9]{3}|[0-9][1-9][0-9]{2}|[0-9]{2}[0,2-9][0-9]|[0-9]{3}[0-4,6-9])-.*' \
-P $destination \
$domain
Configuration du serveur web
Voilà, maintenant j'ai un joli contenu statique que je peux envoyer sur mon serveur web.... Ou pas.
Les personnes plus attentives que moi auront sans doute repéré quelque chose qui ne m'avait pas sauté aux yeux : les URI ont des paramètres. Et votre serveur web (dans mon cas, Apache HTTPd 2.4) va les traiter comme tel. Il va nous falloir faire une jolie transition de l'un a l'autre pour échapper le "?" en "%3F".
Seulement voilà, le moteur de réécriture d'Apache n'est pas vraiment prévu pour ce genre de choses. Il peut le faire, mais vous allez voir que ce n'est pas la chose la plus simple a faire. Cette approche n'est même pas couverte explicitement par la documention alors qu'il existe de la documentation pour l'effet inverse.
Heureusement, en tatonant un peu avec la documentation complète et un peu de logs (LogLevel rewrite:trace8), fini par arriver a un résultat qui marche :
RewriteEngine on
# Dans un .htaccess, une règle interne d'Apache HTTPs rajoutera le chemin
# complet du fichier
RewriteBase /
# On traite pas les URI qui contiennent un "?". Parce que, oui, quand on lui
# envoie "%3F", le moteur traite un "?" (ce qui est logique)
RewriteCond "%{REQUEST_URI}" "^[^?]*$"
# On traite pas non plus quand on a un "%3F" dans la requête (parce que sinon
# on se retrouve dans un jolie boucle de redirections)
RewriteCond "%{QUERY_STRING}" "^.*[^%][^3][^F]*$"
# Par contre, on traite quand même la requête si elle contient un "?"
RewriteCond "%{QUERY_STRING}" "([^?]*)?([^?]*)$"
# Et enfin la réécriture. On récupère l'ensemble des informations avant le "?"
# qu'on réutilisera ($1) et on récupère la suite via les parenthèses capturantes
# de la condition du dessus (%1).
# On oublie pas d'escape le "%" quand on réécrit le "?" en "%3F"
# Voici le détail des flags :
# [PT] : On envoie le résultat de la regexp au resolver interne, le résultat
# est totalement transparent pour les utilisateurs.
# [NE] : On empêche d'escaper le % une fois de plus
# [QSD] : On retire les paramètres (?....) de l'URL
RewriteRule "(.*)?.*" "$1\%3F%1" [PT,NE,QSD]
Pas besoin de parser spécifiquement le "&" étant donné que le séparateur URI/Requête est le "?", ça juste marche.