Faktycznie starałem się żeby strona przypominała szablon „Twenty Eleven” który znaleźć możemy w Wordpressie, ponieważ uważam że jest on wyjątkowo czytelny, jednak pod spodem siedzi zupełnie inna technologia.

Przyznaję, że Wordpress świetnie nadaje się na silnik stron, które edytowane są przez kilka osób, czy nawet cały zespół redaktorów. Co więcej - w podstawowej wersji jest to system, powiedziałbym, idealny dla początkujących redaktorów. Edytor WYSIWYG, elegancka obsługa galerii, mnogość pluginów,… Dodatkowo Wordpress napisany jest w języku wspieranym przez większość firm hostingowych - istnieje więc szansa na bardzo tanie hostowanie swojej (pierwszej) strony. Wszystko to sprawia że bardzo polecam Wordpressa jako silnik nie tylko bloga ale jako CMS ogólnego użytku, nawet początkującym użytkownikom.

Z racji tego że moja strona jest raczej rzadko aktualizowana (nad czym ubolewam) oraz aktualizuję ją tylko ja, zdecydowałem się na zastosowanie innego rozwiązania. (Tak naprawdę nie byłbym sobą gdybym nie spróbował czegoś nowego ;) ) Zastosowałem tzw. Static Site Generator. Rozwiązanie to różni się od tradydyjnego podejścia (strona umożliwia edycję jej samej + wynikowy HTML jest zwykle generowany w locie) tym, że całość strony przygotowywujemy lokalnie (albo na jakimś repozytorium, bez większego znaczenia dla opisu), za pomocą specjalnych plików z artykułami (co ważne - nie są to „gotowe” pliki HTML jako takie), a następnie „przepuszczamy” tak przygotowany zestaw artykułów przez wspomniany Static Site Generator, który na podstawie ich oraz odpowiednich szaablonów „wyprodukuje” wszystkie możliwe pliki HTML na jakie może natrafić użytkownik podczas przeglądania strony.

Wydawałoby się że takie rozwiązanie jest niewygodne, zabiera dużo czasu,… Muszę zdementować tę pogłoskę. Strony przygotowane za pomocą Static Site Generatorów mają jedną, przeogromną zaletę: są plikami HTML. Nie przyjmują argumentów, nie autoryzują użytkownika - słowem: nie są kodem po stronie serwera który może zawierać błąd wpływający na bezpieczeństwo całej maszyny. Tradycyjne systemy CMS (w szczególności te bardziej popularne) narażone są na ogromną ilość, w tym momencie nawet zautomatyzowanych i ślepych, ataków, w związku z czym wymagają dość mocnej opieki - czy to aktualizacji czy to poprawek po stronie kodu,… Tutaj ograniczamy się do opieki podczas wrzucania nowego artykułu. Albo tylko pobieżnego rzucenia okiem na wynik, jeśli zdecydowaliśmy się na automatyzację aktualizacji za pomocą jakiegoś repozytorium i odpowiednich post-commit-hook (lub analogicznych). Między aktualizacjami treści strona taka właściwie nie wymaga żadnej opieki.

Drugą ważną zaletą stosowania Static Site Generatorów jest to że jedynym co potrzebujemy umieścić na serwerze jest garstka plików HTML (i ewentualnie innych, statycznych typu obrazki, skrypty, CSS,…), a do tego wystarczy nam absolutnie najprostszy hosting, bez obsługi żadnych skryptów/specjalnych języków/… Dodatkowo strony tego typu mogą ładować się znacznie szybciej od strony użytkownika. Znika jedna warstwa abstrakcji - strony zostały wygenerowane zanim użytkownik o nie zapytał - żaden skrypt nie musi pobierać treści artykułów z bazy, sklejać ich z szablonami,…

