Blog

CMS a pliki płaskie

Czy CMS bez bazy danych ma sens? Omówienie trzech takich propozycji.

CMS a pliki płaskie

Zacznę od pewnego oświadczenia: idea generatorów stron statycznych (dalej SSG) bardzo mocno do mnie przemówiła. Uważam, że na hobbystyczny użytek, czyli taki jaki mnie interesuje jest to najsensowniejsza propozycja. Z resztą podejrzewam, że tak z 80% stron na Wordpressie posadowionych tylko zyskałoby na tym, gdyby jej właściciele zmigrowali się na Hugo czy inszego Jeckylla, jeśli chodzi o ogólną responsywność i bezpieczeństwo. Niestety problem z tymi rozwiązaniami jest taki, że są to narzędzia niespecjalnie użytkownikom przyjazne, czyli wymagają znajomości znaczników Markdown oraz poznania ogólnej architektury całości, ponieważ miast panelu administracyjnego, który by jakoś spinał całość wdrażanego projektu, użytkownik musi uzbroić się w porządny edytor w rodzaju Visual Studio Code oraz przygotować się na spędzeniu wielu godzin na lekturze dokumentacji. Innymi słowy: jest to bardzo fajne rozwiązanie z punktu widzenia deweloperów, ale już niekoniecznie dla osób odpowiedzialnych za tworzenie kontentu. Tym sposobem rozwiązania takie jak wcześniej wspomniane walkowerem oddają całe grono potencjalnych odbiorców, którzy chcieliby postawić prostą stronę będącą wizytówką ich firmy czy prowadzić bloga.

Na szczęście są od tego schematu są wyjątki jak chociażby opisywany przeze mnie projekt rodzimego chowu, czyli Publii. Szczerze powiedziawszy jestem zachwycony podejściem do tematu ze strony jego twórców, choć w tej chwili ma on pewne zasadnicze ograniczenia (o czym będzie jeszcze dalej), dlatego postanowiłem zgłębić temat i sprawdzić czy nie ma więcej tego rodzaju rozwiązań, które spełniałyby moje oczekiwania. A jakież to potrzeby mam na myśli? Nie są one specjalnie wyszukane i sprowadzają się do następującej listy:

  1. sensowny panel administracyjny, który pozwala zarządzać sporą częścią elementów, składających się na projekt, jakim jest gotowa i działająca witryna internetowa (w moim wypadku blog),
  2. możliwość rozszerzania funkcjonalności całości przy pomocy gotowych wtyczek,
  3. przyjazna dokumentacja, która pozwoli w łatwy sposób ogarnąć podstawy takiego narzędzia.

Niestety jeśli chodzi o SSG okazuje się, to poza Publii (choć nawet to narzędzie nie spełnia w/w wymagań) nie ma praktycznie gotowych rozwiązań, które wpisywałyby się w moje oczekiwania. Dlatego trochę rozszerzyłem zakres poszukiwań, czyli wziąłem pod uwagę również CMS, które wprawdzie generują stronę w sposób dynamiczny, ale nie wymagają do tego żadnej bazy danych, czyli cały kontent przechowywany jest w postaci plików płaskich. Tym sposobem lista dostępnych opcji znacznie się wydłużyła, ale sensownych - z mojej perspektywy - rozwiązań nie przybyło znacząco. W efekcie w dalszej części tekstu przedstawiam 3 “kandydatów”, których byłbym gotów - w mniejszym lub większym stopniu - uczynić podstawą mojego bloga. Dwa pierwsze rozwiązania to faktycznie SSG, zaś ostatni to “typowy” CMS, ale bez wykorzystywania bazy danych. Co ciekawe, każdy z nich reprezentuje inny język programowania, choć to czysty przypadek.

  1. Publii (JS)

Temu rozwiązaniu - jak wspominałem wcześniej - poświęciłem osobny tekst. Dlatego w tym wpisie tylko zaznaczę, że na ten moment Publii nie spełnia w żadnej mierze drugiego z postawionych przeze mnie wymagań, ale jego twórcy odgrażają się, że jeszcze w tym roku wprowadzą instytucję wtyczek. Jeśli na sam początek zaproponują dzięki temu kilka funkcjonalności w rodzaju przeszukiwania zawartości strony, to będzie to dla mnie bardzo poważny kandydat na SSG roku.

2. Lektor (PYTHON)

