Dlaczego w Lumina nie budujemy stron opartych na WordPressie

WordPress nie jest zły. Po prostu często trafia do złego projektu

WordPress rozwiązał realny problem. Pozwala szybko uruchomić stronę, oddać edycję treści klientowi i korzystać z ogromnego ekosystemu gotowych rozszerzeń. Dla prostego bloga, małej strony informacyjnej albo projektu zbudowanego wokół publikowania treści nadal może być rozsądnym wyborem.

Problem zaczyna się później. Firma zamawia stronę, po kilku miesiącach dokłada katalog, formularz ofertowy, integrację z CRM-em, kilka wersji językowych, konta klientów i niestandardowe reguły dostępu. System, który miał zarządzać treścią, zaczyna udawać aplikację.

Każde kolejne wymaganie da się jeszcze „jakoś zrobić”. Następna wtyczka, fragment PHP w motywie, dodatkowa tabela, webhook uruchamiany przy zapisie wpisu. Po dwóch latach nikt nie potrafi już powiedzieć, gdzie kończy się WordPress, a zaczyna właściwy produkt.

W Lumina nie budujemy nowych stron na WordPressie, ponieważ większość naszych projektów nie kończy się na pięciu podstronach i formularzu kontaktowym. Tworzymy strony B2B, aplikacje webowe, systemy z integracjami i produkty, które mają być rozwijane. W takim środowisku wygodny start nie może być ważniejszy niż przewidywalna architektura.

Problem zaczyna się, gdy CMS staje się architekturą

CMS powinien odpowiadać za treść. Produkt powinien mieć własny model domenowy, logikę, API i zasady dostępu.

W klasycznym wdrożeniu WordPress często pełni wszystkie role naraz:

• przechowuje treść,
• renderuje frontend,
• obsługuje formularze,
• zarządza użytkownikami,
• realizuje wyszukiwanie,
• wysyła wiadomości,
• integruje płatności,
• udostępnia dane zewnętrznym systemom,
• przechowuje konfigurację biznesową.

Na początku jest to wygodne. Jeden panel, jedna baza i jeden hosting. Z czasem każda warstwa zaczyna zależeć od pozostałych. Zmiana sposobu prezentowania treści wymaga ingerencji w motyw. Integracja wpływa na zapis postów. Aktualizacja wtyczki zmienia strukturę danych albo sposób generowania HTML-u.

To nie jest wyłącznie problem WordPressa. Każdy monolit może zostać źle zaprojektowany. WordPress jednak szczególnie łatwo zachęca do dokładania funkcji bez postawienia granicy między treścią a logiką produktu.

Jeżeli strona ma być częścią większego systemu, fundament powinien to uwzględniać od początku.

Wtyczki są zależnościami, nie darmowymi funkcjami

„Jest do tego wtyczka” brzmi jak zamknięcie tematu. W rzeczywistości dopiero go otwiera.

Każda wtyczka jest zewnętrzną zależnością. Ma własnego autora, cykl wydań, sposób przechowywania danych, model licencji i podejście do kompatybilności. Może zostać porzucona, sprzedana innemu dostawcy albo zmienić warunki płatności.

Przed dodaniem rozszerzenia trzeba odpowiedzieć na kilka pytań:

• Czy jest regularnie utrzymywane?
• Czy działa z obecną wersją PHP i WordPressa?
• Jak przechowuje dane?
• Czy potrafimy je wyeksportować?
• Czy ładuje zasoby na każdej stronie?
• Czy zmienia publiczny HTML?
• Jak reaguje na błędy zewnętrznego API?
• Co stanie się po wyłączeniu licencji?

Trzydzieści aktywnych wtyczek nie oznacza automatycznie złego projektu. Oznacza jednak trzydzieści elementów, których zgodność trzeba kontrolować. Aktualizacja jednej części może zmienić zachowanie formularza, cache, edytora albo procesu płatności.

Gotowa funkcja nie jest darmowa. Jej koszt został tylko przesunięty z implementacji na utrzymanie i ryzyko.

Wydajności nie naprawia się trzema wtyczkami cache

