Archiwizacja strony w Drupal 8 do HTML-a?

27.08.2018

Co zrobić ze starą, nieaktualizowaną już stroną internetową, którą jednak chcielibyśmy pozostawić w sieci? Doskonałym rozwiązaniem jest archiwizacja do czystego kodu HTML. Udowodnimy Wam to na przykładzie witryny drupalcamp.pl stworzonej w Droopler, opartej o Drupal 8.

Po co w ogóle archiwizować strony?

Czasami strony internetowe mają swój termin ważności. Może on wynikać z cyklu życia użytej technologii albo z faktu tworzenia witryny dla wydarzeń lub specjalnych okazji. Gdy np. organizujemy festiwal muzyczny - po jego zakończeniu strona przestaje być aktualna i potrzebna. Gdy mamy na swoim serwerze dawno zapomniane witryny - ich kod może okazać się na tyle przestarzały, że zacznie stanowić zagrożenie. Jeśli z jakiegoś powodu zależy nam na zatrzymaniu stron w Internecie - musimy się liczyć z kosztami ich stałego utrzymania i aktualizacji. Alternatywą w kontekście powyższego, a więc zaoszczędzenia pieniędzy, jest zakup wsparcia Drupala.

Jakie koszty generuje nieużywana strona?

Koszt utrzymania zależy w dużej mierze od wykorzystywanej technologii. Skupmy się więc na Drupalu 8. Jest to jeden z najbezpieczniejszych dostępnych CMS. Aktualizacje do D8 ukazują się co miesiąc, co pół roku publikowana jest wersja z nowymi funkcjonalnościami. Oznacza to, że aby nie pozostać w tyle, należy 12 razy w roku zainstalować świeże wydanie Drupala i przetestować, czy nasza strona nadal działa. Z doświadczenia wiemy, że bywa to bardzo czasochłonne.

Z drugiej strony, jeśli zdecydujemy się na zaniechanie aktualizacji - ryzykujemy atak na stronę i zagrożenie dla innych witryn znajdujących się na naszym serwerze. Zaniedbanie bezpieczeństwa może prowadzić do znacznie większych kosztów niż bieżące aktualizowanie kodu.

Jak więc uniknąć kosztów utrzymania, a jednocześnie pozostawić stronę online? Świetnym kompromisem między sentymentem a opłacalnością jest konwersja do czystego kodu HTML.

Jakie zalety i wady ma czysty kod HTML?

Publikacja stron napisanych w czystym HTML to w pewnym sensie powrót do korzeni. W dobie zaawansowanych CMS-ów mało kto pamięta bowiem, że strona internetowa może być stworzona bez użycia języków interpretowanych po stronie serwera, jak np. PHP.

Dlaczego zapomniano już o pisaniu stron przy użyciu wyłącznie HTML?

Ze względu na trudności przy uaktualnianiu ich treści.
Przez brak możliwości ponownego użycia kodu dla globalnych elementów (np. nagłówka, głównego menu, stopki).
Z uwagi na statyczny charakter HTML, utrudniający tworzenie stron administracyjnych.

Dlaczego więc warto przekonwertować nieużywaną stronę stworzoną na podstawie Drupal 8 do postaci czystego HTML?

Spowoduje to duży wzrost szybkości działania wszystkich podstron - także tych, które dotąd działały najwolniej.
Zaatakowanie strony stanie się bardzo trudne o ile właściwie skonfigurujemy serwer.
Aktualizacja kodu stanie się zupełnie zbędna, koszt utrzymania spadnie praktycznie do zera.

Jakie ograniczenia będzie miała strona skonwertowana do HTML?

Zmiany w treści staną się bardziej czasochłonne. Deweloper będzie je wprowadzał na lokalnej kopii, a następnie generował wersję HTML do publikacji na serwerze.
Przestaną działać elementy dynamiczne, jak np. formularze.

Jak przystosować stronę do archiwizacji?

Nie każda witryna nadaje się od razu do archiwizacji. Przede wszystkim powinniśmy upewnić się, czy któraś z podstron nie zawiera elementów wymagających do działania skryptów PHP:

Formularzy kontaktowych (można zamienić je na osadzone Google Forms).
Wyszukiwarek (można zamienić ją na wyszukiwanie Google w witrynie).
Views Exposed Filters.
Obsługi AJAX w widokach.

Konieczne jest także wyłączenie komunikatów błędów pochodzących z serwera - zwłaszcza jeśli kopiujemy stronę z localhost. Podczas archiwizacji powinniśmy używać ustawień maksymalnie zbliżonych do produkcyjnych, włączając w to agregację CSS/JS i brak dodatkowych informacji diagnostycznych generowanych przez Twig.

Na początku artykułu obiecaliśmy opisać konwersję do HTML na przykładzie. Przedstawimy więc sposób archiwizacji witryny drupalcamp.pl, dedykowanej organizowanej przez nas konferencji DrupalCamp 2018. Jest to wydarzenie cykliczne, każdego roku przygotowujemy dla niego zupełnie nową stronę internetową. Gdy DrupalCamp już się odbędzie, zostawiamy tę stronę na pamiątkę, zarchiwizowaną do HTML pod osobnym adresem.

