2021-12-02
md
Nettoyer un site web
W3C LogValidator in cPanel->

Voici mon choix idiosyncrasique d'outils pour nettoyer les fichiers HTML de mon site web. Il reflète les contraintes imposées par certaines décisions de conception lorsque j'ai créé mon site web et des exigences particulières, dont une nette préférence pour des programmes qui peuvent être utilisés localement sur mon ordinateur de bureau. Je voulais aussi que les vérificateurs n'exigent pas Python version 2.7.x. qui est maintenant obsolète ce qui a éliminé certains programmes utilisés auparavant.

La version en anglais de ce billet présente d'autres outils qu'en fin de compte, je n'utilise pas. En outre il y a une discussion assez longue de HTML Tidy qui pourrait s'avérer fonctionnel si un préprocesseur HTML comme GTML n'est pas employé.

Table des matières

  1. Comptage et liste des fichiers HTML
  2. Vérification de la syntaxe HTML avec Nu Html Checker
    1. Vérification depuis le web
    2. Installation locale du vérificateur
    3. Vérification locale
    4. Vérification à partir de la ligne de commande
  3. Vérification des fichiers CSS
  4. Vérification des liens hypertexte avec LinkChecker
  5. Stratégie

Comptage et liste des fichiers HTML toc

Au fil des ans, de nombreux fichiers ont été ajoutés à ce site. J'étais curieux de connaître leur nombre et, surtout, d'obtenir une liste des noms complets de ces fichiers. Les utilitaires find et wc peuvent répondre à ces questions.

michel@hp:~$ find /var/www/html/michel/ -type f | wc -l 1812 michel@hp:~$ find /var/www/html/michel/ -name '*html' | wc -l 329

Évidemment le dossier /var/www/html/michel sur mon ordinateur personnel contient une copie du site web hébergé par un fournisseur situé à mille kilomètres. En fait, il y a trois complications dont il faut tenir compte pour obtenir le nombre exact de pages HTML sur le site public depuis la copie locale. Voici la commande que j'utilise pour avoir le bon compte.

michel@hp:~$ find /var/www/html/michel/ -type f -name '*html' -not \( -path "*/local/*" -o -path "*/dnld/*" \) | wc -l 320

Il y a un répertoire nommé /var/www/html/michel/local qui n'est pas copié vers le site public. Puis il y a des fichiers à télécharger de type HTML dans des sous répertoires */dlnld/* dans l'arborescense du site. L'option -not \( -path "*/local/*" -o -path "*/dnld/*" \) élimine les fichiers provenant de ces dossiers. Enfin le fichier /var/www/html/michel/index.html n'est qu'un lien symbolique vers ./index_fr.html ou ./index_en.html. Pour ne pas le compter deux fois, l'option -type f élimine tout ce qui n'est pas un fichier ordinaire.

Si le résultat de la commande find n'est pas acheminé vers le compteur de lignes wc, mais plutôt rediriger vers un fichier on obtient une liste de tous les fichiers HTML a vérifier.

michel@hp:~$ find /var/www/html/michel/ -type f -name '*html' -not \( -path "*/local/*" -o -path "*/dnld/*" \) > liste_html.txt

Cette liste est tout ce qu'il faut pour entamer la vérification du site web. Voilà qui est simple, alors il me fallait compliquer les choses en créant un script qui utilise tree (plutôt que find) pour obtenir une liste de nom dans un ordre que je préfère.

#!/bin/bash # Web Site Statistics ############################################# # Defaults - adjust these #-------------------------------------------- # directory containing local copy of the site local=/var/www/html/michel/ #-------------------------------------------- # output path prefix prefix=http://localhost/michel/ #-------------------------------------------- # do not list html files list="stat" ############################################# output="" usage() { echo "$(basename $0) [-h] [-a | -l] [-d srcdir] [-p prefix]" echo " -h this help message" echo " -a list all (site statistics and html files)" echo " -l list html files only" echo " -d srcdir web site directory (default: $local)" echo " -p prefix concatenate file path prefix (default: $prefix)" echo " -p '' will remove default path prefix" } while getopts ':halp:d:' OPTION; do case "$OPTION" in h) usage exit 0 ;; a) list="all" ;; l) list="files" ;; p) prefix="$OPTARG" ;; d) local="$OPTARG" ;; *) usage exit 1 ;; esac done if [ ! -d "$local" ]; then echo "$local does not exist" exit 2 fi #length of local len=${#local} if [ $list != "files" ]; then echo "Location of site: $local" echo -n "Number of files: "; find $local -type f | wc -l echo -n "Number of HTML files: "; find $local -type f -name '*html' | wc -l echo -n "Number of English HTML files: "; find $local -type f -name '*en\.html' | wc -l echo -n "Number of French HTML files: "; find $local -type f -name '*fr\.html' | wc -l echo -n "Number of JPEG image files: "; find $local -name '*jpg' | wc -l echo -n "Number of PNG image files: "; find $local -name '*png' | wc -l echo -n "Number of downloads: "; find $local -wholename '*dnld/*' | wc -l echo -n "Number of ZIP archives: "; find $local -name '*zip' | wc -l echo -n "Number of bash scripts: "; find $local -name '*sh' | wc -l echo -n "Number of Pascal files: "; find $local -name '*pas' | wc -l echo -n "Number of Arduino sketches: "; find $local -name '*ino' | wc -l echo -n "Number of C files: "; find $local -name '*c' | wc -l echo -n "Number of PDF files: "; find $local -name '*pdf' | wc -l fi if [ $list != "stat" ]; then # list files if list == all or list == files tree -f -i --noreport --dirsfirst -I 'index.html' -P '*.html' $local | sed -r "s/.{$len}//" | sed '/html$/!d' | sed -e "s#^#$prefix#" fi

