Motyw potomny WordPress: tworzenie i utrzymanie child theme

Motyw potomny, czyli child theme, pozwala utrzymywać własne zmiany obok zainstalowanego motywu nadrzędnego. Przydaje się przy modyfikowaniu szablonów, rozbudowie warstwy prezentacji oraz przechowywaniu ustawień wyglądu w plikach. Nie trzeba go zakładać wyłącznie dlatego, że witryna działa na WordPressie.

Najpierw nazwij zmianę. Inny kolor przycisku może wystarczyć zapisać w dostępnych ustawieniach stylów. Rozbudowany wariant szablonu, który ma podlegać przeglądowi kodu i przenoszeniu między środowiskami, może uzasadniać osobny motyw potomny. Instalacja buildera jest odrębną decyzją, opisaną w poradniku o instalowaniu page builderów w WordPressie.

Własne pliki dziecka nie zostaną zastąpione paczką aktualizacji rodzica. Ta ochrona nie oznacza jednak zgodności z każdą nową wersją ani odporności na błędy PHP. Zmiana zachowania rodzica może wpłynąć na kod dziecka, dlatego aktualizacja nadal wymaga sprawdzenia.

Nie przenoś do motywu logiki, która powinna działać także po zmianie wyglądu strony. Obsługa własnego procesu biznesowego zasługuje na niezależną wtyczkę. Dzięki temu późniejsza wymiana motywu nie wyłączy funkcji niezwiązanej z prezentacją treści.

Nie działa tu zasada, że każdy plik skopiowany pod tę samą nazwę automatycznie zastępuje plik rodzica. Znaczenie mają hierarchia szablonów oraz sposób wczytania konkretnego zasobu. Rozpoznaj ten mechanizm przed rozpoczęciem edycji, szczególnie przy plikach schowanych w katalogu inc.

Funkcja get_theme_file_path sprawdza plik w motywie potomnym, a następnie szuka go u rodzica. Jeżeli jednak autor załącza pomocniczy plik sztywną ścieżką do katalogu rodzica, samo utworzenie odpowiednika w dziecku nie zmieni tego załączenia. Wtedy poszukaj udokumentowanego filtra, akcji albo innego punktu rozszerzenia.

Zanotuj źródło każdego nadpisania. Opis powinien wskazywać plik bazowy, powód modyfikacji i widoki korzystające ze zmiany. Taka lista jest bardziej pomocna przy aktualizacji niż samo stwierdzenie, że witryna ma child theme.

Zacznij od kopii plików oraz bazy danych i sprawdź możliwość odtworzenia środowiska. Sam katalog motywu nie obejmuje ustawień zapisanych w panelu. Przygotowanie miejsca prób opisuje poradnik o stagingu WordPressa.

Ustal nazwę i wersję rodzica, miejsce przechowywania własnego CSS oraz źródło obecnych szablonów. Sprawdź, czy ktoś wcześniej edytował bezpośrednio pliki motywu. Samo aktywowanie nowego dziecka nie przeniesie takich poprawek. Trzeba je najpierw odnaleźć i ocenić, które nadal są potrzebne.

Przygotuj krótką listę reprezentatywnych widoków: stronę główną, zwykłą stronę, artykuł, archiwum i wyszukiwanie. Dodaj układy specjalne używane w projekcie. Zapisz zrzuty oraz oczekiwane zachowanie menu, stopki i elementów interaktywnych, aby później porównywać te same przypadki.

Kopia powinna mieć odłączone wysyłki oraz integracje wywołujące skutki zewnętrzne. Formularze odbieraj na danych syntetycznych i przechwyconych żądaniach. Jeżeli na stronie działa sklep, próba motywu nie powinna tworzyć rzeczywistych płatności, rezerwacji ani zdarzeń konwersji. Ustal też osobę odpowiedzialną za decyzję o wdrożeniu i warunek wycofania zmiany.

W katalogu wp-content/themes przygotuj osobny folder, na przykład pracownia-child. W nim utwórz style.css z nagłówkiem identyfikującym motyw i jego rodzica. Poniższy przykład zakłada, że rzeczywisty katalog zainstalowanego rodzica nazywa się pracownia:

/*
Theme Name: Pracownia Child
Template: pracownia
Version: 1.0.0
*/

Wartość Template musi odpowiadać nazwie katalogu rodzica, a nie jego nazwie marketingowej widocznej w panelu. Jeśli folder ma inną nazwę, popraw przykład przed użyciem. Nie dopisuj rozszerzenia pliku ani ścieżki do całego katalogu themes.

Dokumentacja motywów potomnych wskazuje style.css jako wymagany plik, natomiast functions.php jest opcjonalny. Minimalny nagłówek pozwala rozpoznać relację motywów, ale sam w sobie nie rozstrzyga sposobu wczytywania arkuszy ani nie dodaje zmian wyglądu.

Rodzic musi pozostać zainstalowany. Przed aktywacją sprawdź, czy WordPress rozpoznaje dziecko i nie zgłasza brakującego motywu nadrzędnego. Gdy pojawia się błąd, zacznij od nazwy folderu i położenia style.css, zamiast kopiować całą zawartość rodzica. Zachowaj prostą strukturę i dodawaj tylko pliki potrzebne do konkretnej modyfikacji.

Najpierw sprawdź, jakie arkusze rodzic już rejestruje oraz ładuje. Obejrzyj kod odpowiedzialny za style i żądania CSS w przeglądarce. Nie dodawaj automatycznie dwóch kolejnych wywołań tylko dlatego, że znalazły się w ogólnym poradniku.

