Motyw blokowy a klasyczny w WordPressie: uczciwe porównanie

Otwórz katalog swojego motywu. Jeśli zawiera katalog templates z plikiem index.html w środku, a w katalogu głównym leży theme.json — masz motyw blokowy. Jeśli zawiera index.php obok plików takich jak header.php i footer.php, a w menu kokpitu widzisz Wygląd, a następnie Dostosuj — masz motyw klasyczny.

Ta jedna różnica w strukturze przesądza o tym, kto może zmieniać co na Twojej witrynie, gdzie zapisywane są te zmiany i która połowa ekosystemu wtyczek WordPressa zachowa się normalnie.

Rozpoznanie w 30 sekund

Sygnał	Motyw klasyczny	Motyw blokowy
Główny plik szablonu	index.php	templates/index.html
Nagłówek i stopka	header.php, footer.php	parts/header.html, parts/footer.html
Konfiguracja globalna	functions.php	theme.json (plus opcjonalnie functions.php)
Menu w kokpicie	Wygląd > Dostosuj	Wygląd > Edytor
Gdzie zapisywane są zmiany	Pliki na dysku	Baza danych, jako wpisy wp_template
Ekran widżetów	Jest	Brak

WordPress rozstrzyga to, szukając pliku templates/index.html. Motyw, który dostarcza theme.json, ale zachowuje szablony PHP, wciąż traktowany jest jako klasyczny — ten stan pośredni jest częsty i ma swoją nazwę, o czym niżej.

Jeśli masz dostęp do powłoki, jedno polecenie kończy dyskusję:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI to najszybszy sposób sprawdzenia witryny, której sam nie budowałeś, zwłaszcza gdy kreator stron poukrywał zwykłe menu w kokpicie.

Co się zmienia dla osoby edytującej witrynę

W motywie klasycznym nagłówek, stopka, panel boczny, kolory i logo siedzą za narzędziem personalizacji, a dostajesz tylko te kontrolki, które autor motywu postanowił zbudować. Jeśli motyw nie zarejestrował kontrolki dla tekstu praw autorskich w stopce, to takiej kontrolki nie ma. Albo edytujesz plik PHP, albo się z tym godzisz.

W motywie blokowym edytor witryny udostępnia całą stronę. Nagłówek, stopka, pętla wpisów, strona 404, układ wyników wyszukiwania — to wszystko są bloki i wszystko może edytować ktoś, kto nigdy nie widział PHP. To jest prawdziwa główna zaleta i naprawdę duża.

Kosztem jest to, że wszystko może edytować ktoś, kto nigdy nie widział PHP. Klient może o drugiej w nocy usunąć tytuł witryny z nagłówka i nie ma na dysku żadnej historii wersji, z której dałoby się to przywrócić — są tylko wersje w samym edytorze witryny. Da się to zabezpieczyć blokadą bloków i ograniczeniem dostępu do edytora, ale to praca, którą trzeba świadomie wykonać i o niej pamiętać.

Dwie mniejsze straty, które w praktyce dają się we znaki: motywy blokowe nie mają ekranu widżetów (obszary widżetów zastępują części szablonów i bloki), a klasyczne menu zastępuje blok nawigacji, który przechowuje pozycje jako osobny typ treści, a nie w znanym ekranie Menu.

Co się zmienia dla programisty

Motywy klasyczne korzystają z hierarchii szablonów PHP. WordPress rozstrzyga żądanie, schodząc po znanym łańcuchu — single-{post-type}.php, potem single.php, potem singular.php, potem index.php — a Twój plik się wykonuje, wywołuje get_header(), uruchamia pętlę i wypisuje znaczniki, nad którymi panujesz co do znaku.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Motywy blokowe używają tych samych nazw z hierarchii, ale z rozszerzeniem .html, a plik zawiera znaczniki blokowe — HTML z ogranicznikami bloków w komentarzach — i nie ma w nim żadnych znaczników szablonowych:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Trzy konsekwencje, na które programiści trafiają od razu:

get_header() i get_footer() nigdy się nie wykonują. Cokolwiek podpięto pod te akcje — we wtyczce albo w starym motywie potomnym — po cichu nic nie robi. wp_head i wp_footer nadal się wywołują, więc większość kolejkowania zasobów przetrwa, ale hooki związane wyłącznie z nagłówkiem już nie.