Si tree n'est pas installé, l'utilitaire apt s'en charge rapidement.

michel@hp:~$ sudo apt install tree ... 0 mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 43,0 ko dans les archives. ...

Le script sitestats peut être téléchargé. Enregistrez le fichier dans un répertoire du chemin de recherche tel que ~/.local/bin et faites-en un exécutable.

michel@hp:~$ chmod +x .local/bin/sitestats

N'oubliez pas d'éliminer l'option | sed "/\/dnld\/\|^local/d" de la commande tree à la fin du script s'il n'y a pas de dossiers */dnld/* et local/ à traiter.

The script can be downloaded: sitestats. Save the file in a directory in the search path such as ~/.local/bin and make it an executable. Don't forget to eliminate the | sed "/\/dnld\/\|^local/d" pipe if there is no need to deal with dnld/ and local/ directories. En règle générale, j'utilise ce script comme suit.

michel@hp:~$ sitestats -l -p '' > htmlfiles.csv

Le fichier htmlfiles.csv contient une liste de tous les fichiers HTML du site web par ordre alphabétique, à l'exception des derniers fichiers qui se trouvent dans le répertoire racine du site. J'ai importé ce fichier dans une feuille de calcul qui sera utilisée pour suivre certaines informations fichier par fichier. Dans une colonne, j'entre la date de la dernière fois que j'ai vérifié le fichier avec Nu HTML Checker (voir la section suivante) et la dernière fois que les liens du fichier ont été vérifiés est entrée dans une troisième colonne. Le deuxième exemple montre comment utiliser sitestats pour produire une liste de fichiers HTML pouvant être utilisés pour vérifier localement le site web complet avec Nu HTML Checker et LinkChecker à partir de la ligne de commande, comme cela sera expliqué plus tard.

michel@hp:~$ sitestats -l > list.txt

Voici un aperçu du résultat.

http://localhost/michel/3d/first_3d_prints_en.html http://localhost/michel/3d/intro_openscad_01_en.html http://localhost/michel/ha/ahsdk/ahsdk-downloads_en.html ... http://localhost/michel/index_en.html http://localhost/michel/index_fr.html http://localhost/michel/major_incident_en.html http://localhost/michel/major_incident_fr.html

Il est possible de vérifier directement toutes les copies locales des fichiers HTML constituant le site web avec Nu HTML Checker sans passer par le serveur web. Voici comment générer la liste de fichiers avec l'utilitaire puis voici un aperçu de cette liste.

michel@hp:~$ sitestats -l -p /var/www/html/michel/ > list2.txt
/var/www/html/michel/3d/first_3d_prints_en.html /var/www/html/michel/3d/intro_openscad_01_en.html /var/www/html/michel/ha/ahsdk/ahsdk-downloads_en.html ... /var/www/html/michel/index_en.html /var/www/html/michel/index_fr.html /var/www/html/michel/major_incident_en.html /var/www/html/michel/major_incident_fr.html

Un examen du script révèle qu'il forme cette liste d'une façon peu efficace, car il commence en supprimant la racine /var/www/html/michel/ du nom complet de chaque fichier et il se termine en rajoutant cette même racine. J'étais tout simplement trop paresseux pour refaire sitestats après avoir découvert que le véritable chemin des fichiers pouvait être utilisé par Nu Html Checker lorsqu'il était exécuté à partir de la ligne de commande.

Vérification de la syntaxe HTML avec Nu Html Checker toc

Le World Wide Consortium (W3C) fournit des outils aux développeurs de contenu pour le web, notamment Nu HTML Checker (alias v.Nu). Le W3C est catégorique : son vérificateur ne certifie pas qu'une page web répond à une quelconque norme, mais il détecte les erreurs. v.Nu peut être utilisé comme un outil web tel que décrit dans la sous-section suivante, mais je préfère l'installer sur mon ordinateur de bureau pour exécuter des vérifications localement. La procédure à suivre pour utiliser ce programme de cette façon se trouve dans les sous-sections suivantes.

Vérifications depuis le web toc

Cliquez sur le lien : https://validator.w3.org/nu/ pour accéder au vérificateur. L'application web ne peut vérifier qu'un seul fichier à la fois.

Nu Html Checker - checking remote file

Le fichier index.html de mon site web sera vérifié à l'aide de la méthode address en cliquant sur le bouton Check. En fait, je ne procède jamais ainsi. Étant donnée l'utilisation du préprocesseur GTML, il est préférable de tester la copie locale du fichier qui se trouve sur mon ordinateur de bureau parce que je ne corrige jamais directement le fichier HTML. Le code source doit être modifié, la page web doit être engendrée avec le préprocesseur et puis elle doit être testée de nouveau. Puisqu'il est très rare que j'arrive à tout corriger dans un seul essai, il est plus pratique d'attendre pour téléverser le fichier HTML sans erreurs qu'une seule fois vers le site web.

Nu Html Checker - checking local file

