Motyw potomny to standardowa praktyka WordPress od 2009 roku, ale wielu deweloperów nadal albo edytuje motyw nadrzędny bezpośrednio, albo używa pluginów typu Code Snippets do zarządzania CSS. Oba podejścia są problematyczne: pierwsze rozsypuje się przy aktualizacji, drugie rozmywa odpowiedzialność za kod między bazą danych a plikami. Ten tekst pokazuje krok po kroku, jak zbudować solidny motyw potomny Astra, który wytrzyma aktualizacje i pozwoli skalować projekt klienta przez lata.
Astra Pro jest domyślnym wyborem w naszym studio od 2018 roku, a architektura motyw potomny stała się centralnym elementem każdego projektu B2B. Konwencja, którą tu opisujemy, była iterowana przez 20+ produkcyjnych wdrożeń (Niemiec, Austrii i Szwajcarii plus Polska) i jest publikowana jako referencja dla innych deweloperów oraz dla klientów technicznych, którzy chcą zrozumieć „co dokładnie kupują”. Stack: Astra Pro 4.x plus WordPress 6.7 plus Gutenberg. Dla kontekstu rekomendujemy też nasz tekst o Gutenberg vs Elementor.
Dlaczego motyw potomny, a nie edycja Astra Pro bezpośrednio
Astra Pro otrzymuje aktualizacje co 2-4 tygodnie. Aktualizacje są ważne, bo dostarczają łatki bezpieczeństwa, kompatybilność z najnowszym WordPress, oraz nowe funkcje (np. ostatnio wsparcie Container Query w 4.x). Jeśli edytujesz pliki motyw nadrzędny bezpośrednio, każda aktualizacja nadpisuje twoje zmiany i klient widzi nagle „rozsypaną” stronę po automatycznej aktualizacji. Naprawa zajmuje 2-4 godziny i jest powtarzalnym kosztem na każdą aktualizację.
Motyw potomny rozwiązuje ten problem strukturalnie. Motyw nadrzędny (Astra Pro) dostarcza narzędzie programistyczne, otrzymuje aktualizacje, jego pliki nie są modyfikowane. Motyw potomny zawiera tylko twoje zmiany brandowe: paleta kolorów, fonty, nadpisania layoutu, własne bloki, integracje z pluginami. Aktualizacja Astra Pro nie wpływa na motyw potomny, bo WordPress ładuje pliki motyw potomny z wyższym priorytetem.
Drugi argument za motyw potomny: rozdział odpowiedzialności. Motyw nadrzędny = decyzje narzędzie programistyczne, motyw potomny = decyzje brandowe. Ta separacja jest cenna dla zespołu projektowego: system designu, fonty, kolory są w jednym miejscu (motyw potomny), zmiana brandingu sprowadza się do edycji 3-5 plików, nie do polowania na hardcoded styles w 50 plikach motyw nadrzędny.
Konfiguracja: pięć plików, które tworzą motyw potomny
Minimalny działający motyw potomny wymaga 5 plików. Poniżej kopiowalny szablon, który stosujemy dla każdego nowego klienta.
Plik 1: style.css. Ten plik MUSI mieć w nagłówku WordPress metadane o motyw potomny, w tym kluczowe Template: astra. Bez tej dyrektywy WordPress nie rozpozna folderu jako motyw potomny.
/*
Theme Name: My Own Astra Child
Description: własny motyw potomny bazujący na Astra Pro
Template: astra
Version: 1.0.0
Text Domain: my-child
*/Plik 2: functions.php. Tutaj rejestrujemy motyw nadrzędny styles plus child styles, ładujemy textdomain dla wersji wielojęzycznych, rejestrujemy własne wzorce bloków, dodajemy hooki. Główny element to enqueue parent + child stylesheet z łańcuchem zależności i filemtime jako pamięć podręczna busting (opisane szerzej w sekcji o najlepszych praktykach enqueue).
Plik 3: screenshot.png. Obraz 1200×900 pikseli, widoczny w wp-admin pod Appearance plus Themes. To „branding” dla redaktora treści, nie ma wpływu na front-end. Standardowo używamy kompozycji z logo klienta plus dominującym kolorem brandu jako podgląd.
Plik 4: assets/css/main.css. Skompilowane brand styles. W praktyce piszemy w SCSS w lokalnym dev, kompilujemy do main.css przed deploy. Tutaj idą tokeny designu (CSS własny properties), nadpisania grid systemu, reguły typografii, style przycisków, style własnych bloków. To centralny plik brandingu.
Plik 5: assets/js/main.js. Komponenty interaktywne, jeśli są potrzebne (np. animowane przejścia, własny lazy-load, nagłówki sterowane przewijaniem). Dla większości projektów B2B ten plik jest pusty albo minimalny (1-3 KB). Wartość wydajnościowa: nie ładuj 200 KB jQuery, jeśli używasz tylko jednego scroll listenera.
Po stworzeniu 5 plików pakujemy je do ZIP i instalujemy w wp-admin pod Appearance plus Themes plus Add New plus Upload Theme. Aktywujemy. Front-end powinien wyglądać jak parent Astra (czysty domyślny), bo child styles są jeszcze puste. Od tego momentu wszystkie modyfikacje idą tylko do motyw potomny.
Nadpisywanie plików szablonów parent
Każdy plik PHP, który istnieje w motyw nadrzędny, można nadpisać przez stworzenie pliku o tej samej nazwie w motyw potomny. WordPress automatycznie wybierze wersję z motyw potomny. Najczęstsze pliki, które nadpisujemy: header.php, footer.php, single.php (dla własny layout artykułu blog), archive.php (dla własnego listingu), 404.php (dla brandowanej strony błędu).
Hierarchia plików szablonów w WordPress jest dobrze udokumentowana w developer.wordpress.org. Skrótowo: dla single post najpierw szuka single-{post_type}.php, potem single.php, potem singular.php, potem index.php. Każdy z tych plików można nadpisać w motyw potomny.
Astra ma dodatkową warstwę: folder template-parts z modułami header i footer (Header Builder, Footer Builder). Dla własnego layoutu nagłówka kopiujemy template-parts/header/header.php z parent do child i modyfikujemy. Dla własnej stopki analogicznie.
Kiedy nadpisywać, a kiedy używać Astra Customizer: jeśli zmiana jest jednorazowa i prosta (kolor, font, padding) używaj Customizera. Jeśli zmiana jest strukturalna (cały layout nagłówka, własny widget area, brandowana strona 404) nadpisz w motyw potomny. Nasza reguła: nadpisz gdy modyfikacja przekracza 3 linijki CSS lub wymaga logiki PHP.
Własne bloki Gutenberg w motyw potomny
Własne bloki Gutenberg to najmocniejsza dźwignia produktywności dla redaktora treści klienta. Zamiast pisać HTML w „własny HTML block” lub klejić 5 ogólnych bloków razem, redaktor wybiera „Kafelek studium przypadku” z menu i wypełnia 4 pola: tytuł, klient, metryka, link.
Dwa podejścia do własnych bloków. Pierwsze: theme.json plus wzorce bloków (renderowanie po stronie PHP, statyczne wzorce bloków rejestrowane w functions.php). Łatwiejsze, szybsze, ale ograniczone do prostych szablonów bez interaktywności. Drugie: w pełni własny blok (renderowanie po stronie JS, komponent React, build pipeline z webpack lub @wordpress/scripts). Cięższe, ale w pełni elastyczne.
Dla 80% przypadków klienta B2B wystarczają wzorce bloków. Przykład: register block pattern dla „Kafelka cennikowego” z 3 kolumnami, każda zawiera nagłówek plus listę plus przycisk. Redaktor wybiera wzorzec z menu, modyfikuje treść, layout zostaje stały. Konkretny przykład z naszego portfolio: nasz własny serwis ma 6 własnych wzorców bloków dla typowych layoutów stron pakietów.
Theme.json to plik konfiguracyjny WordPress 5.9+, który deklaruje tokeny designu (paleta kolorów, presety typografii, spacing, style obramowań) dostępne dla redaktora treści w Gutenbergu. Cytujesz tam własną paletę kolorów klienta (5-7 kolorów nazwanych: primary, secondary, accent, surface, ink, bg-1, bg-2), typografię (font nagłówków, font tekstu, skala), system spacingu. Redaktor treści widzi te tokeny w UI Gutenberga i nie może wybrać „niezgodnego z brandem” koloru.
Rejestrowanie skryptów i styli: najlepsze praktyki
Wydajność motyw potomny zaczyna się od poprawnego rejestrowania zasobów. Cztery najlepsze praktyki, które stosujemy w każdym projekcie.
Pierwsza: łańcuch zależności. Parent style (astra-style) musi być wpisany jako zależność dla child style. WordPress wtedy ładuje parent przed child, child może nadpisać reguły parent. Bez tej zależności kaskada CSS może działać „losowo” w zależności od mtime plików.
Druga: pamięć podręczna busting przez filemtime. Wersja pliku (parametr version w wp_enqueue_style) powinna być filemtime() pliku. Po deploy zmienia się mtime, pamięć podręczna przeglądarki unieważnia się automatycznie. Bez pamięć podręczna busting klienci widzą starą wersję CSS po deploy, dopóki nie zrobią twardego odświeżenia.
Trzecia: leniwe ładowanie JS dla nie-krytycznych. Skrypty, które nie są potrzebne above-the-fold, ładujemy z atrybutem defer lub async. WP hooks pozwalają opóźnić ładowanie JS selektywnie dla konkretnych identyfikatorów. Korzyść: parser HTML nie blokuje się czekając na JS, LCP poprawia się o 200-500 milisekund typowo.
Czwarta: warunkowe rejestrowanie. Skrypt dla galerii produktowej na stronie pojedynczego produktu nie powinien ładować się na stronie głównej. Sprawdzamy is_produkt() lub get_post_type() przed rejestracją. Konkretny wpływ z naszego portfolio: pakiet JS strony głównej spadł z 45 KB do 18 KB po wprowadzeniu warunkowego rejestrowania dla pojedynczych skryptów branżowo-specyficznych.
Obsługa wersji wielojęzycznych: Polylang plus motyw potomny
Wersje wielojęzyczne są standardem dla klientów B2B w Niemczech, Austrii i Szwajcarii i EU. Motyw potomny musi być przygotowany na tłumaczenia od momentu konfiguracji, nawet jeśli klient startuje z jednym językiem (dodanie później jest 2-3× droższe niż od pierwszego dnia).
Stringi gotowe do tłumaczenia używamy z funkcjami __() lub esc_html__() z text domain motyw potomny. Każdy string widoczny dla użytkownika musi przejść przez funkcję translacyjną z text domain, inaczej Polylang nie złapie go do tłumaczenia.
Plik .pot generujemy narzędziem WP-CLI: wp i18n make-pot. Plik .pot zawiera wszystkie stringi z motyw potomny, gotowe do tłumaczenia. Tłumacz wypełnia .po za język (np. en.po, de.po), kompilujemy do .mo i ładujemy przez load_child_theme_textdomain w functions.php.
Polylang synchronizuje tłumaczenia postów: gdy redaktor tworzy polską wersję posta, Polylang oferuje przycisk „stwórz tłumaczenie EN”. Kopiowane są strukturalnie wszystkie meta plus bloki treści, redaktor tłumaczy tylko teksty. Dla bloków Gutenberg ta synchronizacja działa świetnie, dla struktur danych Elementora często wymaga ręcznej naprawy (kolejny argument za Gutenberg, opisany w naszym tekście porównawczym).
Workflow wdrożenia: lokalny, staging, produkcja
Motyw potomny nie powinien być edytowany na produkcji. Nasz standard: lokalny dev (Local by Flywheel lub wp-env), staging (subdomena klienta na tym samym hostingu), produkcja (główna domena klienta). Każda zmiana przechodzi przez wszystkie trzy środowiska.
Workflow Git: cały folder motyw potomny (theme/) jest w repo Git, oddzielnym dla każdego klienta. Ignorujemy node_modules, .DS_Store, foldery vendor. Strategia branchowania: main dla produkcji, develop dla staging, branche funkcjonalne dla pojedynczych zadań (np. feature/add-pricing-block). Każdy commit ma jasny opis zgodnie z Conventional Commits.
Wdrożenie z lokalnego dev na staging robimy przez SFTP/rsync. Nasz standardowy pipeline: sprawdzenie składni PHP, scp motyw potomny do staging, czyszczenie LSCache (LiteSpeed Cache 7.8.1 aktywny na hostingu Cyber Folks plus Hetzner), lswsctrl restart (CyberPanel only), test dymny 3 stron. Cały proces 5-10 minut z lokalnego pc.
Wdrożenie produkcyjne ze staging jest analogiczne, ale dodajemy kopię zapasową przed deploy (wp db export plus tar -czf folder uploads) i pełny audyt Lighthouse po deploy. Kopia zapasowa jest pakowana do nazwy ze znacznikiem czasu i przechowywana 30 dni. Workflow dokumentujemy w wewnętrznych SOP-ach dla referencji innych klientów. Po wdrożeniu mailujemy klientowi raport zmian. Kontakt do nas: strona kontaktowa.
FAQ
Czy mogę użyć motyw potomny bez Astra Pro (tylko darmowa Astra)?
Tak, architektura motyw potomny działa z Astra Free. Tracisz natomiast część hooks Astra Pro (Header Builder Pro, Footer Builder Pro, własny Layouts, integracje WooCommerce Pro). Dla projektów B2B Astra Pro to konieczność, dla portfolio osobistego Astra Free wystarcza. Cena Astra Pro: 60 USD/rok dla pojedynczej strony, 240 USD/rok agencyjna (nieograniczona liczba stron).
Co po aktualizacji Astra Pro: czy motyw potomny się rozsypie?
Nie, jeśli motyw potomny jest dobrze zbudowane. Najczęstszy problem: motyw potomny polega na funkcji motyw nadrzędny, która została usunięta lub zmieniła sygnaturę w nowej wersji. Rozwiązanie: zawsze obstaw function_exists() i is_callable() sprawdzeniem przed wywołaniem funkcji motyw nadrzędny. Drugi częsty problem: wojny specyficzności CSS, gdy motyw nadrzędny dodał nową regułę z wyższą specyficznością. Rozwiązanie: regularne sprawdzanie staging po każdej aktualizacji Astra, przed promocją na prod.
Czy motyw potomny da się przenieść ze strony na stronę?
Tak, instalacja z ZIP jak każdy motyw. Ale: oczyszczenie funkcji specyficznych dla strony. Jeśli motyw potomny ma hardcoded URL klienta, hardcoded klucze API, lub własne typy postów specyficzne dla strony, te elementy trzeba wyciągnąć przed wdrożeniem na inną stronę. Nasz standard: zmienne brandingowe w jednym pliku konfiguracji (np. inc/config.php), reszta neutralna i przenośna.
Mogę użyć motyw potomny z Elementorem?
Technicznie tak, motyw potomny jest abstrakcyjnie kompatybilne z każdym page builderem. W naszym studio nie rekomendujemy tej kombinacji (patrz Gutenberg czy Elementor). Z Elementor Pro motyw potomny traci większość wartości, bo layout edytowany jest w Elementorze, nie w PHP motyw potomny. Własne bloki Gutenberg w motyw potomny są ortogonalne do widgetów Elementora.
Ile czasu zajmuje budowa motyw potomny od zera?
Realistycznie 40-80 godzin pracy dewelopera dla solidnego motyw potomny klienta B2B. Rozbicie: 4-8 godzin konfiguracja oraz punkt wyjścia (5 plików plus rejestrowanie zasobów plus textdomain), 16-24 godzin stylowanie plus tokeny designu, 12-20 godzin własne wzorce bloków, 4-8 godzin konfiguracja wersji wielojęzycznych, 4-8 godzin testowanie plus wdrożenie. Cena: 6 000-12 000 PLN w naszej wycenie. Więcej o czynnikach wpływających na cenę: wycena strony WordPress.