Wolny WordPress często dostaje kolejną warstwę cache, minifikację, lazy loading i CDN. Wynik w Lighthouse rośnie. Źródło problemu zostaje.

Wydajność zależy między innymi od:

• czasu generowania odpowiedzi na serwerze,
• liczby zapytań do bazy,
• kodu uruchamianego przez motyw i wtyczki,
• wielkości HTML-u,
• liczby skryptów i arkuszy stylów,
• sposobu ładowania obrazów i fontów,
• zewnętrznych widgetów,
• cache na poziomie aplikacji, serwera i CDN-u.

Jeśli każda wtyczka dorzuca własny JavaScript, CSS i zapytania, optymalizacja staje się próbą ograniczania skutków architektury. Można wygrać kilka punktów kompresją. Trudniej odzyskać kontrolę nad kodem, który jest ładowany niezależnie od potrzeb konkretnego widoku.

Szybki WordPress jest możliwy. Wymaga jednak dyscypliny, dobrego hostingu, kontroli rozszerzeń i świadomego motywu. To nie jest stan domyślny uzyskiwany po instalacji wtyczki „performance”.

Jeśli chcesz zobaczyć, jak diagnozujemy rzeczywiste źródła problemów, przeczytaj przewodnik o Core Web Vitals albo sprawdź usługę optymalizacji Core Web Vitals.

Aktualizacje i bezpieczeństwo mają koszt

Sam WordPress jest aktywnie rozwijany i ma dojrzały proces bezpieczeństwa. Ryzyko pojawia się w całym wdrożeniu: rdzeniu, motywie, rozszerzeniach, konfiguracji serwera, kontach administratorów oraz własnym kodzie.

Aktualizacja nie powinna wyglądać tak:

1. kliknij „aktualizuj wszystko”,
2. otwórz stronę główną,
3. jeśli działa, uznaj temat za zamknięty.

Potrzebne są kopie zapasowe, środowisko testowe, kontrola kluczowych procesów i plan wycofania zmiany. Formularz może nadal wyglądać poprawnie, ale przestać wysyłać dane. Integracja może odpowiadać błędem tylko dla części przypadków. Zmiana w motywie może popsuć dane strukturalne lub canonicale bez widocznego błędu na ekranie.

Im więcej rozszerzeń i niestandardowych fragmentów, tym większa powierzchnia aktualizacji. Firma płaci za nią nawet wtedy, gdy faktura nie zawiera pozycji „utrzymanie zależności”. Płaci przestojem, ręcznymi testami albo odkładaniem aktualizacji do momentu, w którym robi się naprawdę niebezpiecznie.

Customowa funkcja szybko wychodzi poza model CMS-a

WordPress świetnie zna wpisy, strony, taksonomie, użytkowników i media. Problem pojawia się, gdy produkt operuje na innych pojęciach.

System ofertowania potrzebuje klientów, wersji ofert, pozycji cenowych, zatwierdzeń, komentarzy i historii zmian. Platforma B2B może mieć organizacje, oddziały, role, limity, cenniki oraz zamówienia zależne od umowy. Aplikacja terenowa pracuje na lokalizacji, zdarzeniach, aktywności i danych synchronizowanych z wielu źródeł.

Da się odwzorować te elementy jako custom post types, pola i metadata. Pytanie nie brzmi jednak: „czy się da?”. Pytanie brzmi: „czy taki model pozostanie czytelny, testowalny i bezpieczny po kolejnych dwóch latach rozwoju?”.

Jeśli logika biznesowa jest najważniejszą częścią produktu, powinna mieć własny model. Nie powinna być zbiorem hooków uruchamianych przy zapisie wpisu.

Integracje obnażają granice monolitu

Prosty formularz wysłany na e-mail nie wymaga rozbudowanej architektury. Integracja z CRM-em, ERP-em, systemem magazynowym albo zewnętrzną usługą wymaga już znacznie więcej.

Trzeba obsłużyć:

• uwierzytelnienie,
• limity API,
• ponawianie żądań,
• błędy częściowe,
• idempotencję,
• kolejki i zadania asynchroniczne,
• mapowanie danych,
• monitoring,
• historię synchronizacji.