Pour vérifier la copie locale d'une page web, il faut utiliser la méthode file upload puis cliquer sur le bouton Parcourir pour repérer le fichier dans l'arborescence des fichiers de l'ordinateur. Dans mon cas, le fichier index.html se trouve dans le répertoire /var/www/html/michel/.

On peut voir que j'ai coché l'option Show source. Par conséquent, lorsque la vérification est complétée les erreurs et les avertissements s'affichent, mais en plus, le code correspondant sera affiché en surbrillance dans la source HTML ce qui facilite grandement la localisation des fautes dans le fichier source GTML.

Installation locale du vérificateur toc

Le vérificateur de W3C peut être installé localement, mais il nécessite un environnement d'exécution Java. Il doit s'agir de la version 8 ou plus récente. Il se trouve que la version 11 de openjdk est installée sur mon ordinateur de bureau.

michel@hp:~$ apt list --installed | grep openjdk WARNING: apt does not have a stable CLI interface. Use with caution in scripts. openjdk-11-jre-headless/focal-updates,focal-security,now 11.0.11+9-0ubuntu2~20.04 amd64 [installé] openjdk-11-jre/focal-updates,focal-security,now 11.0.11+9-0ubuntu2~20.04 amd64 [installé]

Si cet environnement n'est pas installé, la situation est rapidement corrigée avec le gestionnaire de paquets habituel.

michel@hp:~$ sudo apt-get install openjdk-11-jre-headless

Obtenez la dernière version de Nu Html Checker sur https://github.com/validator/validator/releases. Actuellement c'est la version 20.6.30. J'ai copié le fichier d'archive zip dans un sous-répertoire de mon répertoire de téléchargement.

michel@hp:~$ cd Téléchargements michel@hp:~/Téléchargements$ mkdir vnu michel@hp:~/Téléchargements$ cd vnu michel@hp:~/Téléchargements/vnu$ wget https://github.com/validator/validator/releases/download/20.6.30/vnu.jar_20.6.30.zip ... 2021-11-11 12:02:13 (36,5 MB/s) - «vnu.jar_20.6.30.zip» enregistré [28942603/28942603]

J'ai ensuite extrait le contenu de l'archive dans le répertoire binaire local ~/.local/bin de mon répertoire personnel.

michel@hp:~/Téléchargements/vnu$ unzip vnu.jar_20.6.30.zip -d ~/.local/bin Archive: vnu.jar_20.6.30.zip creating: /home/michel/.local/bin/dist/ extracting: /home/michel/.local/bin/dist/index.html extracting: /home/michel/.local/bin/dist/LICENSE extracting: /home/michel/.local/bin/dist/CHANGELOG.md extracting: /home/michel/.local/bin/dist/README.md extracting: /home/michel/.local/bin/dist/vnu.jar michel@hp:~/Téléchargements/vnu$ cd michel@hp:~$ mv .local/bin/dist .local/bin/vnu

Cette copie locale du vérificateur peut être utilisée immédiatement comme indiqué dans la section suivante. Cependant, si vous souhaitez démarrer le serveur web local du vérificateur à partir du menu du système, il faut créer un fichier .desktop. Dans ce cas, je suggère d'obtenir une copie de l'icône de Nu Html Checker pour compléter l'affichage dans le menu.

michel@hp:~$ wget https://validator.w3.org/nu/icon.png -O .local/bin/vnu/icon.png ... 2021-11-14 18:56:08 (59,7 MB/s) - «.local/bin/vnu/icon.png» enregistré [621/621]

Créez ensuite un fichier .desktop pour ajouter le vérificateur au menu du système Mint.

michel@hp:~$ nano .local/share/applications/vNuChecker.desktop

Voici le contenu du fichier.

#!/usr/bin/env xdg-open [Desktop Entry] Version=21.11.13 Encoding=UTF-8 Type=Application Exec=/usr/bin/java -Dnu.validator.servlet.bind-address=127.0.0.1 -cp .local/bin/vnu/vnu.jar nu.validator.servlet.Main 8888 Icon=/home/michel/.local/bin/vnu/icon.png Name=Nu Html Checker Categories=WebApp;Development; Terminal=true Comment=Validate HTML source Comment[fr_CA]=Valider source HTML

Remarquez la ligne Terminal=true. Habituellement, le terminal est masqué, mais ici il sera affiché puisque c'est le moyen le plus simple que j'ai trouvé pour arrêter le vérificateur après son utilisation. Sinon, le processus reste en arrière-plan jusqu'à ce qu'il soit explicitement tué ou que l'ordinateur soit redémarré.

Vérification locale toc

Si l'on a pas créé un enregistrement dans le système de menu comme décrit ci-dessus, on peut démarrer le serveur web de Nu Html Checker sur l'ordinateur de bureau à partir d'un terminal et saisissant la commande suivante à l'invite du système. Typiquement, il y a plusieurs façon de lancer un terminal On lance un terminal à partir du menu système ou avec le raccourci clavier AltCtrlT

michel@hp:~$ java -cp ~/.local/bin/vnu/vnu.jar nu.validator.servlet.Main 8888 nu.validator.servlet.VerifierServletTransaction - Starting static initializer. ... Checker service started at http://0.0.0.0:8888/

Si l'on a créé un enregistrement dans le système de menu, alors aussi l'utiliser pour lancer Nu Html Checker. Trouvez l'enregistrement du vérificateur dans la catégorie Programmation ou recherchez Nu, Valider, ou Checker etc. et cliquez sur le bon enregistrement. Une fenêtre de terminal s'ouvrira et le programme Java sera lancé.

