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 workflow redakcyjny powiązany z PHP-owymi template parts, 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 (renderer customowych shortcodów, wtyczka “performance” próbująca cofnąć render-blocking CSS motywu i trzecia spinająca menu walker z biblioteką megamenu).
Przebudowa przeniosła całą warstwę na block theme. Fluidowa typografia i skala odstępów wylądowały w theme.json. Shortcody zamieniły się w cztery customowe bloki zbudowane z @wordpress/scripts i renderowane serwerowo. Megamenu zwinęło się do natywnego bloku nawigacyjnego plus jednego wzorca. Po launchu 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. Workflow redakcyjny poprawił się przy okazji: redakcja przestała otwierać tickety z prośbami o dodanie sekcji, bo wzorce dawały im to, czego potrzebowali.
Workflow redakcyjny 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 wersje 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 customowym motywem warto zaczynać tylko wtedy, kiedy projekt wymaga kontrolowanej biblioteki komponentów zamiast freeform buildera, kiedy budżet wydajnościowy jest ciasny na tyle, że generyczny motyw go nie utrzyma, kiedy serwis musi integrować się z CRM, ERP albo systemem fulfillmentu wymagającym customowych bloków i ekranów admina, 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 block theme z małą biblioteką wzorców powstaje szybciej i utrzymuje się łatwiej niż custom build, i powiemy to wprost.
Jak pracujemy
Każde zlecenie zaczyna się od krótkiego review technicznego. Patrzymy na istniejący motyw (albo na pliki projektowe, jeśli to nowy build), hosting, listę wtyczek, custom post types i workflow redakcyjny, z którego zespół faktycznie korzysta. Wynikiem jest pisemna ocena z dwoma lub trzema wariantami implementacji, z trade-offami każdego i realistycznym harmonogramem.
Dalej praca biegnie w milestone’ach, nie w jednej dużej dostawie. Typowa przebudowa motywu dzieli się na discovery, theme.json i bibliotekę wzorców, customowe bloki, migrację treści z testami parity oraz okno launchu z planem rollbacku. 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 block theme z WooCommerce, a setup headless z WordPressem jako warstwą treści to znów osobna sprawa. Wycenę przygotowujemy po review 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 workflowem 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.
FAQ - Najczęściej zadawane pytania
Ile czasu zajmuje stworzenie dedykowanego motywu WordPress? Czas realizacji zależy od stopnia skomplikowania projektu i zakresu funkcjonalności. Prosty motyw możemy przygotować w ciągu dwóch tygodni, natomiast bardziej zaawansowane projekty z pełną integracją e-commerce mogą trwać od jednego do trzech miesięcy. Przed przystąpieniem do pracy zawsze przygotowujemy szczegółowy harmonogram, który uwzględnia wszystkie etapy projektu i pozwala na śledzenie postępów. Elastycznie podchodzimy do terminów i staramy się dostosować do potrzeb klienta.
Ile kosztuje stworzenie dedykowanego motywu WordPress? Koszt zależy od wielu czynników, takich jak zakres projektu, stopień skomplikowania designu, wymagane funkcjonalności i termin realizacji. Przed przystąpieniem do pracy przygotowujemy szczegółową wycenę, która uwzględnia wszystkie oczekiwania klienta. Nasze ceny są transparentne i nie zawierają ukrytych kosztów. Każdy projekt jest wyceniany indywidualnie po dokładnej analizie wymagań.
Czy motyw będzie responsywny i dostosowany do urządzeń mobilnych? Tak, wszystkie nasze motywy są projektowane jako w pełni responsywne. Testujemy je na różnych urządzeniach i przeglądarkach, aby zapewnić idealne wyświetlanie na każdym ekranie. Wykorzystujemy najnowsze techniki CSS, takie jak Flexbox i CSS Grid, które pozwalają na tworzenie elastycznych układów. Dbamy o to, aby nawigacja i interakcje były równie intuicyjne na urządzeniach dotykowych, jak i na komputerach stacjonarnych.
Czy otrzymam kod źródłowy motywu? Tak, po zakończeniu projektu przekazujemy klientowi pełny kod źródłowy motywu. Klient staje się właścicielem całego kodu i może go dowolnie modyfikować lub zlecać modyfikacje innym programistom. Przekazujemy również dokumentację techniczną, która ułatwia zrozumienie struktury kodu i wprowadzanie zmian. Kod jest napisany zgodnie ze standardami WordPressa, co ułatwia jego dalsze rozwijanie.
Jakie technologie są wykorzystywane do tworzenia motywów? Wykorzystujemy nowoczesne technologie, w tym HTML5, CSS3, JavaScript w najnowszej wersji oraz PHP w najnowszej wersji. Stosujemy również WordPress REST API dla integracji z zewnętrznymi systemami. Używamy narzędzi do automatyzacji, takich jak Webpack czy Gulp, które optymalizują proces tworzenia i wdrażania. Wszystkie nasze rozwiązania są zgodne z aktualnymi standardami webowymi i najlepszymi praktykami branżowymi.
Czy motyw będzie zoptymalizowany pod kątem SEO? Tak, wszystkie nasze motywy są projektowane zgodnie z najlepszymi praktykami SEO. Zawierają semantyczny kod HTML, odpowiednią strukturę nagłówków, możliwość ustawienia meta danych oraz wsparcie dla schematów danych strukturalnych. Dbamy o czystość kodu i szybkość ładowania, co ma pozytywny wpływ na pozycjonowanie w wyszukiwarkach. Nasze motywy są również kompatybilne z popularnymi wtyczkami SEO.
Czy mogę zlecić tylko modyfikację istniejącego motywu? Tak, oferujemy również usługi adaptacji i modyfikacji istniejących motywów WordPress. Możemy dostosować gotowy szablon do indywidualnych potrzeb lub wprowadzić konkretne zmiany w już działającej stronie. Pracujemy z różnymi typami motywów, zarówno darmowymi, jak i komercyjnymi. Modyfikacje są realizowane w sposób, który nie wpływa na przyszłe aktualizacje oryginalnego motywu.
Jak wygląda proces pracy nad projektem? Po wstępnej konsultacji przygotowujemy szczegółowy plan projektu i harmonogram prac. Następnie przedstawiamy projekt graficzny do zatwierdzenia i przystępujemy do programowania. Podczas całego procesu regularnie informujemy o postępach i konsultujemy z klientem wszystkie istotne decyzje. Zapewniamy przejrzystą komunikację i elastyczne podejście do zmian w projekcie. Finalny produkt jest starannie testowany przed oddaniem do użytku.
Czy oferujecie wsparcie po wdrożeniu? Tak, zapewniamy kompleksowe wsparcie powdrożeniowe. Oferujemy pakiety serwisowe, które obejmują pomoc techniczną, aktualizacje i modyfikacje. Możesz również zgłaszać pojedyncze problemy, które rozwiązujemy w krótkim czasie. Nasz zespół jest dostępny dla klientów i reaguje na ich potrzeby z pełnym zaangażowaniem.
Czy motyw będzie bezpieczny? Bezpieczeństwo jest naszym priorytetem. Stosujemy najlepsze praktyki kodowania i walidacji danych, co minimalizuje ryzyko ataków. Regularnie aktualizujemy nasze motywy, aby eliminować potencjalne luki w zabezpieczeniach. Wszystkie dane są odpowiednio szyfrowane i chronione przed nieautoryzowanym dostępem.
Czy możliwa jest integracja z zewnętrznymi systemami i API? Tak, mamy doświadczenie w integracji z różnymi systemami zewnętrznymi, w tym bramkami płatności, systemami logistycznymi, CRM i innymi API. Każda integracja jest starannie planowana i implementowana zgodnie z najlepszymi praktykami. Dbamy o to, aby integracje były niezawodne i bezpieczne.
Jak długo trwa wsparcie i aktualizacje? Czas wsparcia i aktualizacji zależy od wybranego pakietu. Oferujemy różne opcje, od jednorazowych aktualizacji po roczne pakiety wsparcia, które zapewniają ciągłą opiekę nad motywem. Możesz wybrać opcję najlepiej dopasowaną do swoich potrzeb i budżetu.
