Retour d'expérience sur l'extraction des sites CMS
Publié le 28 décembre 2024
Dans mon précédent article sur le gâchis que peut revêtir certains sites motorisés par un CMS, je donnais ma méthode pour transformer un site dynamique en site statique afin de le publier ainsi. Ceci permet d'éviter de consommer trop de ressources pour délivrer un page qui ne bougera pas avant un petit moment.
Cette préoccupation de ne pas trop consommer de ressources est essentiel de nos jours, d'ailleurs un référentiel d'écoconception a été produit et est de plus en plus demandé et donc appliqué.
Dans le présent article, je reviens sur la méthode d'extraction d'un site afin de partager mon retour d'expérience après plusieurs cycles de mises à jour, mais surtout des mises à jour techniques (Systèmes, CMS, ...).
Optimisation du process
Au fur et à mesure de l'utilisation de ma publication en mode statique de mes sites, j'ai pu optimiser le processus afin d'avoir quelque chose de totalement opérationnel et de rapide. Cela tourne en 3 étapes :
- Lancement de "httrack" depuis le répertoire de la dernière extraction. Pas besoin d'option, automatiquement httrack reprend les précédentes !
- Lancement de mon script shell "cleanAll.sh" de retouche des fichiers ainsi extraits
- Transfert des fichiers sur mon serveur d'hébergement avec mon script Kermit "ftpsyncup"
Et hop, une mise à jour du site s'est déroulée...
Détaillons ces étapes.
httrack : Toutes mes options
Par rapport aux options détaillées dans mon précédent article, j'ai un peu optimisé et fait évoluer les options et les pages extraites.
Même si httrack mémorise les options et les URLs à capturer dans le fichier hts-cache/doit.log, en voici le détail :
httrack https://localwww.emmguyot.com https://locallibertylook.emmguyot.com https://localwww.emmguyot.com/?sitemap=pages&type=1533906435 https://locallibertylook.emmguyot.com/?sitemap=pages&type=1533906435 https://locallibertylook.emmguyot.com/en/?sitemap=pages&type=1533906435 https://localwww.emmguyot.com/robots.txt https://locallibertylook.emmguyot.com/robots.txt -*/syntax_highlighter/* -%! -o0 -R5 -b1 -K4 -v -%k -s0 -c10 -%q0 -%l "fr, en, *" -F "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0"
On retrouve dans cette ligne de commande (en gras les points vraiment importants) :
- Les URLs à extraire :
- https://localwww.emmguyot.com : Mon site perso en local
- https://locallibertylook.emmguyot.com : Mon site LibertyLook en local
- https://localwww.emmguyot.com/?sitemap=pages&type=1533906435 : Le sitemap généré par Typo3 pour mon site perso
- https://locallibertylook.emmguyot.com/?sitemap=pages&type=1533906435 : Le sitemap français généré par Typo3 pour mon site LibertyLook
- https://locallibertylook.emmguyot.com/en/?sitemap=pages&type=1533906435 : Le sitemap de la partie anglaise généré par Typo3 pour mon site LibertyLook
- https://localwww.emmguyot.com/robots.txt : Le robots.txt de mon site perso
- https://locallibertylook.emmguyot.com/robots.txt : Le robots.txt de mon site LibertyLook
- -*/syntax_highlighter/* : Ceci est un cas particulier car httrack ne parvient pas à analyser ces scripts SyntaxHighlighter qui chargent dynamiquement d'autres scripts. Ces fichiers seront déposés à la main en attendant de trouver une meilleure solution.
- -%! pour forcer les paramètres au-delà de ce qu'autorise httrack en temps normal
- -o0 : Pas de génération de page HTML en cas d'erreur (404, ...). Ces pages ne doivent pas être déployées car le but est qu'il n'y ait pas d'erreur.
- -R5 : Nombre de tentatives pour charger la page. C'est une simple sécurité au cas où mon poste rame un peu.
- -b1 : Accepte les cookies. Option un peu inutile dans mon cas, mais au cas où.
- -K4 : Conserve les liens originaux. C'est au final la meilleure option pour moi compte tenu des scripts que j'ai ajouté en fin de production.
- -v : Affichage à l'écran de l'avancée de la capture. C'est surtout utile pour vérifier que tout va bien au début.
- -%k : Utilisation de connexion "keep-alive" lors de l'échange avec le serveur Apache. Cela permet de gagner en vitesse lors de la capture.
- -s0 : Ignore les balises pour les robots. Ceci est indispensable pour bien capturer tout le site.
- -c10 : Nombre de connexions simultanées pour accélérer la récupération.
- -%q0 : Pour ne pas intégrer les paramètres des URLs
- -%l "fr, en, *" : Langues acceptées. C'est utile pour moi car le site LibertyLook est en français et en anglais.
- -F "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0" : Pas vraiment utile de spécifier un User Agent, mais bon, ça ne fait pas de mal.
cleanAll.sh : Mon script qui ajuste ce qui doit l'être
Dans mon précédent article, je détaillais comment les pages capturées étaient transformées. Les trois premiers scripts n'ont pas évolué, cependant j'ai enrichi le tout de deux nouveaux scripts :
- cleanCarriageReturn.sh : Ce script uniformise les retours à la ligne des fichiers afin d'optimiser le tout. Ceci est surtout utile pour les pages qui présentent mes programmes.
find . -type f -iname "*.html" -exec dos2unix -k {} \;
- cleanSitemap.xml.sh : Ce script, un peu plus complexe, adresse la production des sitemap.xml pour le référencement. Il renomme le fichier sitemap.xml et produit la version complète FR et EN du sitemap.xml pour LibertyLook.
if [ -f emmguyot.com/localwww.emmguyot.com/index0bd0.html ]
then
mv emmguyot.com/localwww.emmguyot.com/index0bd0.html emmguyot.com/localwww.emmguyot.com/sitemap.xml
# Concatene les 2 sitemaps FR + EN
head -n -1 emmguyot.com/locallibertylook.emmguyot.com/index0bd0.html > emmguyot.com/locallibertylook.emmguyot.com/sitemapLL.xml
rm emmguyot.com/locallibertylook.emmguyot.com/index0bd0.html
tail -n +4 emmguyot.com/locallibertylook.emmguyot.com/en/index0bd0.html >> emmguyot.com/locallibertylook.emmguyot.com/sitemapLL.xml
rm emmguyot.com/locallibertylook.emmguyot.com/en/index0bd0.html
fimkdir -p emmguyot.com/typo3/sysext/seo/Resources/Public/CSS/
docker cp typo3-web-10-4-28:/var/www/html/typo3/sysext/seo/Resources/Public/CSS/Sitemap.xsl emmguyot.com/typo3/sysext/seo/Resources/Public/CSS/Sitemap.xsl
Transfert FTP du site
Cette partie a peu évolué : Elle est toujours basée sur ftpsyncup en Kermit.
Outre une adaptation aux répertoires et serveur FTP, le script adresse 4 parties :
- Le contenu du site www.emmguyot.com
- Le contenu du site libertylook.emmguyot.com
- Les quelques fichiers de Typo3 à maintenir en place (XSL du sitemap par exemple)
- Le changement du fichier .htaccess afin de prendre en compte un fichier différent de celui en local. Pour cela, j'utilise un fichier.htaccess.remote que je renomme lors du transfert par
ftp put .htaccess.remote .htaccess
Problème d'URLs
J'utilise toujours le même CMS : Typo3. Néanmoins, je l'ai fortement mis à jour depuis mon précédent article, ce qui a occasionné quelques écarts de fonctionnement au niveau des URLs produites.
En particulier, suite à ma migration, les URLs pour charger les fichiers Javascript ou CSS étaient affublées d'un paramètre chiffre, correspondant à la date de modification du fichier. Ainsi par exemple j'obtenais ce genre d'URL :
<link rel="stylesheet" type="text/css" href="/typo3temp/assets/css/7015c8c4ac.css?1620486798" media="all"> <script src="/typo3temp/assets/js/62b8391210.js?1620486798"></script>
Evidemment, le site fonctionnait parfaitement sur mon navigateur, mais la transformation en site statique se heurtait à une limite de l'outil httrack. En effet, httrack gère très bien ce type d'URL pour les charger puis renommer le fichier, cependant le source HTML qui appelle ces fichiers de cette façon n'est pas modifiée. Ce qui crée un site "cassé".
Axe httrack
J'ai donc créé une issue sur GitHub afin de permettre de faire évoluer httrack. A ce moment là, j'étais partagé entre l'idée que j'avais raté une option dans httrack ou qu'il s'agissait d'un bug d'httrack. Comme l'outil est très performant, je n'imaginais pas alors que c'était carrément que l'outil ne savait pas le faire.
Toujours pressé de trouver une solution, je me suis plongé dans le code en C d'httrack. Ce code est assez ardu et surement un exemple de code peu maintenable mais, bref, je m'y suis plongé, toujours convaincu que ce n'était surement qu'un petit bug. J'ai bien retrouvé le code qui renomme les fichiers pour le sauvegarder, mais pas de trace d'impact du fichier HTML à la source. Il faut donc se rendre à l'évidence : La fonctionnalité manque 😞
Axe Typo3
Je me tourne donc vers Typo3 pour comprendre pourquoi ces paramètres sont ajoutés et donc comment les supprimer.
Premièrement pas de résultat probant sur les différentes recherches sur Internet.
Je me plonge alors dans le source de Typo3 à coup de "grep" afin de retrouver un début de fil à tirer. Je fini par tomber sur le fichier GeneralUtility.php qui génère le paramètre sur ces fichiers et, oh surprise, j'y vois un paramètre utilisable :
$GLOBALS['TYPO3_CONF_VARS'][TYPO3_MODE]['versionNumberInFilename']
En modifiant ce paramètre dans mon fichier LocalConfiguration.php, je résoud mon problème 🎉