nu.validator.servlet.VerifierServletTransaction - Starting static initializer. ... Checker service started at http://127.0.0.1:8888/

Une comparaison de la ligne de commande entrée à la main et celle spécifiée dans le fichier .desktop expliquera la différence dans l'adresse IP du service.

Ouvrez Nu Html Checker dans un navigateur sur le même ordinateur à l'aide de l'URL suivante http://localhost:8888. La même page que celle trouvée sur le site de W3C sera affichée.

Nu Html Checker - local service

Puisque le vérificateur est installé sur l'ordinateur de bureau, il peut accéder au serveur web de ce dernier ce qui veut dire qu'on peut utiliser la méthode address pour accéder aux copies locales des pages web tel qu'illustré ci-dessus. On peut aussi utiliser la méthode file upload. Comme précédemment, j'active toujours l'option Show source.

Si le vérificateur a été démarré depuis le menu du système, le processus fonctionne toujours même après avoir coupé la connexion avec le serveur web de l'application. Il faut fermer le terminal d'où a été lancé le vérificateur en appuyant sur la combinaison de touches CtrlC.

... python ./checker.py --bind-address 192.168.0.100 run java -Dnu.validator.servlet.bind-address=192.168.0.100 -cp vnu.jar nu.validator.servlet.Main 8888 vnu-runtime-image/bin/java -Dnu.validator.servlet.bind-address=192.168.0.100 nu.validator.servlet.Main 8888 vnu-runtime-image\bin\java.exe -Dnu.validator.servlet.bind-address=192.168.0.100 nu.validator.servlet.Main 8888 Checker service started at http://127.0.0.1:8888/ nu.validator.xml.PrudentHttpEntityResolver - http://localhost/michel/program/misc/webclean_fr.html ... ^C

Vérification à partir de la ligne de commande toc

Il est possible de vérifier plusieurs fichiers à la fois lors de l'utilisation de Nu Html Checker à partir de la ligne de commande.

michel@hp:~$ java -jar ~/.local/bin/vnu/vnu.jar http://localhost/michel/about_fr.html http://localhost/michel/index_en.html http://localhost/michel/index_fr.html "file:http://localhost/michel/about_fr.html":60.1-60.4: error: No “p” element in scope but a “p” end tag seen. "file:http://localhost/michel/about_fr.html":89.1-89.4: error: No “p” element in scope but a “p” end tag seen. "file:http://localhost/michel/about_fr.html":137.78-137.83: error: Named character reference was not terminated by a semicolon. (Or “&” should have been escaped as “&”.) "file:http://localhost/michel/about_fr.html":178.1-178.7: error: Stray end tag “code”.

Les fichiers HTML peuvent être transmis directement au script au lieu de passer par le serveur web comme indiqué ci-dessus.

michel@hp:~$ java -jar ~/.local/bin/vnu/vnu.jar /var/www/html/michel/about_fr.html /var/www/html/michel/index_en.html /var/www/html/michel/index_fr.html "file:/var/www/html/michel/about_fr.html":60.1-60.4: error: No “p” element in scope but a “p” end tag seen. "file:/var/www/html/michel/about_fr.html":89.1-89.4: error: No “p” element in scope but a “p” end tag seen. "file:/var/www/html/michel/about_fr.html":137.78-137.83: error: Named character reference was not terminated by a semicolon. (Or “&” should have been escaped as “&”.) "file:/var/www/html/michel/about_fr.html":178.1-178.7: error: Stray end tag “code”.

S'il n'y a pas de sortie, comme dans les cas des fichiers index_xx.html, c'est qu'il n'y a pas d'erreur selon le vérificateur. En revanche, about_fr.html contient des erreurs qui sont clairement identifiées avec la ligne et les colonnes où elles se trouvent. La vérification de tous les fichiers d'un répertoire se fait facilement. Mais attention c'est récursif !

michel@hp:~$ java -jar ~/.local/bin/vnu/vnu.jar --skip-non-html /var/www/html/michel/program/misc/

Avertissement :

Quand le répertoire ne contient pas de fichier HTML par défaut (typiquement nommé index.html), on ne doit pas utiliser le serveur web du système local pour accéder aux fichiers HTML.

michel@hp:~$ java -jar ~/.local/bin/vnu/vnu.jar --skip-non-html --stdout /var/www/html/michel/program/misc/ | wc -l 648 michel@hp:~$ java -jar ~/.local/bin/vnu/vnu.jar --skip-non-html --stdout http://localhost/michel/program/misc/ | wc -l 2

Comment peut-il n'y avoir que 2 erreurs ou avertissements dans le second cas ? C'est parce que le serveur web local a transmis la page d'erreur 403 au vérificateur bloquant l'accès aux fichiers HTML.

Notez l'ajout de l'option --stdout, sinon les messages d'erreur et d'avertissement auraient été acheminés vers stderr sans que wc puisse les compter.

Au lieu d'espérer qu'une vérification récursive testera tous les fichiers, je préfère fournir la liste des fichiers à l'outil. Malheureusement, je n'ai pas trouvé de moyen de le faire et j'ai dû écrire un script bash qui parcourt chaque nom de fichier de la liste en le transmettant au vérificateur.