Strona DrupalCamp 2018

Jakich przygotowań wymagała witryna drupalcamp.pl? Przede wszystkim usunęliśmy podstrony z formularzami, które z uwagi na zakończenie konferencji przestały być potrzebne. Na podstronach programu upewniliśmy się, że wszystkie widoki działają bez użycia AJAX. Wykonaliśmy też szybki audyt skryptów JS, aby wyeliminować potencjalne problemy z działaniem kodu po wyłączeniu obsługi PHP.

Proces archiwizacji

Do automatycznego archiwizowania stron wykorzystujemy oprogramowanie httrack, udostępniane na licencji GNU GPL3. Dostępne są jego wersje na Windows, Linux, OSX i Android. Na nasze potrzeby używamy httrack za pośrednictwem linuxowej konsoli. W dokumentacji dostępnych jest mnóstwo przełączników i opcji, oto nasza komenda pozwalająca na skopiowanie strony w trybie 1:1, z zachowaniem struktury linków:

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 - powoduje wyłączenie wbudowanych limitów transferu, przydatne w przypadku gdy źródłem jest nasz lokalny serwer.
--max-rate - ustawia maksymalną prędkość transmisji.
-%P - próbuje rozpoznać wszystkie możliwe linki do plików na stronie.
-K3 - nie zmienia linków na stronach.
-N "%h%p/%n.%t"- nie zmienia nazw plików.
-X - przy kolejnym wywołaniu komendy usuwa z wersji zarchiwizowanej pliki, które zostały usunięte w oryginale.
-wqQ%v - tryb standardowy, cichy, z listą przetwarzanych plików na ekranie.

Uzyskany w ten sposób obraz strony nie jest jeszcze do końca gotowy. Podstrony znajdują się w plikach typu about-us.html zamiast about-us/index.html. Problem ten naprawi prosty skrypt:

#!/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

Stworzona w powyższy sposób kopia będzie z zewnątrz nie do odróżnienia od oryginału. Ma to duże znaczenie dla zachowania dotychczasowych pozycji w wyszukiwarkach internetowych.

Współpraca httrack z Drupalem

Drupal 8 nie jest do końca kompatybilny z httrack. Problemem są przede wszystkim responsywne obrazki prezentowane za pośrednictwem tagu <picture>. Przeprowadzenie poprawnej konwersji do HTML wymaga przekazania do httrack podpowiedzi w odniesieniu do dodatkowych plików do ściągnięcia.

Archiwizowana przez nas strona drupalcamp.pl jest oparta o oprogramowanie Droopler, autorską, udostępnioną bezpłatnie dystrybucję Drupal 8. W wersji 1.3 Drooplera wprowadziliśmy pełną obsługę httrack, pomagającą rozpoznać i pobrać wszystkie pliki graficzne, których używa strona.

W jaki sposób “poprawiliśmy” kompatybilność z httrack? Zastosowaliśmy bardzo proste rozwiązanie w postaci hooków przygotowujących listę plików do ściągnięcia. Podpowiedzi dla bota umieszczamy w sekcji <head> strony, jako kolejne elementy <link>:

<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" />

Elementy te zostają rozpoznane przez httrack i ściągnięte do tworzonej kopii. Dzięki temu zachowujemy pełną responsywność obrazków. Nadmiarowy kod zazwyczaj usuwamy z poziomu konsoli, za pomocą wyrażenia regularnego.

Wyniki konwersji

Efekt konwersji do HTML jest w naszym przypadku bardzo satysfakcjonujący. Otrzymaliśmy folder z plikami o całkowitej wielkości około 20 MB. Jak można się było spodziewać - czas dostępu do pliku HTML wynosi kilka milisekund, jest więc pomijalny. Nawet pod dużym obciążeniem pozostaje na bardzo niskim poziomie. Dotychczas na produkcyjnym serwerze czas ten oscylował w okolicach 200ms (oczywiście dla niezalogowanych użytkowników, z aktywnym cache). Pod obciążeniem wzrastał do ok 700ms.

Poprawność eksportu sprawdziliśmy przy pomocy oprogramowania Screaming Frog SEO Spider. Nie wykryło ono błędów 404, co oznacza, że archiwizacja przebiegła w 100% pomyślnie. Również konsole przeglądarek nie pokazują błędów JS.

Można się więc spodziewać, że już w najbliższych dniach strona DrupalCamp 2018 odejdzie na zasłużoną emeryturę, zastąpiona przez czysty HTML. Dzięki temu unikniemy konieczności jej aktualizacji, a zatem również ponoszenia dodatkowych kosztów. Jeśli zajdzie potrzeba wprowadzenia zmian w treści - dokonamy ich na wersji lokalnej, działającej pod kontrolą Drupala, a następnie wygenerujemy automatycznie nowy kod HTML. Zachęcamy do skorzystania z naszych doświadczeń!