CMS

CMS to system, w którym redakcja zmienia treści bez programisty. Brzmi oczywisto, a jest najczęściej pomijaną decyzją projektu: strona bez wygodnej edycji wraca do agencji przy każdej literówce, a każda taka wizyta ma swój koszt i swój czas oczekiwania.

Klasyczny CMS (WordPress) trzyma treść i wygląd razem — redaktor widzi stronę taką, jaka będzie. Headless CMS (Strapi, Contentful) rozdziela te dwie rzeczy: system przechowuje treść i udostępnia ją przez API, a wygląd buduje osobna warstwa. Cena tego rozdzielenia to brak podglądu „jeden do jednego" bez dodatkowej pracy; zysk to ta sama treść zasilająca stronę, aplikację i cokolwiek jeszcze dojdzie.

Kiedy headless wygrywa: gdy treść ma trafiać w więcej niż jedno miejsce, gdy zależy Wam na szybkości strony, gdy potrzebne są własne typy treści z relacjami między nimi. Kiedy przegrywa: przy prostej stronie wizytówkowej, gdzie klasyczny CMS jest szybszy do wdrożenia i tańszy w utrzymaniu.

Ile pól ma mieć jeden typ treści. Każde dodatkowe pole to decyzja, którą redaktor musi podjąć przy każdym wpisie. Model z czterdziestoma polami „na wszelki wypadek" kończy się tym, że trzydzieści zostaje pustych, a formularz staje się nie do przejścia.

Czy potrzebny jest podgląd przed publikacją. W headless to dodatkowa praca, nie funkcja z pudełka. Jeśli redakcja publikuje codziennie, warto to wycenić na starcie; jeśli raz na miesiąc — prawdopodobnie nie.

Kto aktualizuje system. CMS to oprogramowanie z własnym cyklem wydań i poprawek bezpieczeństwa. Bez ustalonego właściciela aktualizacji zostaje wersja sprzed dwóch lat z otwartymi lukami.

Czego nie robić. Nie modeluj treści pod dzisiejszy wygląd strony — wygląd zmieni się szybciej niż treść. Nie dawaj wszystkim uprawnień administratora. I nie migruj wszystkiego bez przeglądu; okazja do usunięcia martwych wpisów nie wraca.

Treść oddzielona od prezentacji to obietnica headless — pod warunkiem, że model treści powstał z głową: komponenty współdzielone, relacje zamiast kopii, pola nazwane językiem redakcji. Wtedy redesign frontu nie wymaga migracji treści, a te same dane zasilają stronę, aplikację i integracje. Na własnym serwisie utrzymujemy tak kilkanaście typów treści od lat, bez przebudowy schematu.

Wydajność frontu nie zależy od obciążenia panelu: strony generowane statycznie wytrzymują skoki ruchu, a redakcja pracuje płynnie niezależnie od liczby odwiedzających.

Panel konfigurujemy pod ludzi: role i uprawnienia, workflow draft/publish, podgląd przed publikacją, media library z sensownym porządkiem. Do tego automatyczna rewalidacja frontu po publikacji — treść wychodzi w sekundach, bez rebuilda i bez proszenia IT. Redakcja Konsorcjum Migracyjnego prowadzi serwis w całości sama; nasza rola skończyła się na wdrożeniu i szkoleniu.