Archiver un site web créé dans Drupal 8 en HTML ?

Que faire avec un ancien site web obsolète que vous souhaitez garder en ligne ? La solution parfaite est de l'archiver en code HTML pur. Nous allons le démontrer à l'exemple du site drupalcamp.pl créé dans Droopler, basé sur Drupal.

Pourquoi archiver les pages ?

Parfois, les sites web ont une date d'expiration. Cela peut résulter du cycle de vie de la technologie utilisée pour la construire ou simplement parce que le site a été créé pour un événement ou une occasion spéciale. Lorsque vous organisez un festival de musique, par exemple, le site web n'est plus à jour ni nécessaire après la fin de cet événement. Lorsque vous avez des sites web oubliés depuis longtemps sur votre serveur, leur code peut être tellement obsolète qu'il représentera une menace à l'avenir. Si, pour une raison quelconque, vous souhaitez conserver vos sites sur Internet, vous devez prendre en compte les coûts de leur maintenance et de leur mise à jour constantes.

Quels sont les coûts d'un site web inutilisé ?

Le coût de maintenance dépend en grande partie de la technologie utilisée. Concentrons-nous sur Drupal 8 puisqu'il s'agit de l'un des CMS les plus sécurisés disponibles sur le marché. Des mises à jour de D8 sont publiées tous les mois, et tous les six mois une version contenant de nouvelles fonctionnalités est publiée. Cela signifie que vous devez installer une nouvelle version de Drupal 12 fois par an et tester notre site web pour voir s'il fonctionne toujours, afin de rester à jour avec les mises à jour. Nous savons par expérience que cela peut être très chronophage. Alternativement, vous pouvez acheter un support drupal, mais s'il n'y a pas de justification commerciale alors ce sera un coût que vous encourez inutilement.

D'un autre côté, si vous décidez de ne pas faire la mise à niveau, votre site web est maintenant à risque d'être attaqué et constitue une menace pour les autres sites web de votre serveur. Les lacunes au niveau de la sécurité peuvent entraîner des coûts bien plus élevés que la mise à jour continue de votre code.

La question se pose – comment éviter les coûts de maintenance et garder le site en ligne ? Un excellent compromis entre sentiment et rentabilité est la conversion en code HTML pur.

Quels sont les avantages et inconvénients du HTML pur ?

Le déploiement de sites web écrits en HTML pur est en quelque sorte un retour aux sources. À l'ère des CMS avancés, peu de gens se souviennent qu'un site peut être créé sans l'utilisation de langages interprétés côté serveur, comme PHP.

Pourquoi l'écriture de pages uniquement en HTML a-t-elle été oubliée ?