#!/bin/bash # Nu Html Checker Runner usage() { echo "Usage:" echo " $(basename $0) -h | file" } if [ "$#" -ne 1 ]; then echo "Error: missing parameter" usage exit 1 fi if [ $1 == "-h" ]; then usage exit 0 fi Lines=$(cat $1) for Line in $Lines do # java -jar ~/.local/bin/vnu/vnu.jar --stdout --verbose "$Line" java -jar ~/.local/bin/vnu/vnu.jar --stdout "$Line" done

Ajoutez l'option --verbose lors de l'exécution du vérificateur si vous souhaitez voir le nom du fichier en cours de vérification. Comme indiqué, seules les erreurs seront affichées sur le terminal. Comme auparavant, j'ai enregistré ce script dans le répertoire ~.local/bin/répertoire et l' ai rendu exécutable avec la commande chmod +x nvu.

Pour tester le script, j'ai créé un fichier, top_level.txt, avec le chemin complet de tous les fichiers HTML dans /michel/, qui est le répertoire de niveau supérieur de mon site web personnel.

/var/www/html/michel/about_en.html /var/www/html/michel/about_fr.html /var/www/html/michel/archives_en.html /var/www/html/michel/archives_fr.html /var/www/html/michel/downloads_en.html /var/www/html/michel/downloads_fr.html /var/www/html/michel/index_en.html /var/www/html/michel/index_fr.html /var/www/html/michel/major_incident_en.html /var/www/html/michel/major_incident_fr.html

Le script a exécuté la copie locale de Nu Html Checker sur chaque fichier de cette liste et a signalé des erreurs.

michel@hp:~$ nvu top_level.txt "file:/var/www/html/michel/major_incident_en.html":54.1-54.6: error: Stray end tag “div”. "file:/var/www/html/michel/major_incident_en.html":532.11-532.16: error: Saw “<” when expecting an attribute name. Probable cause: Missing “>” immediately before. "file:/var/www/html/michel/major_incident_en.html":532.11-532.18: error: End tag had attributes. "file:/var/www/html/michel/major_incident_en.html":532.11-532.18: error: Stray end tag “b,”. "file:/var/www/html/michel/major_incident_en.html":542.1-542.6: error: Stray end tag “div”. "file:/var/www/html/michel/major_incident_fr.html":54.1-54.6: error: Stray end tag “div”. "file:/var/www/html/michel/major_incident_fr.html":533.1-533.6: error: Stray end tag “div”.

L'exécution du script sur tous les fichiers du site web a donné un nombre total d'erreurs décourageant.

michel@hp:~$ nvu list2.txt | wc -l 19772

Pour plaire à ceux qui ne cessent de parler de l'élégance et de la puissance de Linux, terminons avec une commande bash qui fait la même chose que le script nvu.

michel@hp:~$ find /var/www/html/michel/ -type f -name '*html' -not \( -path "*/local/*" -o -path "*/dnld/*" \) -exec java -jar ~/.local/bin/vnu/vnu.jar --stdout {} \; > result_find.txt

Étant incapable de me souvenir de quelque chose d'aussi complexe, il me faudrait consigner ce commandement à un fichier bash ce qui reviendrait à créer une version de nvu plus cryptique.

Vérification des fichiers CSS toc

Nu Html Checker peut vérifier les documents HTML, CSS et SVG. Cependant, pour vérifier les feuilles de style CSS, je préfère utiliser CSS Validation Service. La raison de cette préférence est que ce service renvoie une version corrigée du fichier soumis. C'est une application basée sur le web mais il n'était pas important pour moi de voir si cet outil peut être installé localement. Je n'ai que 3 feuilles de style CSS et elles sont rarement modifiées.

Vérification des liens hypertexte avec LinkChecker toc

Le lien invalide est un problème épineux pour les utilisateurs et les créateurs de contenu web. Il existe deux types d'erreurs liées aux hyperliens sur mon site : celles qui sont entièrement de ma faute et celles créées par d'autres. La plupart des erreurs auto-infligées sont des fautes d'orthographe stupides, de simples inversions de lettres lors de la saisie d'une URL ou des changements précipités dans le nom d'un attribut id lors de la création de la table des matières au début dans la plupart des billets substantiels. Une vérification minutieuse avant de publier une nouvelle page web devrait éliminer ce problème, mais c'est rarement le cas. L'autre type d'erreur courant est la disparition du site visé. En 1998, Sir Tim Berners-Lee a énuméré les justifications de certains qui modifient les adresses pour dénoncer leur invalidité : Cool URIs don't change. Tous (et je fais partie de ce groupe malheureusement) n'ayant pas reçu le message de nombreux liens vers des ressources externes finissent par pointer vers quelque chose qui n'existe plus ou qui a reçu une nouvelle adresse. Essayez ce lien https://www.google.fr/introuvable.html pour voir comment Google signale une URL introuvable (erreur 404). Ma propre version https://sigmdel.ca/michel/introuvable.html est encore plus laconique. L'expérience a montré que la correction des erreurs 404 sur un site distant peut grugé du temps, car rien n'indique si la ressource recherchée a été entièrement supprimée ou si elle reste disponible sur le même hôte, mais avec une URL différente ou qu'elle se trouve sur un hôte différent. Ce dernier est une conséquence inévitable déplacent de site vers un autre fournisseur d'hébergement web par des créateurs individuels qui n'ont pas de domaine personnel.