Poniższy przykład zakłada, że rodzic ładuje własny arkusz pod potwierdzonym identyfikatorem pracownia-parent, ale nie ładuje style.css dziecka. Nazwę zależności trzeba zastąpić rzeczywistym identyfikatorem z kodu rodzica. Jeśli ten warunek nie jest spełniony, przykład wymaga dostosowania:

<?php
function pracownia_child_enqueue_styles() {
    wp_enqueue_style(
        'pracownia-child',
        get_stylesheet_uri(),
        array( 'pracownia-parent' ),
        wp_get_theme()->get( 'Version' )
    );
}
add_action( 'wp_enqueue_scripts', 'pracownia_child_enqueue_styles', 20 );

Kod umieszczasz w opcjonalnym functions.php dziecka. Nie kopiuj do niego całego pliku rodzica. Dokumentacja functions.php wyjaśnia, że oba pliki są ładowane, a plik dziecka wcześniej. Własne nazwy funkcji powinny mieć unikalny prefiks, aby ograniczyć konflikty.

Po zmianie sprawdź, czy arkusz pobiera się raz i czy zależność została poprawnie rozwiązana. Priorytet akcji nie zastępuje prawidłowej rejestracji arkusza. Jeśli styl się nie pojawia, skontroluj adres, odpowiedź serwera, pamięć podręczną oraz regułę wygrywającą w narzędziach przeglądarki. Nie naprawiaj każdej kolizji przez dodawanie !important.

Motyw blokowy również może mieć dziecko, ale nie wszystkie zmiany wymagają klasycznego arkusza i szablonów PHP. Ustawienia oraz style mogą wynikać z theme.json, a struktura widoków z plików blokowych. Wprowadzenie do theme.json opisuje ten plik jako wspólny mechanizm ustawień i stylów motywu.

Zdecyduj, czy zmiana ma być utrzymywana w panelu, czy w wersjonowanych plikach. Oba sposoby wymagają porządku. Jeśli ten sam widok jest zmieniany jednocześnie przez redaktora i programistę, łatwo pomylić źródło efektu widocznego na stronie.

Dokumentacja szablonów blokowych wskazuje pierwszeństwo szablonów zapisanych przez użytkownika w bazie przed plikami dziecka i rodzica. Dlatego poprawny plik w templates może nie dać widocznej zmiany. Sprawdź, czy konkretny szablon został wcześniej zapisany w Edytorze witryny.

Przed resetowaniem takiej wersji wyeksportuj lub zachowaj jej zawartość i porównaj ją z plikiem. Ustal, które poprawki mają zostać przeniesione. Nie usuwaj zapisów z bazy tylko po to, aby wymusić rezultat. Przy odbiorze porównaj także edytor z publicznym widokiem oraz sprawdź, czy kolory, typografia i odstępy pozostają spójne.

Po aktywacji dziecka sprawdź stronę jako niezalogowany użytkownik. Panel administracyjny i podgląd edytora nie zastępują publicznego widoku. Przejdź wcześniej przygotowaną listę stron, a przy każdym problemie zapisz adres, szerokość okna i oczekiwany rezultat.

Odbierz przypisanie menu, widgety oraz ustawienia związane z motywem. Nie zakładaj, że cała konfiguracja automatycznie przełoży się na nową aktywną pozycję. Sprawdź nagłówek i stopkę, bo ich wspólne elementy wpływają na wiele podstron. Gdy problem dotyczy samego nagłówka, przejdź do diagnostyki headera w WordPressie.

Na telefonie sprawdź rozwijanie menu, szerokość treści, obrazy oraz przyciski. Przejdź interfejs klawiaturą i sprawdź widoczność fokusu. Skontroluj krótkie oraz długie tytuły, a także komunikaty błędów formularza w izolowanym teście. Udany wygląd strony głównej nie potwierdza zgodności pozostałych szablonów.

Przed wdrożeniem zapisz wersje motywów i listę plików objętych zmianą. Uzgodnij sposób powrotu do poprzedniego stanu, uwzględniając ustawienia w bazie. Jeżeli potrzebujesz wsparcia przy przygotowaniu i odbiorze takiej zmiany, zakres prac można ustalić w ramach obsługi WordPressa.

Przy aktualizacji rodzica wróć do listy plików skopiowanych do dziecka. Porównaj ich odpowiedniki z nową wersją bazową. Dziecko zachowuje własny szablon, więc poprawka dodana później przez autora rodzica nie zostanie automatycznie włączona do tej kopii.

Dla każdego nadpisania ustal, czy nadal jest potrzebne. Czasem nowa wersja rodzica udostępnia ustawienie albo punkt rozszerzenia, który pozwala usunąć własny duży plik. Mniejszy zakres różnic ułatwia kolejne przeglądy, ale usunięcie nadpisania również wymaga odbioru widoków.

Zapisuj uzasadnienie zmian i aktualizuj wersję dziecka zgodnie z przyjętym sposobem wydawania. Przy problemie porównaj ostatnią działającą konfigurację, zamiast od razu edytować rodzica. Sprawdź błędy PHP oraz wynik renderowania i oddziel problem kodu od nieodświeżonej pamięci podręcznej.

Zmiana rodzica jest migracją, nie kosmetyczną edycją pola Template. Nowy motyw może mieć inną strukturę, funkcje i ustawienia. Nie usuwaj dotychczasowego rodzica, dopóki aktywne dziecko go wymaga. Jeśli planujesz taką przebudowę, przez kontakt przekaż listę nadpisań i oczekiwanych widoków. To pozwala określić zakres prac na podstawie rzeczywistych zależności.

• Jak usunąć motyw WordPress bez utraty danych i zmian na stronie