Najgorszy wariant to integracja ukryta w callbacku formularza. Użytkownik klika „Wyślij”, request czeka na trzy zewnętrzne systemy, a każdy z nich może odpowiedzieć wolno albo wcale. Gdy proces nie ma jawnych statusów i logów, zespół dowiaduje się o problemie od klienta.

Własny backend nie gwarantuje dobrej integracji. Daje jednak możliwość zaprojektowania jej jako osobnego procesu zamiast efektu ubocznego zapisu treści.

Edycja treści nie wymaga WordPressa

Najczęstszy argument brzmi: „klient musi sam zmieniać teksty”. Oczywiście, że musi. Nie wynika z tego jednak, że cały system powinien działać na WordPressie.

Headless CMS oddziela panel redakcyjny od frontendu. Redaktor zarządza treścią, a aplikacja pobiera ją przez API. Frontend może działać w Next.js lub Nuxt, być statycznie generowany, korzystać z CDN-u i wdrażać się niezależnie od panelu.

Taki podział nie jest potrzebny każdej firmie. Ma sens wtedy, gdy:

• treść trafia do kilku kanałów,
• frontend wymaga pełnej kontroli,
• strona łączy content z danymi aplikacyjnymi,
• zespół rozwija część redakcyjną i produktową niezależnie,
• wydajność oraz sposób renderowania są istotne.

Sam WordPress może również działać headless dzięki REST API. To rozsądna opcja przy migracji albo gdy zespół redakcyjny jest mocno związany z jego panelem. Nie usuwa jednak automatycznie kosztu utrzymania WordPressa jako źródła treści.

Jaką architekturę wybieramy w Lumina

Nie zaczynamy od frameworka. Zaczynamy od odpowiedzialności systemu.

Typowy podział wygląda tak:

CMS -> treści redakcyjne
API -> logika, dane i integracje
Next.js / Nuxt -> frontend i renderowanie
PostgreSQL -> dane domenowe
CDN -> szybkie dostarczanie zasobów

Nie każda strona potrzebuje wszystkich tych elementów. Prosty serwis może działać jako statyczny frontend z lekkim CMS-em. Aplikacja potrzebuje API, bazy, uwierzytelnienia i monitoringu. Ważne, żeby każda warstwa miała konkretną rolę.

Dzięki temu zmiana panelu treści nie wymaga przepisywania produktu. Integracja nie blokuje renderowania strony. Frontend nie musi znać tabel należących do CMS-a. Możemy również rozwijać aplikację webową bez dopasowywania jej modelu do systemu publikacji.

Kiedy WordPress ma sens

WordPress jest sensownym wyborem, gdy projekt jest przede wszystkim publikacją treści, a gotowy ekosystem naprawdę skraca drogę do celu.

Rozważylibyśmy go na przykład wtedy, gdy:

• firma potrzebuje klasycznego bloga lub magazynu,
• redakcja zna już panel i proces publikacji,
• budżet nie pozwala na osobny frontend i CMS,
• funkcje mieszczą się w dobrze utrzymanych rozszerzeniach,
• projekt ma przewidywalny zakres,
• organizacja akceptuje regularne utrzymanie i aktualizacje.

Nie ma sensu budować dedykowanego systemu tylko po to, żeby opublikować dziesięć podstron i aktualność raz na kwartał. Technologia ma odpowiadać skali problemu.

Odrzucenie WordPressa z przyzwyczajenia byłoby tak samo bezmyślne jak wybieranie go do każdego projektu.

Kiedy WordPressa nie wybieramy

Nie wybieramy go, gdy już na starcie wiadomo, że strona stanie się produktem albo panelem operacyjnym.

Czerwone flagi to:

• niestandardowe role i rozbudowane uprawnienia,
• wieloetapowe procesy biznesowe,
• intensywne integracje,
• dane o strukturze dalekiej od treści redakcyjnej,
• wymagania czasu rzeczywistego,
• rozbudowana praca offline,
• wiele klientów korzystających z jednego systemu,
• osobne aplikacje korzystające z tego samego API,
• rozwój planowany jako stały proces, a nie jednorazowe wdrożenie.