W odróżnieniu od poprzednika mechanizm rozszerzenia korowych funkcjonalności przy pomocy wtyczek jest zaimplementowany, choć ich ilość póki co nie powala (przynajmniej jeśli mowa o tych, którymi chwalą się twórcy na stronie projektu). Niestety dużo gorzej jest z panelem administracyjnym, choć od razu zaznaczę, że z trójki omawianych rozwiązań Lektor jest jedynym, którego nie sprawdziłem w boju i bazuję jedynie na tym co udało mi się wyczytać w dokumentacji (notabene mocno średniej ze wskazaniem na słabą, co trochę nie licuje z moim trzecim wymaganiem). De facto pozwala on chyba wyłącznie na tworzenie kontentu, cała reszta to jednak zabawa konsolą i grzebanie w plikach konfiguracyjnych, więc trudno uznać to rozwiązania za przesadnie przyjazne dla nowego użytkownika i mimo wszystko dużo bliżej tu do typowego SSG niż czegoś na kształt propozycji w rodzaju Publii czy Wordpressa.

Dla wielu osób ogromnym plusem może być fakt, że jest to rozwiązanie oparte na Pythonie, więc niewykluczone, że istnieje sporo gotowych lub łatwych do zaimplementowania narzędzi, które mogą uczynić pracę z Lektorem dużo przyjemniejszą. Tym niemniej osobiście nie sięgnąłbym po Lektora z myślą o własnej stronie.

3. Grav (PHP)

Nie jest to SSG żadną miarą, ponieważ treść prezentowana odwiedzającym witrynę na Grav posadowioną jest generowana dynamicznie, choć oczywiście jest też opcja ustawienia, by “gotowe” strony ładowane były do pamięci podręcznej. Tym niemniej odpada tutaj konieczność instalowania i korzystania z jakiejkolwiek bazy danych, ponieważ cały kontent jest zapisywany w plikach płaskich i jeśli ktoś ma ochotę pracować bardziej z plikami niż przy użyciu panelu administracyjnego, to będzie miał nieodparte wrażenie, że korzysta z typowego SSG. Tym niemniej z wszystkich wymienionych w tym tekście rozwiązań Grav wydaje się najbardziej dojrzały.

Na duży plus zasługuje bardzo dobra dokumentacja, zorganizowana w logiczny sposób. Oczywiście ktoś może uznać, że jest ona momentami “przegadana”, ponieważ jej autorzy tłumaczą pewne podstawowe kwestie, ale w przypadku rozwiązań dla “hobbystów” w rodzaju piszącego te słowa jest to bez dwóch zdań spora zaleta. Nieprzypadkowo ten aspekt wymieniłem wśród wymagań, które stawiam przed tego rodzaju narzędziami.

Warto też wspomnieć, że wokół tego projektu skupiła się spora społeczność. W tym kontekście wystarczy nadmienić, że pośród CMS-ów, których kod źródłowych znajduje się na Github, jest to projekt o jednej z największej liczbie gwiazdek (na ten moment 13 tysięcy). W efekcie do dyspozycji użytkowników jest dużo gotowych tematów i całkiem sporo wtyczek, które adresują sporo potrzeb.

Podsumowanie

Jak widać marniutko to wszytko wygląda, choć rzecz jasna nie można wykluczyć (a wręcz należy założyć), że nie dotarłem do wszystkich godnych uwagi rozwiązań tego typu. Tym niemniej chciałbym kończąc nadmienić, że w przypadku CMS-ów w rodzaju Grav, czyli nie wymagających pod spodem jakiejkolwiek bazy danych, to wybór był znacząco większy niż w przypadku SSG, oczywiście jeśli chodzi o spełnienia zakładanych warunków. Pierwotnie zamiast Grav (albo obok tego ostatniego rozwiązania) chciałem napisać o projekcie Statamic. Po niewczasie zorientowałem się, że choć jest to rozwiązanie Open Source to wymaga wykupienia licencji, choć dla osób prywatnych istnieje darmowa opcja, ale z pewnymi ograniczeniami. Jednak problem okazała się dużo bardziej trywialny: nie byłem w stanie uruchomić go na moim kompie. Jeśli chciałby poszperać we własnym zakresie wystarczy, że wpisze się w przeglądarkę “cms flat file” i już przed oczami pojawi się sporo linków do stron zawierających zestawienia takich narzędzi.

Na sam koniec dodam tylko, że Grav okazał się na tyle interesującym i bezproblemowym w obsłudze rozwiązaniem, a przy tym mocno wykraczającym poza to, co obecnie ma do zaoferowania Ghost, z którego korzystam, że rozważam opcję migracji tego bloga na nowe rozwiązanie. Dla decyzji w tym względzie kluczowy będzie najbliższy weekend, gdzie mocniej w obroty wezmę Grav.