Tworzenie stron WordPress i sklepów oraz adaptacja
Większość projektów, które do nas trafiają, to nie greenfield. To kod odziedziczony po poprzednim wykonawcy, najczęściej z lat 2018-2020, z functions.php rozrośniętym do 1500-2000 linii, kilkoma “must-use” wtyczkami zainstalowanymi nieformalnie i hierarchią szablonów, która rozsypuje się przy pierwszym custom post type. To stała część naszej pracy, nie wyjątek.
Adaptujemy taką bazę zamiast łatać kolejne miejsce z błędem. Decyzja, czy mapujemy istniejący motyw na block theme z theme.json, czy zostajemy przy klasycznym motywie po refaktoryzacji, zapada po review kodu, a nie wcześniej.
Block theme czy motyw klasyczny w 2026
Full Site Editing jest dziś domyślnym punktem wyjścia dla nowych projektów WordPress. Wybór między motywem blokowym a klasycznym nie jest już kwestią stylu, tylko architektury, z konsekwencjami dla edytora, przenośności treści i ilości PHP do utrzymania.
Block theme ma sens, kiedy redakcja potrzebuje bezpośredniej kontroli nad układem, kiedy serwis opiera się na powtarzalnych wzorcach zamiast sztywnych szablonów i kiedy większość intencji projektowych można wyrazić w theme.json. Konfiguracja obejmuje paletę kolorów, fluidową typografię przez clamp(), skalę odstępów i wariacje stylów per blok. W połączeniu z register_block_pattern_category oraz biblioteką wzorców rejestrowanych przez register_block_pattern redakcja dostaje kontrolowany zestaw komponentów zamiast wolnego płótna.
Motyw klasyczny pozostaje uzasadniony w wąskich przypadkach: rozbudowany sklep WooCommerce z własnymi szablonami checkoutu, wieloletni proces redakcyjny powiązany z PHP-owymi częściami szablonu, projekt mocno oparty na ACF, do którego redakcja jest przyzwyczajona. Nie migrujemy działających klasycznych motywów do FSE dla samej zasady. Migrujemy wtedy, kiedy koszt utrzymania starej struktury przekracza koszt przebudowy.
Czego unikamy: block theme, który omija theme.json i hardkoduje style w CSS, albo klasyczny motyw doklejony do pojedynczych bloków Gutenberga. Oba wzorce produkują rozdzieloną logikę, przez którą prosta poprawka zmienia się w tydzień śledztwa rok później.
Custom blocks w sensowny sposób
Customowe bloki należą do @wordpress/scripts, z plikiem block.json opisującym atrybuty, supports i skrypty edytora. Renderowanie po stronie serwera przez render_callback utrzymuje spójność markupu między edytorem a frontendem, eliminuje hydration mismatch i pozwala ewoluować HTML bez psucia starszych wpisów. Statyczne bloki zapisywane do post_content nadal mają sens dla czysto strukturalnych elementów (callout, wrapper layoutu), ale wszystko, co zależy od dynamicznych danych, powinno renderować się serwerowo.
Wydajność tam, gdzie naprawdę widać
Cele Core Web Vitals, według których pracujemy: LCP poniżej 2,0 s, CLS poniżej 0,05, INP poniżej 200 ms. Osiąganie tych liczb na realnej instalacji WordPressa polega głównie na usuwaniu, nie dodawaniu. Inline’ujemy krytyczny CSS dla widoku above the fold, odraczamy lub usuwamy renderujący JavaScript, zdejmujemy zależność od jQuery, którą klasyczne motywy nadal wciągają, rezerwujemy miejsce na media, żeby trzymać CLS w ryzach. Nie chodzi o wynik audytu. Chodzi o to, że LCP 2,4 s i LCP 0,7 s zachowują się inaczej w danych konwersji, a tę drugą wartość daje się osiągnąć na współdzielonym hostingu z poprawnie zbudowanym motywem.
Praca z motywami odziedziczonymi po poprzednim wykonawcy
Polskie agencje internetowe często wracają do nas z motywami z lat 2018-2020, które przeszły przez ręce dwóch lub trzech zespołów. Refaktoryzacja takich projektów to jeden z najczęstszych kształtów naszej pracy. Wzorce, które rozplątujemy:
- Motywy potomne nadpisujące rodzica bezpośrednio w
functions.phpzamiast przezadd_filteriadd_action, więc aktualizacja motywu rodzica po cichu psuje połowę serwisu. - Motywy zbudowane przed Gutenbergiem, rejestrujące sidebary i widgety nieużywane przez redakcję od dwóch lat, ale wciąż ładujące swoje zasoby na każdej podstronie.
- Customowe szablony stron oparte na zmiennych globalnych ustawianych w
header.php, które znikają, gdy WordPress przechodzi na blokowy header pattern. - Nadpisania szablonów WooCommerce skopiowane ze starszych wersji wtyczki, dryfujące dwa lub trzy minor release za kanonicznymi szablonami.
Nie łatamy w miejscu. Mapujemy każdą custom funkcję na blok, wzorzec albo małą skupioną wtyczkę, a potem przebudowujemy motyw na bazie theme.json i czystej hierarchii szablonów. Stary motyw zostaje na stagingu, dopóki nowy nie przejdzie testów parity.
Niedawna przebudowa
Jedno zlecenie, które dobrze oddaje typowy kształt tej pracy: motyw z 2018 roku, około 1400 linii functions.php, sześć obszarów widgetów, z których redakcja przestała korzystać, LCP 2,4 s na stronie głównej. Serwis polegał na trzech wtyczkach istniejących wyłącznie po to, żeby obejść ograniczenia oryginalnego motywu: jedna renderowała własne shortcody, druga próbowała odkręcić CSS blokujący renderowanie, trzecia spinała walker menu z biblioteką megamenu.
Przebudowa przeniosła całą warstwę na motyw blokowy. Fluidowa typografia i skala odstępów wylądowały w theme.json. Shortcody zamieniły się w cztery własne bloki zbudowane z @wordpress/scripts i renderowane serwerowo. Megamenu zwinęło się do natywnego bloku nawigacyjnego plus jednego wzorca. Po uruchomieniu LCP spadło do 700 ms na tym samym hostingu, trzy łatkowe wtyczki wyleciały, a functions.php skurczył się do około 180 linii robiących tylko to, czego nie da się wyrazić w theme.json ani w konfiguracji bloków. Praca redakcji poprawiła się przy okazji: zespół przestał otwierać zgłoszenia z prośbami o dodanie sekcji, bo wzorce dawały im to, czego potrzebowali.
Praca redakcyjna po polsku
Polskie projekty w naszych rękach to zwykle dwujęzyczność PL/EN przez WPML albo Polylang, czasem trójjęzyczność z dołożonym DE. Konfigurujemy theme.json tak, żeby paleta kolorów, kroje pisma i wzorce blokowe były neutralne wobec języka, a same wzorce mają warianty z poprawnie sformatowanymi cudzysłowami drukarskimi („…”) i polską typografią (myślnik półpauzowy zamiast en/em-dasha, niełamliwe spacje przed jednoliterowymi przyimkami w nagłówkach).
Redakcja najczęściej dostaje od nas zestaw 8-12 wzorców pokrywających cykl publikacji: lead z autorem, callout, cytat, pull quote, bibliografię, dwie wersję CTA i kilka layoutów dwukolumnowych. WPML String Translation jest wpięty w theme.json na poziomie etykiet wzorców, co eliminuje typową bolączkę polskich redakcji - mieszanie polskich i angielskich nazw bloków w jednym wpisie.
Dedykowany motyw kontra dobrze skonfigurowany motyw blokowy
Pracę nad dedykowanym motywem warto zaczynać tylko wtedy, kiedy projekt wymaga kontrolowanej biblioteki komponentów zamiast swobodnego buildera, kiedy budżet wydajnościowy jest tak ciasny, że gotowy motyw go nie utrzyma, kiedy serwis musi integrować się z CRM, ERP albo systemem obsługi zamówień wymagającym własnych bloków i ekranów administracyjnych, albo kiedy odziedziczony motyw narósł takim długiem technicznym, że utrzymanie kosztuje kwartalnie więcej niż jednorazowa przebudowa.
To nie jest dobra droga, kiedy projekt to pięciostronicowa wizytówka bez integracji i bez presji wydajnościowej. W tym scenariuszu dobrze skonfigurowany motyw blokowy z małą biblioteką wzorców powstaje szybciej i utrzymuje się łatwiej niż dedykowana przebudowa, i powiemy to wprost.
Jak pracujemy
Każde zlecenie zaczyna się od krótkiego przeglądu technicznego. Patrzymy na istniejący motyw albo na pliki projektowe, jeśli to nowa budowa, hosting, listę wtyczek, własne typy treści i sposób pracy redakcji, z którego zespół faktycznie korzysta. Wynikiem jest pisemna ocena z dwoma lub trzema wariantami implementacji, z zaletami i kosztami każdego wariantu oraz realistycznym harmonogramem.
Dalej praca biegnie etapami, nie w jednej dużej dostawie. Typowa przebudowa motywu dzieli się na rozpoznanie, theme.json i bibliotekę wzorców, własne bloki, migrację treści z testami zgodności oraz okno uruchomienia z planem wycofania zmian. Kod od pierwszego dnia leży w Git, działa na środowisku staging odzwierciedlającym produkcję i wjeżdża przez CI, nie przez FTP.
Wycena jest indywidualna, bo projekty rzadko wyglądają tak samo. Ukierunkowana refaktoryzacja motywu to inna półka niż pełna przebudowa na motyw blokowy z WooCommerce, a konfiguracja headless z WordPressem jako warstwą treści to znów osobna sprawa. Wycenę przygotowujemy po przeglądzie technicznym, na zdefiniowany zakres.
Wydajność i Core Web Vitals w realnych warunkach
Polskie hostingi współdzielone bywają wolniejsze niż europejska średnia, więc budżet wydajnościowy planujemy ostro. Wartości, które trzymamy: LCP poniżej 2,0 s na 4G, CLS poniżej 0,05, INP poniżej 200 ms. Inline’ujemy krytyczny CSS dla widoku above the fold i odraczamy resztę. Skrypty admin-ajax i jQuery, które klasyczne motywy często ciągną do frontendu, są wycinane lub kolejkowane warunkowo.
Obrazy hero podajemy w AVIF z fallbackiem WebP, fonty preloadujemy tylko dla wariantów rzeczywiście używanych above the fold (z reguły jedna waga regular i jedna semibold). Reszta wag ładuje się leniwie. Dla redakcji to oznacza, że nawet artykuł z ośmioma obrazami w treści mieści się w LCP poniżej sekundy na średnim łączu mobilnym.
Bezpieczeństwo i zgodność
Sanitizacja wejścia, escapowanie wyjścia, weryfikacja nonce w każdym formularzu, prepared statements w $wpdb. To minimum, nie cecha. Customowe role i capabilities trzymamy zgodnie z zasadą najmniejszego uprzywilejowania - redaktor nie powinien móc instalować wtyczek, klient nie powinien mieć dostępu do plików motywu. Dla projektów wymagających RODO konfigurujemy mechanizmy zgody przed ładowaniem skryptów zewnętrznych (Google Analytics, Meta Pixel, mapy) i logujemy zdarzenia consent po stronie serwera, nie tylko w localStorage przeglądarki.
Refleksja końcowa
Praca nad motywem to w dużej mierze decydowanie, co usunąć. Większość problemów z wydajnością, bezpieczeństwem i procesem redakcyjnym, które trafiają do nas, zaczyna się od motywu robiącego za dużo: ładującego render-blocking CSS dla sekcji, których nikt nie używa, rejestrującego custom post types, które nigdy nie weszły do procesu, podpinającego się pod filtry, których już nie ma. Czysty motyw na bazie theme.json, mała biblioteka bloków i wzorców oraz functions.php mieszczący się na jednym ekranie przeżyje każdy “all-in-one” motyw z marketu.
Jeśli masz odziedziczony motyw WordPress, który przestał obsługiwać biznes, albo nowy projekt, w którym chcesz mieć przemyślaną architekturę przed finalizacją designu, napisz przez stronę kontaktową. Zaczniemy od review technicznego i indywidualnej wyceny.
