WordPress jest platformą publikacyjną z ogromnym rynkiem gotowych rozszerzeń i motywów. Decyzja o niej nie jest wyborem technologii do napisania serwisu. Jest rozstrzygnięciem o tym, ile odpowiedzialności organizacja przejmuje za kod, którego nie napisała i którego cyklu wydawniczego nie kontroluje. Rachunek za tę decyzję przychodzi latami, nie przy wdrożeniu.
Na skróty
Czego dowiesz się z artykułu:
- Jaki koszt organizacja ponosi w serwisie, zanim ktokolwiek zaproponuje zmianę platformy
- Jakie warunki muszą wystąpić razem, żeby platforma z ekosystemem rozszerzeń była właściwą odpowiedzią
- W jakich sytuacjach ta platforma nie odpowiada na realny problem
- Jakie alternatywy pozostają i jaką cenę niesie każda z nich
- Co organizacja podpisuje, opierając serwis na cudzych rozszerzeniach
Dla kogo ten artykuł:
- Osoby odpowiadające za komunikację i serwis firmowy
- Kierownicy zespołów utrzymujących obecność organizacji w sieci
- Menedżerowie planujący budżet wdrożenia i utrzymania serwisu
Ile kosztuje serwis, w którym każda zmiana treści wymaga programisty?
Rachunek nie zaczyna się od nazwy platformy. Zaczyna się od pozycji, których nikt nie księguje osobno: zgłoszenie o poprawienie literówki czekające w kolejce razem z wdrożeniami, kampania przesunięta o tydzień, bo nie ma kto dołożyć strony, i treść publikowana tam, gdzie akurat się da, zamiast tam, gdzie powinna. Każda z tych pozycji jest drobna. Razem tworzą stałą pozycję w koszcie komunikacji.
Do tego dochodzi koszt widoczny dopiero przy zmianie osób. Serwis zbudowany bez warstwy redakcyjnej zna wyłącznie ten, kto go zbudował, a jego następca zaczyna od odtworzenia cudzych decyzji. Organizacja odkłada wtedy zmiany akurat tam, gdzie komunikacja jest najbardziej potrzebna — i to odkładanie, a nie sam serwis, jest realnym wydatkiem.
Problem ma odmiany, a ich pomylenie kosztuje najwięcej. Pierwsza odmiana to przepustowość: publikacja jest wąskim gardłem, bo wymaga wdrożenia. Druga to zakres: potrzebne są funkcje, których nikt w organizacji nie chce pisać od zera — formularze, wielojęzyczność, sklep, kalendarz wydarzeń. Trzecia to odpowiedzialność: serwis już istnieje, ale nikt nie umie powiedzieć, kto odpowiada za jego aktualizacje i co się stanie, gdy przestanie działać. Rozstrzygnięcie nie zależy od tego, jak zaawansowany technicznie jest zespół — zależy od tego, którą z tych odmian organizacja faktycznie ponosi.
Kiedy ta platforma jest właściwą odpowiedzią?
Platforma z własnym ekosystemem rozszerzeń jest właściwą odpowiedzią wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno:
- Treść zmienia się częściej niż kod. Redakcja publikuje regularnie i chce to robić bez udziału programisty. Gdy serwis jest wizytówką zmienianą raz na sezon, warstwa redakcyjna zostaje kosztem bez zastosowania.
- Potrzebne funkcje są rynkowo standardowe. Formularz, katalog, wielojęzyczność i sprzedaż istnieją jako gotowe rozszerzenia, więc organizacja płaci za konfigurację zamiast za wytworzenie. Gdy potrzeba jest nietypowa, ta przewaga znika w pierwszym tygodniu.
- Organizacja godzi się prowadzić aktualizacje jako proces. Rdzeń, motyw i rozszerzenia mają własne wydania i własne poprawki bezpieczeństwa. Zespół, który tego nie zaplanuje, dostanie serwis aktualizowany dopiero po awarii.
Dopiero gdy te warunki występują łącznie, sensu nabiera praca nad samą platformą: własny motyw zamiast kupionego, rozszerzenie napisane pod proces organizacji i porządek w kodzie, który przetrwa aktualizację rdzenia. Ten zakres — od struktury motywu po własne rozszerzenie doprowadzone do wdrożenia — obejmuje szkolenie PHP dla WordPress: tworzenie motywów i wtyczek.
Kiedy tej platformy nie wybierać?
Najczęstszym błędem jest sięgnięcie po tę platformę dlatego, że „wszyscy jej używają”, zanim ktokolwiek nazwał, co serwis ma robić. Organizacja dostaje wtedy instalację obwieszoną rozszerzeniami, których nikt nie wybierał świadomie, i rachunek za utrzymanie każdego z nich.
Poza tym są sytuacje, w których ta platforma nie odpowiada na realny problem. Serwis, który jest w istocie aplikacją — z własnym modelem danych, logiką biznesową i integracjami — będzie ją miał wygiętą wokół założeń systemu publikacyjnego, a każda aktualizacja rdzenia stanie się ryzykiem regresji w logice, która nigdy nie miała tam mieszkać. Wymagania regulacyjne wobec danych osobowych albo płatności przenoszą ciężar dowodu na organizację, a jej powierzchnia ataku rośnie z każdym rozszerzeniem pochodzącym od nieznanego autora. Zespół bez planu utrzymania dostanie serwis, który działa do pierwszej niezgodności wersji; przy platformie o tak dużym udziale w rynku publiczne podatności są znane wcześniej niż ktokolwiek zdąży zareagować. Żadnej z tych sytuacji nie zmienia to, ile pracy włożono już we wdrożenie. Co konkretnie oznacza ta powierzchnia ataku po stronie aplikacji webowej, rozkłada tekst o bezpieczeństwie sieci, aplikacji webowych i mobilnych.
Jakie są alternatywy i ile kosztują?
Generator statyczny daje serwis bez bazy danych i bez warstwy wykonawczej, więc powierzchnia ataku niemal znika, a koszt utrzymania spada do hostingu plików. Ceną jest publikacja przechodząca przez proces budowania: redakcja pracuje w narzędziu, które ktoś musi jej dostarczyć, a każda zmiana wymaga przebiegu. System bezgłowy rozdziela treść od prezentacji i pozwala zasilać nią aplikację oraz serwis naraz, ale organizacja utrzymuje wtedy osobno warstwę treści i osobno warstwę prezentacji, a podgląd strony przed publikacją traci, jeśli go nie dobuduje. Platforma niskokodowa skraca drogę do działającego rozwiązania i przenosi utrzymanie na dostawcę, kosztem uzależnienia od jego cennika i granic. Ile faktycznie da się w ten sposób obsłużyć, rozkłada omówienie platform low-code i no-code.
Ostatnia droga bywa najtańsza i najrzadziej rozważana: zostawienie platformy w spokoju i naprawienie procesu — uprawnień redakcyjnych, przeglądu treści i harmonogramu aktualizacji. Bywa też jedyną, która działa, bo pozostałe zakładają, że problemem jest narzędzie.
Co organizacja podpisuje, opierając serwis na cudzych rozszerzeniach?
Podpisuje przede wszystkim cudzy cykl wydawniczy. Rdzeń, motyw i każde rozszerzenie mają osobnych autorów, osobne tempo poprawek i osobne momenty porzucenia. Rozszerzenie bez opieki nie przestaje działać z dnia na dzień — przestaje dostawać poprawki, a to wychodzi na jaw dopiero przy kolejnej aktualizacji rdzenia albo przy incydencie.
Podpisuje też obowiązek testowania aktualizacji, którego nikt nie planuje z góry. Serwis potrzebuje kopii do sprawdzania wydań, kopii zapasowej z odtworzeniem przećwiczonym naprawdę i wiedzy, które rozszerzenia są krytyczne dla procesów. Najdroższą pozycją nie jest jednak żadna z tych rzeczy, tylko kompetencja po stronie organizacji. Serwis prowadzony przez pojedynczą osobę zamienia każdą zmianę w kolejkę do jednego kalendarza, a każdą nieobecność w ryzyko. Rolą, która ten rachunek obniża, jest zespół redakcyjny umiejący prowadzić serwis samodzielnie — czyli zakres szkolenia WordPress: tworzenie i zarządzanie stronami internetowymi. Bez tego organizacja płaci podwójnie: za wdrożenie i osobno za każdą zmianę, której nie umie wykonać sama.
FAQ — najczęściej zadawane pytania
Czy dużo gotowych rozszerzeń to zaleta czy ryzyko?
Zaleta na wdrożeniu i ryzyko w utrzymaniu — te określenia nie wykluczają się. Rozstrzyga reguła: rozszerzenie wchodzi wtedy, gdy ktoś wskazany odpowiada za jego aktualizacje i wie, co się stanie po jego usunięciu. Bez takiej reguły liczba rozszerzeń rośnie sama.
Czy migracja z tej platformy jest kosztowna?
Treść przenosi się stosunkowo łatwo, bo jest ustrukturyzowana. Kosztem są funkcje wniesione przez rozszerzenia: formularze, przekierowania, wielojęzyczność i integracje trzeba odtworzyć po nowej stronie, a części z nich nikt nigdy nie spisał. Dlatego decyzję o migracji podejmuje się na podstawie inwentaryzacji rozszerzeń, a nie objętości treści.
Po czym poznać, że serwis wymknął się spod kontroli?
Po tym, że nikt nie potrafi powiedzieć, do czego służy konkretne rozszerzenie ani kto je włączył. Aktualizacje są odkładane, bo nie wiadomo, co się po nich zepsuje. To jest moment na inwentaryzację i decyzję o zakresie, a nie na kolejne rozszerzenie naprawiające skutki poprzedniego.