Trzecim, mniej istotnym argumentem za jest workflow backupów. Klasyczne systemy CMS wymagają generalnie backupu plików + backupu bazy danych, wykonywane są okresowo, jedyną „wiążącą” lokalizacją źródeł strony jest serwer który je serwuje. W rozwiązaniu ze Static Site Generatorami, szczególnie jeśli skorzystamy z jakiegoś repozytorium kod potrzebny do odtworzenia strony znajduje się u każdego z autorów/redaktorów, na serwerze z repozytorium,… W skrajnym przypadku w ogóle nie potrzebujemy backupować serwera serwującego stronę (mam na myśli serwowane pliki, backup konfiguracji serwera jest osobną sprawą), ponieważ całą stronę możemy bez większego problemu wygenerować od nowa ze źródeł.

Czwartą ciekawostką może być feature, dość modny w tego typu systemach, pozwalający na optymalizację plików statycznych (w tym wygenerowanych przez sam silnik). Jak to działa? Przykładowo - mamy dość duży ruch na stronie, potrzebujemy mocno ograniczyć zużywane łącze. Istnieją pluginy pozwalające optymalizować szablony CSS, skrypty JS, sam kod HTML do formy w której pominęte jest możliwie dużo białych znaków, czasami nawet bardziej zaawansowane systemy potrafią optymalizować nazwy funkcji w sposób podobny do tego w jaki kompresowane są pliki. Dodatkowo istnieją pluginy do optymalizacji obrazków - w przypadku obrazków mogą je albo skalować do potrzebnych rozmiarów, albo rekompresować z niższą jakością (jak w przypadku plików JPG), lub, co ciekawe, rekompresować pliki bez straty jakości, ale silniejszym algorytmem kompresji (jak w przypadku plików PNG).

I na koniec wychwalania tego typu systemów wspomnę tylko że dość łatwo jest skalować taką stronę jeśli nagle otrzymujemy duży ruch przychodzący. W najprostszym przypadku można dokupić konto hostingowe u innego dostawcy, szybko skopiować pliki i zrobić round robin na DNS. Jeśli nie zamierzamy w czasie wzmożonego ruchu aktualizować strony nie napotkamy na żadne problemy z synchronizacją itp.

Rozwiązanie to ma jednak również trochę wad. Przede wszystkim nie jest tak user-friendly jak tradycyjne systemy CMS. Redaktor powinien wiedzieć jak formatować tekst w markdown czy innym języku formatowania tekstu, powinien znać podstawy działania repozytoriów i umieć się nimi posługiwać, najlepiej jakby umiał uruchomić na swoim komputerze testową instancję strony do podglądania efektów swojej pracy przed wysłaniem wyników na serwer produkcyjny. To wszystko wymaga wiedzy, środowiska i chwili czasu, na które jednak nie każdy może sobie pozwolić.

Drugą wadą na którą natrafiłem podczas korzystania z tej technologii jest (miejmy nadzieję, że chwilowo) dość słaba obsługa galerii. Generalnie istnieją pluginy do dodawania galerii do wpisów, ale są dość toporne w użytkowaniu, skrojone pod jedno, konkretne zastosowanie. Za to zwykle oferują optymalizacje wspomniane wyżej.

Wracając do konkretów, ja skorzystałem z projektu Pelican, jest to jeden z wielu dostępnych silników typu Static Site Generator, ten akurat został napisany w Pythonie, ma kilka ciekawych rozwiązań - korzysta z dość znanego (i bardzo wygodnego!) systemu szablonów Jinja2, obsługuje pluginy obejmujące swoim obszarem bardzo szeroką gamę zastosowań i wiele innych. Do tego napisałem własny template wzorując się na wspomnianym „Twenty Eleven” oraz bazując na bibliotece Bootstrap, dzięki czemu strona powinna być responsywna.

Myślę że „cokolwiek” przybliżyłem nieco, być może nieznane niektórym, technologie Static Site Generatorów, zachęcam do przetestowania jakiegoś silnika tego typu na własnej skórze i życzę samych owocnych eksperymentów.

pid