De nombreux vérificateurs de liens sont disponibles, mais certains ne fonctionnent pas pour moi à cause de quelques décisions non optimales lors de la création de ce site. L'une d'entre elles était que j'ai décidé d'utiliser des URL relatives au lieu d'absolues pour les liens vers d'autres documents sur mon site. Bien qu'il existe des arguments contre cette pratique (Why relative URLs should be forbidden for web developers) et que le vérificateur de liens W3C Link Checker ne fonctionne qu'avec des URL absolues, cela n'aurait pas eu beaucoup d'impact si je n'avais pas également décidé d'utiliser l'élément HTML <base href="/michel/">. Cela semble dérouter de nombreux vérificateurs de liens, en particulier en ce qui concerne les attributs id utilisés dans les liens vers des positions spécifiques dans un document HTML.

Heureusement, LinkChecker, un script Python 3, peut gérer les liens sur mon site. La version 9.4.0 est disponible sous forme de paquet dans Debian Buster tandis que la dernière version (10.0.1) est disponible dans Debian Bullseye and Sid. Puisque ces paquets ne sont malheureusement pas disponibles dans le référentiel standard de Mint 20.1, j'ai décidé d'installer le script dans un environnement virtuel, mais il existe d'autres méthodes d'installer LinkChecker. En fait la procéder est simple et ne compte que trois étapes : créer un environnement virtuel, l'activer, puis y installer le paquet avec pip (en fait, pip3 puisque l'environnement virtuel est créé avec Python 3).

michel@hp:~$ mkvenv linkchecker creating virtual environment /home/michel/linkchecker updating virtual environment /home/michel/linkchecker michel@hp:~$ ve linkchecker (linkchecker) michel@hp:~$ cd linkchecker (linkchecker) michel@hp:~/linkchecker$ pip install git+https://github.com/linkchecker/linkchecker.git Collecting git+https://github.com/linkchecker/linkchecker.git ... Successfully built LinkChecker Installing collected packages: urllib3, soupsieve, idna, charset-normalizer, certifi, requests, pyxdg, dnspython, beautifulsoup4, LinkChecker Successfully installed LinkChecker-10.0.1 beautifulsoup4-4.10.0 certifi-2021.10.8 charset-normalizer-2.0.7 dnspython-2.1.0 idna-3.3 pyxdg-0.27 requests-2.26.0 soupsieve-2.3.1 urllib3-1.26.7

L'étape suivante consistait à configurer le fichier de configuration qui est appelé linkcheckerrc et qui doit se trouver dans un sous-répertoire nommé .linkchecker du répertoire personnel de l'utilisateur.

(linkchecker) michel@hp:~$ mkdir .linkchecker (linkchecker) michel@hp:~$ nano .linkchecker/linkcheckerrc

C'est un fichier INI avec des en-têtes de section entre crochets []. Chaque section contient un nombre variable (pouvant être zéro) de paramètres de configuration présentés sous la forme paramètre = valeur.

[checking] # no recursion recursionlevel=1 [filtering] # Check all links outside the web site, no recursion no matter the previous setting checkextern=1 [output] # Send the HTML formatted output to stdout (probably best to redirect to a file) log=html # Uncomment for information about each link, otherwise only problems are shown #verbose=1 # Enable checking links to local ID [AnchorCheck]

Le paramètre de configuration recursionlevel=1 dans la section [checking] garantira que seuls les liens dans le fichier fourni sur la ligne de commande sont vérifiés. Sans cela, le comportement par défaut de LinkChecker serait de suivre chaque lien HTML pour vérifier les liens contenus dans le fichier trouvé et de continuer ainsi de façon récursive. Cette récursivité illimitée serait souhaitable lors de la vérification de tous les liens d'un site web. Cependant cela peut prendre beaucoup de temps et ce serait très décourageant lorsqu'on ne souhaite que vérifier une page sur le point d'être ajoutée à un site.

Le paramètre suivant, checkextern=1 dans la section [filtering], garantit que tous les liens vers des ressources en dehors du site web sont vérifiés. Cependant, il n'y a aucune vérification récursive des liens dans les fichiers HTML externes, quelle que soit la valeur du paramètre recursionlevel.

La sortie HTML codée par couleur, définie avec le paramètre log=html dans la section [output], permet de repérer très facilement les erreurs, en particulier lorsque la sortie détaillée est activée. Le paramètre verbose=1 dans la même section est un bon moyen de vérifier que le vérificateur examine tous les liens dans le fichier source HTML. Comme on peut voir, ce paramètre n'est pas défini normalement.

Enfin, l'en-tête de section [AnchorCheck] qui active le plugiciel AnchorCheck qui est important pour mon site. Cela garantira que les liens internes des documents vers les éléments avec l'attribut id sont vérifiés. Il existe d'autres plugiciels, notamment la vérification de chaque fichier avec Nu Html Checker. Tous les plugiciels peuvent être répertoriés.

(linkchecker) michel@hp:~$ linkchecker --list-plugins INFO linkcheck.cmdline 2021-11-16 12:58:02,135 MainThread Checking intern URLs only; use --check-extern to check extern URLs. AnchorCheck Checks validity of HTML anchors. ...

La plupart des paramètres peuvent être définis avec des options sur la ligne de commande, à l'exception de l'activation des plug-ins qui ne peut être effectuée que dans le fichier de configuration. Les paramètres définis avec les options de ligne de commande ont priorité sur tous les paramètres définis dans le fichier de configuration et j'en profite dans ce qui suit. Voici une partie de la sortie lors de la vérification d'un fichier sur le site. Notez que l'option de ligne de commande -o text permet d'afficher plus facilement la sortie de LinkChecker ci-dessous. L'option remplace le paramètre log=html dans le fichier de configuration.

