Eine Website, die in Drupal 8 erstellt wurde, in HTML archivieren?

Was tun mit einer alten, veralteten Website, die Sie online halten möchten? Die perfekte Lösung ist, sie in reinen HTML-Code zu archivieren. Wir werden dies am Beispiel einer drupalcamp.pl Website demonstrieren, die mit Droopler erstellt wurde und auf Drupal basiert.

Warum Seiten überhaupt archivieren?

Manchmal haben Websites ein Ablaufdatum. Dies kann auf den Lebenszyklus der verwendeten Technologie zurückzuführen sein oder einfach darauf, dass die Website für ein Ereignis oder einen speziellen Anlass erstellt wurde. Wenn Sie beispielsweise ein Musikfestival organisieren, ist die Website nach dessen Ende nicht mehr aktuell und notwendig. Wenn Sie längst vergessene Websites auf Ihrem Server haben, könnte ihr Code so veraltet sein, dass er in Zukunft zu einer Bedrohung wird. Wenn Sie aus irgendeinem Grund Ihre Websites im Internet behalten möchten, müssen Sie die Kosten für deren ständige Wartung und Aktualisierung berücksichtigen.

Welche Kosten fallen für eine ungenutzte Website an?

Die Wartungskosten hängen in hohem Maße von der verwendeten Technologie ab. Fokussieren wir uns auf Drupal 8, da es eines der sichersten CMS auf dem Markt ist. Updates für D8 werden monatlich veröffentlicht, und alle sechs Monate wird eine Version mit neuen Funktionalitäten veröffentlicht. Das bedeutet, dass Sie 12 Mal im Jahr eine neue Drupal-Version installieren müssen und unsere Website testen müssen, um sicherzustellen, dass sie noch funktioniert, damit Sie immer auf dem neuesten Stand sind. Aus Erfahrung wissen wir, dass dies sehr zeitaufwändig sein kann. Alternativ können Sie Drupal Support kaufen, aber wenn es keinen geschäftlichen Grund gibt, sind dies unnötige Kosten.

Andererseits, wenn Sie sich gegen ein Upgrade entscheiden, ist Ihre Website jetzt einem höheren Risiko von Angriffen ausgesetzt und stellt eine Bedrohung für andere Websites auf Ihrem Server dar. Sicherheitsmängel können zu weitaus höheren Kosten führen als die laufende Aktualisierung Ihres Codes.

Die Frage stellt sich – wie vermeidet man Wartungskosten und hält die Website online? Ein guter Kompromiss zwischen Nostalgie und Kosteneffizienz ist die Umwandlung in reinen HTML-Code.

Welche Vor- und Nachteile hat reines HTML?

Der Einsatz von Websites, die in reinem HTML geschrieben sind, ist gewissermaßen eine Rückkehr zu den Ursprüngen. Im Zeitalter fortgeschrittener CMS erinnert sich kaum jemand daran, dass eine Website ohne serverseitige Skriptsprachen erstellt werden kann, wie z.B. PHP.

Warum wurde die Erstellung von Seiten nur mit HTML vergessen?

• Aufgrund der Schwierigkeiten bei der Aktualisierung ihres Inhalts.
• Weil es nicht möglich ist, den Code für globale Elemente (wie Kopfzeile, Hauptmenü, Fußzeile) wiederzuverwenden.
• Wegen der statischen Natur von HTML, die es schwierig macht, Administrationsseiten zu erstellen.

Warum also eine ungenutzte Drupal 8 Website in reines HTML umwandeln?

• Dies wird zu einem rapiden Anstieg der Geschwindigkeit der Ausführung aller Unterseiten führen, einschließlich derjenigen, die bisher am langsamsten waren.
• Es wird sehr schwierig sein, die Website anzugreifen, wenn Sie den Server richtig konfigurieren.
• Die Aktualisierung des Codes wird völlig überflüssig, die Wartungskosten werden praktisch bei null liegen.

Welche Einschränkungen hat eine in HTML konvertierte Website?

• Änderungen am Inhalt werden zeitaufwändiger. Der Entwickler wird sie in eine lokale Kopie einfügen und dann die HTML-Version zur Veröffentlichung auf dem Server generieren.
• Dynamische Elemente wie Formulare werden nicht mehr funktionieren.

Wie passt man eine Website für die Archivierung an?

Nicht jede Website ist sofort für die Archivierung geeignet. Zunächst sollten Sie sicherstellen, dass keine der Unterseiten Elemente enthält, die PHP-Skripte erfordern:

• Kontaktformulare (sie können durch eingebettete Google-Formulare ersetzt werden).
• Suchmaschinen (sie können durch die Google-Suche auf der Website ersetzt werden).
• Views Exposed Filters.
• AJAX in Views.

Außerdem ist es notwendig, Fehlermeldungen des Servers zu deaktivieren – insbesondere beim Kopieren einer Website vom localhost. Während der Archivierung sollten Sie Einstellungen verwenden, die denen in der Produktion so ähnlich wie möglich sind, einschließlich CSS/JS-Aggregation und ohne zusätzliche Diagnoseinformationen, die von Twig erzeugt werden.

Am Anfang des Artikels haben wir versprochen, die Umwandlung zu HTML anhand eines realen Beispiels zu beschreiben. Daher werden wir die Methode der Archivierung der drupalcamp.pl Website präsentieren, die für die von uns organisierte DrupalCamp 2018 Konferenz erstellt wurde. Dies ist ein zyklisches Event, aber jedes folgende Jahr bereiten wir eine komplett neue Website vor. Sobald das DrupalCamp stattgefunden hat, behalten wir diese Seite als Souvenir, archiviert bei einer separaten Adresse, bei.