Baza danych wygrywa z Twoimi plikami. W chwili, w której ktoś zapisze szablon w edytorze witryny, WordPress zapisuje tę wersję jako wpis wp_template i serwuje ją zamiast Twojego pliku. Możesz edytować plik HTML całe popołudnie i nie zobaczyć na stronie żadnej zmiany. Wyczyszczenie personalizacji dla tego szablonu przywraca wersję z pliku. To najczęściej zgłaszany objaw „mój motyw blokowy jest zepsuty” i wcale nie jest to błąd.

Stylowanie przenosi się do theme.json. Kolory, skala odstępów, typografia i domyślne style poszczególnych bloków są deklarowane jako dane, a nie jako CSS, a WordPress generuje CSS za Ciebie. Jest to czystsze i znacznie bardziej spójne — dopóki nie potrzebujesz czegoś, czego schemat nie wyraża, bo wtedy i tak piszesz CSS i walczysz o specyficzność z wygenerowanymi regułami.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Sprawdź wartość version względem wydania WordPressa, na którym pracujesz — schemat zmieniał się już nieraz, a przeklejenie numeru wersji ze starego poradnika daje ustawienia po cichu pomijane.

Zwróć uwagę, że functions.php nie znika. Motywy blokowe nadal używają go do kolejkowania zasobów, rejestrowania wpisów add_image_size, własnych typów treści i wszystkiego innego, co robi się w PHP. Po prostu robisz tam znacznie mniej pracy nad szablonami.

Co realnie zyskujesz, a co realnie tracisz

Przechodząc na bloki, zyskujesz: kontrolę nad całą stroną z poziomu edytora, spójność projektową wymuszaną przez theme.json, mniej plików do utrzymania oraz style, które zgadzają się między edytorem a stroną publiczną znacznie częściej, niż udawało się to motywom klasycznym.

Przechodząc na bloki, tracisz: bezpośrednią kontrolę nad wyjściowymi znacznikami, proste dostosowywanie przez hooki, zgodność ze wszystkim, co zakłada istnienie szablonów PHP, oraz pewność, że wygląd witryny mieszka w systemie kontroli wersji.

To ostatnie zasługuje na podkreślenie. W motywie klasycznym git log mówi Ci, co się zmieniło. W motywie blokowym istotna część wyglądu witryny mieszka w bazie danych, do której Twój proces wdrożeniowy w ogóle nie zagląda.

Kiedy motyw klasyczny wciąż jest właściwą odpowiedzią

• Witryną steruje kreator stron. Elementor, Divi, Beaver Builder i podobne narzędzia same przejmują szablony. Podłożenie pod nie motywu blokowego dokłada drugi system szablonów, który nic nie robi.
• Znaczniki muszą być dokładnie takie, a nie inne. Autorskie biblioteki komponentów, rygorystyczne wymogi dostępności, nietypowe wymagania co do danych strukturalnych — wyjście blokowe jest ograniczone tym, co bloki potrafią wygenerować, a walka z tym kosztuje więcej niż napisanie PHP.
• Intensywne szablonowanie po stronie wtyczek. Wtyczki członkowskie, LMS-y, katalogi i starsze rozszerzenia sklepowe często dostarczają własne nadpisania szablonów PHP. Wiele ma już blokowe odpowiedniki; wiele nie ma.
• Witryna jest skończona i działa. Motyw z pięcioma latami nawarstwionych dostosowań nie ma ścieżki aktualizacji do bloków, tylko ścieżkę budowy od nowa. „To nowsze podejście” nie jest argumentem biznesowym.
• Nikt poza Tobą nie będzie tego edytował. Główna korzyść z edytora witryny to oddanie kontroli osobom nietechnicznym. Jeśli takich osób nie ma, ponosisz koszty za korzyść, z której nikt nie korzysta.

Hybrydowa droga pośrednia

Motyw klasyczny może dodać theme.json i zyskać system stylów globalnych, presety kolorów i odstępów oraz spójne style w edytorze — zachowując przy tym swoje szablony PHP i narzędzie personalizacji. WordPress nie nazwie tego motywem blokowym, a edytor witryny pozostanie niedostępny, ale dostajesz większość korzyści z systemu projektowego za ułamek pracy.

Dla istniejącej witryny, która w zasadzie działa, jest to zwykle właściwy pierwszy ruch. Dodaj theme.json, zdefiniuj paletę i odstępy, usuń CSS, który one zastępują, i zobacz, czy nadal chcesz reszty.