(linkchecker) michel@hp:~$ linkchecker -o text http://127.0.0.1/michel/program/misc/gfxfont_8bit_fr.html LinkChecker 10.0.1 Copyright (C) 2000-2016 Bastian Kleineidam, 2010-2021 LinkChecker Authors LinkChecker comes with ABSOLUTELY NO WARRANTY! This is free software, and you are welcome to redistribute it under certain conditions. Look at the file `LICENSE' within this distribution. Get the newest version at https://linkchecker.github.io/linkchecker/ Write comments and bugs to https://github.com/linkchecker/linkchecker/issues Start checking at 2021-11-12 18:52:01-003 URL `http://127.0.0.1/michel/program/misc/gfxfont_8bit_fr.html' Real URL http://127.0.0.1/michel/program/misc/gfxfont_8bit_fr.html Check time 0.044 seconds D/L time 0.000 seconds Size 60.89KB Result Valid: 200 OK URL `javascript:void(0)' Name `Citation originale' Parent URL http://127.0.0.1/michel/program/misc/gfxfont_8bit_fr.html, line 451, col 3 Base http://127.0.0.1/michel/ Real URL javascript:void(0) Info Javascript URL ignored. Result Valid: ignored ... URL `downloads_fr.html' Name `téléchargements' Parent URL http://127.0.0.1/michel/program/misc/gfxfont_8bit_fr.html, line 40, col 3 Base http://127.0.0.1/michel/ Real URL http://127.0.0.1/michel/downloads_fr.html Check time 3.294 seconds Result Valid: 200 OK ... URL `https://github.com/adafruit/Adafruit-GFX-Library/issues/64' Name `international character sets #64' Parent URL http://127.0.0.1/michel/program/misc/gfxfont_8bit_fr.html, line 509, col 38 Base http://127.0.0.1/michel/ Real URL https://github.com/adafruit/Adafruit-GFX-Library/issues/64 Check time 3.571 seconds Result Valid: 200 OK Statistics: Downloaded: 805.85KB. Content types: 15 image, 33 text, 0 video, 0 audio, 2 application, 0 mail and 1 other. URL lengths: min=18, max=114, avg=50. That's it. 51 links in 53 URLs checked. 1 warning found. 0 errors found. Stopped checking at 2021-11-12 19:15:13-003 (14 seconds)

Dans l'exemple suivant, un ancien billet est testé sans modifications des paramètres du fichier de configuration présenté ci-dessus. La sortie vers stdout est redirigée vers un fichier, mais les rapports de progression de la vérification ne sont pas redirigés vers ce fichier et sont affichés à l'écran.

(linkchecker) michel@hp:~$ linkchecker http://localhost/michel/ha/x10/future_en.html > linkchecker_result.html 10 threads active, 10 links queued, 3 links in 23 URLs checked, runtime 1 seconds 5 threads active, 0 links queued, 18 links in 28 URLs checked, runtime 6 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 11 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 16 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 21 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 26 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 31 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 36 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 41 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 46 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 51 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 56 seconds 1 thread active, 0 links queued, 22 links in 33 URLs checked, runtime 1 minute, 1 seconds