• En raison des difficultés de mise à jour de leur contenu.
• Parce qu'il n'est pas possible de réutiliser le code pour des éléments globaux (comme l'en-tête, le menu principal, le pied de page).
• En raison de la nature statique du HTML, qui rend difficile la création de pages administratives.

Alors pourquoi convertir un site Drupal 8 inutilisé en HTML pur ?

• Cela entraînera une augmentation rapide de la vitesse de fonctionnement de toutes les sous-pages, y compris celles qui étaient les plus lentes jusqu'à présent.
• Il sera très difficile d'attaquer le site si vous configurez correctement le serveur.
• La mise à jour du code deviendra complètement inutile, le coût de maintenance sera pratiquement nul.

Quelles seront les limitations d'un site converti en HTML ?

• Les modifications de contenu deviendront plus chronophages. Le développeur les intègrera dans une copie locale et générera ensuite la version HTML pour publication sur le serveur.
• Les éléments dynamiques tels que les formulaires cesseront de fonctionner.

Comment adapter un site pour l'archivage ?

Tous les sites ne sont pas immédiatement adaptés à l'archivage. Tout d'abord, vous devez vous assurer qu'aucune des sous-pages ne contient d'éléments nécessitant des scripts PHP pour fonctionner :

• Formulaires de contact (ils peuvent être remplacés par des Google Forms intégrés).
• Moteurs de recherche (ils peuvent être remplacés par la recherche Google sur le site).
• Filtres exposés des vues.
• AJAX dans les vues.

Il est également nécessaire de désactiver les messages d'erreur envoyés par le serveur – surtout lors de la copie d'un site depuis localhost. Lors de l'archivage, vous devriez utiliser des paramètres aussi proches que possible de ceux de production, y compris l'agrégation CSS/JS et l'absence d'informations de diagnostic supplémentaires générées par Twig.

Au début de l'article, nous avons promis de décrire la conversion en HTML, basée sur un exemple réel. Par conséquent, nous allons présenter la méthode d'archivage du site drupalcamp.pl, dédié à la conférence DrupalCamp 2018 organisée par nous. C'est un événement cyclique, mais chaque année nous préparons un site complètement nouveau. Une fois que DrupalCamp a eu lieu, nous laissons cette page en souvenir, archivée en HTML à une adresse distincte.

Quelles préparations a nécessité drupalcamp.pl ? Tout d'abord, nous avons supprimé les sous-pages avec les formulaires, qui n'étaient plus nécessaires, puisque la conférence est déjà terminée. Nous nous sommes assurer que toutes les vues fonctionnaient sans AJAX sur les sous-pages de programme. Nous avons également réalisé un audit rapide de JS pour éliminer les problèmes de code potentiels lorsque PHP est désactivé.

Le processus d'archivage

Nous utilisons le logiciel httrack, qui est disponible sous la licence GNU GPL3, afin d'archiver automatiquement les pages. Il est disponible pour Windows, Linux, OSX et Android. Nous utilisons httrack via une console Linux. Il y a beaucoup de commutateurs et d'options disponibles dans la documentation, voici notre commande pour faire une copie 1:1 d'un site web, tout en maintenant la structure des liens :

httrack http://example.com -O output_dir --disable-security-limits --max-rate=99999999999 -K3 -X -%P -wqQ%v --robots=0 -N "%h%p/%n.%t"

• --disable-security-limits - désactive les limites de transfert intégrées, ceci est utile lorsque notre serveur local est la source.
• --max-rate - définit la vitesse de transmission maximale.
• -%P - tente de reconnaître tous les liens possibles vers des fichiers sur le site.
• -K3 - ne change pas les liens sur les pages.
• -N "%h%p/%n.%t" - ne change pas les noms de fichiers.
• -X - à la prochaine commande, supprime les fichiers de la version archivée qui ont été supprimés dans l'original.
• -wqQ%v - mode standard, silencieux, avec une liste de fichiers traités à l'écran.

L'image de la page obtenue n'est pas encore complètement finie. Les sous-pages se trouvent dans des fichiers tels que à-propos.html, au lieu de à-propos/index.html. Un simple script corrigera ce problème :

#!/bin/bash
for f in $(find output_dir/example.com -name "*.html" -type f); do 
	if [[ $f = *"/index.html" ]]; then
		echo "Omitting $f"		
	else
		echo "Processing $f"
		mkdir "${f%.html}"
		mv $f "${f%.html}/index.html"
	fi
done

La copie créée de cette manière sera indiscernable de l'original pour l'observateur. Ceci est important pour la conservation des positions existantes dans les moteurs de recherche Internet.

Compatibilité de Httrack avec Drupal

Drupal 8 n'est pas entièrement compatible avec httrack. Le problème principal concerne les images réactives présentées via la balise . Une conversion correcte en HTML nécessite de fournir à httrack des indications pour des téléchargements supplémentaires.

Le site drupalcamp.pl que nous avons archivé est basé sur Droopler, une distribution interne et gratuite de Drupal 8. Dans la version 1.3 de Droopler, nous avons mis en place une prise en charge complète pour httrack, ce qui aide à identifier et télécharger tous les fichiers graphiques utilisés sur le site.

Comment avons-nous "amélioré" la compatibilité avec httrack ? Nous avons utilisé une solution très simple sous la forme de hooks préparant une liste de fichiers à télécharger. Les indications pour le bot sont placées dans la section de la page, sous forme d'éléments successifs :

Ces éléments sont reconnus par httrack et téléchargés dans la copie. Grâce à cela, nous pouvons maintenir une réactivité complète des images. Le code excédentaire est généralement supprimé depuis la console à l'aide d'une expression régulière.

Résultats de la conversion

Le résultat de la conversion en HTML est très satisfaisant dans notre cas. Nous avons un dossier avec des fichiers d'une taille totale d'environ 20 Mo. Comme on pouvait s'y attendre, le temps d'accès à un fichier HTML est de quelques millisecondes, c'est-à-dire qu'il est négligeable. Il reste très bas même sous des charges lourdes. Jusqu'à présent, cette valeur sur le serveur de production a oscillé autour de 200ms (bien sûr pour les utilisateurs qui n'étaient pas connectés, avec le cache actif). Sous la charge, elle a augmenté à environ 700ms.

Nous avons vérifié l'exactitude de l'exportation en utilisant le logiciel Screaming Frog SEO Spider. Il n'a pas détecté d'erreurs 404, ce qui signifie que l'archivage a été effectué à 100% avec succès. De plus, les consoles des navigateurs ne montrent aucune erreur JS.

Il est attendu que dans les prochains jours, le site DrupalCamp 2018 sera enfin mis au repos et remplacé par une version HTML pure. De cette façon, nous éviterons le besoin de le mettre à jour et, par conséquent, nous n'encourrons pas de coûts supplémentaires. S'il devient nécessaire de faire des modifications de contenu, nous les ferons sur une version locale, basée sur Drupal, puis générerons automatiquement une nouvelle page HTML. Nous vous encourageons à profiter de notre expérience !