Welche Vorbereitungen erforderte drupalcamp.pl? Zunächst entfernten wir die Unterseiten mit den Formularen, die nicht mehr benötigt wurden, da die Konferenz bereits beendet ist. Wir stellten sicher, dass alle Views ohne AJAX auf den Programm-Unterseiten funktionierten. Wir führten außerdem eine schnelle JS-Prüfung durch, um potenzielle Code-Probleme zu eliminieren, wenn PHP deaktiviert ist.

Der Archivierungsprozess

Wir verwenden die httrack-Software, die unter der GNU GPL3-Lizenz erhältlich ist, um Seiten automatisch zu archivieren. Es ist für Windows, Linux, OSX und Android verfügbar. Wir nutzen httrack über eine Linux-Konsole. In der Dokumentation sind zahlreiche Schalter und Optionen verfügbar, hier ist unser Befehl, um eine 1:1 Kopie einer Website zu erstellen, während die Linkstruktur beibehalten wird:

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 - deaktiviert die integrierten Übertragungslimits, was nützlich ist, wenn unser lokaler Server die Quelle ist.
• --max-rate - legt die maximale Übertragungsgeschwindigkeit fest.
• -%P - versucht, alle möglichen Links zu Dateien auf der Website zu erkennen.
• -K3 - ändert die Links auf den Seiten nicht.
• -N "%h%p/%n.%t" - ändert Dateinamen nicht.
• -X - beim nächsten Befehl werden Dateien aus der archivierten Version gelöscht, die im Original gelöscht wurden.
• -wqQ%v - normaler Modus, still, mit einer Liste der verarbeiteten Dateien auf dem Bildschirm.

Das resultierende Seitenbild ist noch nicht komplett fertiggestellt. Die Unterseiten sind in Dateien wie about-us.html, anstelle von about-us/index.html. Ein einfaches Skript wird dieses Problem beheben:

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

Die auf diese Weise erstellte Kopie wird vom Beobachter nicht mehr vom Original zu unterscheiden sein. Dies ist wichtig für den Erhalt bestehender Positionen in den Internet-Suchmaschinen.

Httrack-Kompatibilität mit Drupal

Drupal 8 ist nicht vollständig mit httrack kompatibel. Das Hauptproblem sind die responsiven Bilder, die über das <picture>-Tag präsentiert werden. Eine ordnungsgemäße Umwandlung in HTML erfordert, dass httrack mit Hinweisen für zusätzliche Downloads versorgt wird.

Die drupalcamp.pl Website, die wir archiviert haben, basiert auf Droopler, einer hausinternen, kostenlosen Distribution von Drupal 8. In der Version 1.3 von Droopler haben wir die vollständige Unterstützung für httrack implementiert, die bei der Identifizierung und dem Download aller auf der Website verwendeten Grafikdateien hilft.

Wie haben wir die Kompatibilität mit httrack "verbessert"? Wir haben eine sehr einfache Lösung in Form von Hooks verwendet, die eine Liste der herunterzuladenden Dateien vorbereiten. Hinweise für den Bot werden in den <head>-Bereich der Seite eingefügt, als nachfolgende <link>-Elemente:

<link href="/sites/default/files/styles/responsive_image_2000/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=YkFsAytN" rel="droopler:c0527d:img0" />
<link href="/sites/default/files/styles/responsive_image_1200/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=OEsKzsbg" rel="droopler:c0527d:img1" />

Diese Elemente werden von httrack erkannt und in die Kopie heruntergeladen. Dank dessen können wir volle Responsivität der Bilder beibehalten. Der überschüssige Code wird normalerweise über die Konsole mittels eines regulären Ausdrucks gelöscht.

Ergebnisse der Konvertierung

Das Ergebnis der Konvertierung zu HTML ist in unserem Fall sehr zufriedenstellend. Wir haben einen Ordner mit Dateien von insgesamt etwa 20 MB. Wie zu erwarten war, beträgt die Zugriffszeit auf eine HTML-Datei nur wenige Millisekunden, was bedeutet, dass sie vernachlässigbar ist. Sie bleibt auch bei starker Belastung sehr niedrig. Bisher hat dieser Wert auf dem Produktionsserver um die 200ms geschwankt (natürlich für Benutzer, die nicht eingeloggt sind, mit aktivem Cache). Unter Last stieg sie auf etwa 700ms.

Wir überprüften die Korrektheit des Exports mit der Software Screaming Frog SEO Spider. Es wurden keine 404-Fehler erkannt, was bedeutet, dass die Archivierung zu 100% erfolgreich war. Auch die Browser-Konsolen zeigen keine JS-Fehler an.

Es ist zu erwarten, dass in den nächsten Tagen die DrupalCamp 2018 Website endgültig eingestellt und durch eine reine HTML-Version ersetzt wird. Auf diese Weise vermeiden wir die Notwendigkeit der Aktualisierung und verursachen somit keine zusätzlichen Kosten mehr. Wenn Änderungen am Inhalt erforderlich sind, werden wir diese auf einer lokalen Version vornehmen, die auf Drupal basiert, und dann automatisch eine neue HTML-Seite generieren. Wir ermutigen Sie, von unseren Erfahrungen zu profitieren!