W takim projekcie WordPress nie upraszcza architektury. Odkłada decyzję o niej na później, kiedy migracja jest już droższa.

Migracja z WordPressa bez utraty SEO

Migracja nie polega na skopiowaniu tekstów i zmianie DNS-u. Trzeba zachować znaczenie istniejących adresów, metadane i sygnały zbudowane przez domenę.

Plan powinien obejmować:

• eksport i oczyszczenie treści,
• mapę starych oraz nowych URL-i,
• przekierowania 301,
• canonicale,
• metadata i dane strukturalne,
• obrazy oraz ich adresy,
• sitemapę XML,
• robots.txt,
• linkowanie wewnętrzne,
• weryfikację błędów 404,
• monitoring Search Console po wdrożeniu.

Nie każda stara podstrona zasługuje na przeniesienie. Treści bez ruchu i wartości można połączyć albo usunąć, ale musi to być świadoma decyzja. Masowe kierowanie wszystkich starych adresów na stronę główną nie jest strategią migracji.

Jeżeli obecny system urósł poza swoje pierwotne założenia, zobacz, jak podchodzimy do modernizacji aplikacji webowych.

Koszt wdrożenia to nie całkowity koszt posiadania

WordPress często wygrywa ceną startową. To uczciwa przewaga, jeśli zakres rzeczywiście pozostanie prosty.

Porównanie powinno jednak uwzględniać kilka lat działania:

• hosting i środowiska,
• płatne licencje,
• aktualizacje,
• kopie zapasowe,
• monitoring,
• naprawy konfliktów,
• rozwój niestandardowych funkcji,
• koszty ręcznej pracy wynikającej z ograniczeń systemu,
• przyszłą migrację.

Dedykowana architektura również kosztuje. Wymaga projektu, implementacji, testów i utrzymania. Jej przewaga pojawia się wtedy, gdy wspiera właściwy proces zamiast zmuszać firmę do obchodzenia ograniczeń gotowego narzędzia.

Najtańszy start może być najdroższym wariantem po trzech latach. Najdroższy start może być niepotrzebnym przerostem formy. Bez poznania planu rozwoju oba wybory są zgadywaniem.

Checklista przed wyborem technologii

• Czy projekt jest stroną informacyjną, czy początkiem produktu?
• Kto i jak często będzie publikował treści?
• Jakie dane poza treścią trzeba przechowywać?
• Czy system ma obsługiwać konta, organizacje i role?
• Jakie integracje są potrzebne dziś, a jakie za rok?
• Czy dane będą wykorzystywane przez inne aplikacje?
• Jak ważna jest niezależność frontendu od CMS-a?
• Kto będzie utrzymywał aktualizacje i bezpieczeństwo?
• Czy potrafimy wyeksportować treści i dane bez utraty struktury?
• Jaki jest koszt ręcznych obejść w obecnym procesie?
• Czy zakres naprawdę mieści się w gotowych rozszerzeniach?
• Co stanie się po podwojeniu liczby użytkowników, treści i integracji?

Podsumowanie

Nie budujemy nowych stron na WordPressie dlatego, że nie chcemy zaczynać produktu od ograniczeń systemu zarządzania treścią.

WordPress może być bardzo dobrym narzędziem dla bloga, magazynu i przewidywalnej strony informacyjnej. Nie powinien jednak automatycznie stawać się bazą aplikacji, systemu B2B albo procesu, którego jeszcze nie zdążyliśmy dobrze opisać.

Jeżeli budujemy produkt od zera, wolimy kontrolować architekturę niż dopasowywać produkt do CMS-a.

To oznacza więcej decyzji na początku. Oznacza też mniej przypadkowych zależności, czytelniejszy model danych i możliwość rozwoju bez kolejnej warstwy obejść.

Źródła techniczne

• WordPress REST API Handbook: https://developer.wordpress.org/rest-api/
• WordPress Security Handbook: https://developer.wordpress.org/advanced-administration/security/
• Hardening WordPress: https://developer.wordpress.org/advanced-administration/security/hardening/