Les résultats peuvent être consultés. Comme l'option verbose n'était pas activée, seuls les avertissements (il n'y en avait pas) et les erreurs (il y en avait deux) sont affichés dans le fichier de résultats. Le programme a vérifié 23 liens dont beaucoup renvoyaient à d'autres pages du site web. Après 10 secondes environ, tous les liens sauf un avaient été vérifiés. L'un d'entre eux a engendré une erreur 404, ce qui signifie que le fichier externe n'existe plus. Le dernier lien a expiré. La valeur de délai d'attente par défaut est de 60 secondes, ce qui explique pourquoi le programme a fonctionné pendant un peu plus d'une minute.

Pour tester l'ensemble de mon site, j'ai chronométré la commande suivante.

michel@hp:~$ ve linkchecker (linkchecker) michel@hp:~$ time linkchecker -r -1 http://localhost/michel/index_fr.html > linkcheck_all.html 10 threads active, 41 links queued, 3 links in 54 URLs checked, runtime 1 seconds ... 10 threads active, 4 links queued, 4308 links in 4735 URLs checked, runtime 18 minutes, 11 seconds 1 thread active, 0 links queued, 4331 links in 4749 URLs checked, runtime 18 minutes, 16 seconds real 18m18,020s user 2m29,309s sys 0m2,137s (linkchecker) michel@hp:~$

Notez la valeur négative de l'option -r -1 sur la ligne de commande qui correspond au paramètre recursionlevel. Cette valeur négative signifie que tous les liens sur le site web seront vérifiés de manière récursive. J'espère que le programme conserve une liste des pages visitées pour éviter les boucles infinies ! De toute évidence, cet écueil a été évité, car au total, plus de quatre mille liens ont été vérifiés en un peu plus de 18 minutes, avec 126 avertissements principalement concernant des noms d'ancre invalides et 102 erreurs telles que l'erreur 404 de fichier manquant.

Que se passe-t-il si la récursivité est désactivée et que LinkChecker reçoit la liste des fichiers à vérifier ? De manière explicite, le vérificateur obtiendra sa liste d'URL à vérifier à partir du fichier list.txt redirigé vers stdin.

(linkchecker) michel@hp:~$ time linkchecker --stdin <list.txt >linkcheck_list.html 10 threads active, 414 links queued, 3 links in 427 URLs checked, runtime 1 seconds 10 threads active, 568 links queued, 18 links in 596 URLs checked, runtime 6 seconds ... 1 thread active, 0 links queued, 4708 links in 5142 URLs checked, runtime 19 minutes, 51 seconds 1 thread active, 0 links queued, 4708 links in 5142 URLs checked, runtime 19 minutes, 56 seconds real 20m1,610s user 2m11,465s sys 0m2,457s (linkchecker) michel@hp:~$

Cette vérification exige un peu plus de temps et plus de liens sont vérifiés.

michel@hp:~$ cat list.txt http://localhost/michel/about_fr.html http://localhost/michel/program/misc/gfxfont_8bit_fr.html http://localhost/michel/index_en.html ...

Puisque list.txt contient tous les fichiers HTML dans les répertoires du site, cette différence pourrait indiquer qu'il y a des fichiers orphelins qu'on ne peut pas atteindre depuis les autres fichiers du site. Il se peut aussi que cette différence soit due à des erreurs dans les liens. Quoi qu'il en soit, les fichiers archives_en.html et archives_fr.html devraient contenir des liens vers toutes les pages HTML du site.

Pour clore la discussion sur cet excellent outil, deux choses méritent d'être mentionnées. Il y a un léger problème avec Unicode et même avec la spécification de l'encodage utf_8, les points de code au-dessus de l'ASCII 126 ne s'afficheront pas correctement. Il s'agit d'un problème connu (Encoding strings doesn't work #533), mais cela ne réduit pas la valeur du programme. Sachez également que la version originale de LinkChecker créée par Bastian Kleineidam (wummel) est toujours disponible sur Github. Il n'y a eu aucune mise à jour du code depuis juin 2016 qui ne fonctionne qu'avec Python 2.7.x. C'est un peu dommage qu'il n'y ait aucune mention de la nouvelle version nulle part que j'ai pu trouver sur ces deux pages.

Stratégie toc

Plus de 19 000 erreurs de syntaxe et plus de 100 hyperliens invalides semblent être une tâche écrasante. En examinant les erreurs, j'ai constaté que 61% sont du type « utilisez CSS ». Heureusement les navigateurs web continuent d'afficher correctement des attributs désuets comme font, cellspacing et width. Je voudrais quand même corriger ces problèmes même s'il n'y a pas urgence. Pour mieux cerner l'ampleur des erreurs syntaxiques, j'ai modifié le script nvu.

#!/bin/bash # Nu Html Checker Runner II usage() { echo "Usage:" echo " $(basename $0) -h | file" } if [ "$#" -ne 1 ]; then echo "Error: missing parameter" usage exit 1 fi if [ $1 == "-h" ]; then usage exit 0 fi Lines=$(cat $1) for Line in $Lines do count=`java -jar ~/.local/bin/vnu/vnu.jar --stdout "$Line" | wc -l` if [ "$count" -ne 0 ]; then echo $count $Line fi done
michel@hp:~$ nvu2 list2.txt > results.txt michel@hp:~$ cat list2.txt | wc -l 321 michel@hp:~$ cat result.txt | wc -l 295

Seuls 8 % des fichiers HTML du site ont passé le contrôle de syntaxe. De toute évidence, j'ai surestimé ma diligence dans la vérification des fichiers. J'ai importé result.txt dans une feuille de calcul pour découvrir que seulement 10 fichiers contenaient la moitié des erreurs et que 23 fichiers représentaient les deux tiers des erreurs. Cette distribution très asymétrique des erreurs peut être en grande partie attribuable à l'effet d'entraînement de certaines erreurs.

Par où commencer ? Jusqu'à présent, j'ai supprimé toutes les erreurs de syntaxe signalées par Nu Html Checker pour les 10 fichiers à la racine de mon site web personnel soit sigmdel.ca/michel. Il est logique que les fichiers atteints en cliquant sur n'importe quelle icône en haut de chaque page soient sans erreur. Mais où aller à partir de là ? Dois-je commencer par les 10 pages qui représentent la moitié des erreurs de syntaxe ou faut-il vérifier dans un premier temps les 10 pages les plus visitées ?

Encore une fois, le W3C fournit un outil pour aider à établir une priorité. Appelé Log Validator, il s'agit d'un « outil gratuit et simple qui procède étape par étape pour améliorer considérablement la qualité de votre site web. Trouvez les documents invalides les plus populaires, les liens rompus, etc., et hiérarchisez le travail pour les réparer. ». Le W3C va plus loin et fournit des instructions : Making your website valid: a step by step guide.

J'ai installé l'outil dans mon compte avec mon hébergeur. Les détails sont dans W3C LogValidator in cPanel. Les premiers résultats de l'utilisation de cet outil ont été pour le moins décevants.

Donc pour commencer à supprimer les erreurs sur ce site, je commencerai par les pages les plus visitées, puis je regarderai les pires pages. Je ne parierais pas que j'arriverai à vérifier chaque fichier du site et à éliminer toutes les erreurs avant que je mette un terme à cette aventure dans le monde de l'autopublication sur le web.

W3C LogValidator in cPanel->