Motywy klasyczne vs block themes (fse): Co wybrać w 2026 roku

Przez ponad dekadę (2010-2020) tworzenie motywów WordPress wyglądało tak samo: tworzyłeś header.php, footer.php, pętlę w index.php i style w style.css. Logika była w PHP, wygląd w CSS, a te dwa światy rzadko się spotykały.

Wraz z WordPress 5.9 pojawiło się Full Site Editing (FSE), dziś nazywane po prostu edytorem witryny (Site Editor), a w 2026 roku pytanie jest ostrzejsze niż kiedykolwiek: czy wciąż pisać motywy w PHP, czy przejść w pełni na bloki, szablony HTML i theme.json?

Ten tekst rozkłada na części, czym naprawdę są motywy blokowe, czym różnią się od klasycznych na poziomie kodu, kiedy wygrywa każdy z nich i jak zaplanować migrację. Obejmuje model klasyczny, blokowy i hybrydowy.

Krótka odpowiedź: wybierz motyw blokowy, gdy chcesz zarządzać witryną z poziomu edytora, trzymać design tokens w jednym pliku i iść w kierunku, w którym rozwija się rdzeń WordPressa. Zostań przy motywie klasycznym, gdy projekt wciąż zależy od własnych szablonów PHP, ścisłej kontroli układu albo pracy opartej na page builderze. Model hybrydowy leży pomiędzy i właśnie tam ląduje duża część profesjonalnych projektów.

#Czym jest motyw blokowy w WordPressie

Motyw blokowy to motyw WordPress zbudowany w całości z bloków: jego szablony to pliki HTML ze znacznikami bloków zamiast plików PHP, design tokens mieszkają w jednym pliku theme.json, a każdą część witryny (nagłówek, stopkę, archiwa, 404) edytuje się wizualnie w edytorze witryny. Full Site Editing (FSE) to nazwa zbiorcza tego systemu. Zanim przejdziemy do porównania, warto zdefiniować jego elementy, bo kilka osobnych podsystemów weszło do WordPressa jednocześnie. Co już ląduje we wtyczce Gutenberg, w tym React 19, opisujemy w Gutenberg 24.2: notatki i React 19.

Edytor witryny (Wygląd > Edytor) to wizualny interfejs do edycji każdej części strony: szablonów, części szablonów, stylów, wzorców i nawigacji. W motywie klasycznym w edytorze blokowym edytowałeś tylko treść wpisów i stron. W motywie blokowym to samo płótno bloków edytuje nagłówek, stopkę, szablon pojedynczego wpisu, archiwum, 404 i wyniki wyszukiwania.

theme.json to jeden plik konfiguracyjny w katalogu głównym motywu, który deklaruje design tokens i ustawienia edytora. Definiuje paletę kolorów, skalę typografii, skalę odstępów, szerokości układu i to, które kontrolki pojawiają się w edytorze. WordPress go odczytuje i generuje zmienne CSS (custom properties) dla frontendu i edytora, więc widok edycji zgadza się z opublikowaną stroną.

Szablony blokowe i części szablonów to pliki HTML w katalogach templates/ i parts/. Zamiast single.php dostarczasz templates/single.html, a zamiast stopki zakodowanej na sztywno w footer.php dostarczasz parts/footer.html. Te pliki zawierają znaczniki bloków (komentarze HTML w rodzaju <!-- wp:post-title /-->), nie PHP.

Style globalne to warstwa dla użytkownika nad theme.json. Właściciel strony może zmieniać kolory, fonty i odstępy z panelu Style bez dotykania kodu, a motywy mogą dostarczać alternatywne wariacje stylów jako dodatkowe pliki JSON w katalogu styles/.

Wzorce bloków to gotowe, wielokrotnego użytku układy bloków. Przejęły dużą część tego, co oferowały page buildery: sekcję hero, sekcję cennika, wezwanie do działania, wszystko edytowalne jako natywne bloki i rejestrowane z katalogu patterns/.

Zrozumienie tych pięciu elementów to większość pracy. Motyw blokowy to w gruncie rzeczy theme.json plus szablony HTML plus wzorce, edytowane w edytorze witryny.

#Wymagane pliki motywu klasycznego: style.css i index.php

Motyw klasyczny potrzebuje dokładnie dwóch plików, zanim WordPress go wyświetli i pozwoli aktywować: style.css, którego komentarz nagłówkowy niesie nazwę motywu i resztę metadanych, oraz index.php jako szablonu ostatniej szansy. Wszystko inne, co zwykle widać, czyli header.php, footer.php, functions.php, single.php, page.php, jest w ścisłym sensie opcjonalne i staje się potrzebne dopiero wtedy, gdy hierarchia szablonów ma się rozgałęziać. Motyw blokowy podmienia drugi plik: style.css nadal niesie komentarz nagłówkowy, ale szablonem awaryjnym jest templates/index.html zamiast index.php. theme.json też nie jest formalnie wymagany, choć motyw blokowy bez niego dziedziczy domyślne wartości rdzenia dla kolorów, odstępów i typografii, a to prawie nigdy nie jest to, czego chcesz. Motyw potomny dokłada jedną regułę: linia Template: w nagłówku jego style.css musi wskazywać katalog motywu nadrzędnego.

#1. Pliki szablonów w motywie klasycznym i blokowym

To najbardziej podstawowa różnica i ta, która niepokoi wielu programistów z długim stażem.

#Motyw klasyczny (classic theme)

Opiera się na plikach PHP. Kiedy WordPress ładuje stronę, przechodzi hierarchię szablonów (na przykład single-product.php, potem single.php, potem index.php), a silnik PHP składa nagłówek, pętlę i stopkę w momencie żądania.

• Struktura: header.php, page.php, single.php, archive.php, sidebar.php, functions.php.
• Logika: możesz swobodnie mieszać PHP z HTML, na przykład warunek if ( is_user_logged_in() ) albo w pełni własną pętlę WP_Query.
• Zaleta: pełna kontrola nad znacznikami i łatwe wstrzykiwanie logiki biznesowej, wywołań zewnętrznych API czy widoków warunkowych.
• Wada: właściciel strony nie zmieni nagłówka, stopki ani układu bez edycji kodu albo prośby do programisty.

#Motyw blokowy (block theme)

Opiera się na plikach szablonów HTML ze znacznikami bloków. W samych plikach szablonów nie ma PHP.

• Struktura: templates/index.html, templates/single.html, parts/header.html, parts/footer.html, theme.json.
• Logika: żadnej w pliku szablonu. Szablony to statyczne znaczniki bloków, a cała dynamiczna treść pochodzi z bloków takich jak <!-- wp:post-title /-->, blok Pętla zapytania (Query Loop) czy blok Treść wpisu.
• Zaleta: właściciel strony może edytować całą witrynę, łącznie z nagłówkiem i stopką, na jednym wizualnym płótnie.
• Wada: własna logika po stronie serwera musi przejść do własnego bloku, wariacji bloku, Block Bindings API albo shortcode’u, zamiast siedzieć bezpośrednio w szablonie.

Zmiana myślenia polega na tym, że logika prezentacji opuszcza plik szablonu. Tam, gdzie motyw klasyczny wstawia warunek bezpośrednio do single.php, motyw blokowy wyraża ten sam zamiar przez kontekst bloku, block bindings albo dedykowany blok zarejestrowany we wtyczce lub w functions.php motywu.

#2. Co theme.json zastępuje w functions.php

W erze klasycznej functions.php był miejscem na wszystko: rejestrację menu, sidebarów, rozmiarów obrazków, ładowanie arkuszy stylów i skryptów oraz flagi add_theme_support(). Decyzje projektowe były rozrzucone między PHP a jednym lub kilkoma plikami CSS.

W erze blokowej konfigurację centralizuje theme.json. Steruje:

1. Paletą kolorów: nazwanymi kolorami dostępnymi dla redaktorów, emitowanymi jako zmienne CSS.
2. Typografią: rozmiarami i rodzinami fontów, wysokością linii i typografią płynną (fluid).
3. Odstępami: skalą odstępów i odstępem między blokami (block gap), stosowanymi spójnie we wszystkich blokach.
4. Układem: szerokością treści i szerokością poszerzoną (contentSize, wideSize), od których zależy wyrównanie.
5. Kontrolkami i dostępnością: appearanceTools, ustawieniami per blok i możliwością wyłączenia kontrolek, których redaktorzy nie powinni ruszać.

Przykład theme.json w 2026:

{
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": { "contentSize": "720px", "wideSize": "1200px" },
    "color": {
      "palette": [
        { "slug": "primary", "color": "#0055FF", "name": "Niebieski marki" }
      ]
    },
    "typography": {
      "fluid": true,
      "fontSizes": [
        { "slug": "small", "size": "14px", "name": "Mały" }
      ]
    }
  }
}

Zamiast utrzymywać setki linii CSS plus rejestrację w PHP, deklarujesz tokeny raz w JSON. Jak ułożyć te tokeny w system projektowy wspólny dla wielu projektów, opisuje przewodnik o skalowalnych systemach projektowych w Gutenbergu. WordPress generuje zoptymalizowany CSS i zmienne CSS dla frontendu i edytora, dlatego podgląd w edytorze wreszcie zgadza się z opublikowanym wynikiem. functions.php nadal istnieje w motywie blokowym, ale robi się mały: załadowanie fontu, rejestracja kategorii wzorców, flagi wsparcia edytora i niewiele więcej.

#3. Jak działają style globalne i wariacje stylów

theme.json ustala wartości domyślne, a style globalne pozwalają właścicielowi strony nadpisać je bez kodu. Z panelu Style redaktor może zmienić font treści, poprawić paletę albo odstępy, a te wybory zapisują się dla danej witryny.

Motywy mogą też dostarczać wariacje stylów: dodatkowe pliki JSON w katalogu styles/, które pokazują całą witrynę w innym wyglądzie, na przykład ciemnym albo o wysokim kontraście, do wybrania jednym kliknięciem. Motywy klasyczne nigdy nie miały tego natywnie i to jeden z najmocniejszych argumentów za motywami blokowymi w projektach, w których marka ma być elastyczna.

Ceną jest nadzór. Pełny dostęp do stylów globalnych w rękach nieprzeszkolonego redaktora może dać niespójną typografię albo zepsuty kontrast. Motywy blokowe odpowiadają na to blokowaniem bloków (block locking) i wyłączaniem konkretnych kontrolek w theme.json, ale programista musi te zabezpieczenia ustawić świadomie.

#4. Co dzieje się z widgetami i menu w motywie blokowym

W motywach blokowych nie ma domyślnie ekranu Widgetów ani klasycznego ekranu Menu w sekcji Wygląd.

• Zamiast widgetów masz części szablonu (template parts). Stopka to część szablonu HTML, którą edytujesz na tym samym płótnie bloków co każdy wpis.
• Zamiast klasycznego edytora menu masz blok Nawigacja, edytowany bezpośrednio w nagłówku, a samo menu zapisuje się jako obiekt wielokrotnego użytku typu wp_navigation.

Dla klientów przyzwyczajonych do starszego WordPressa to prawdziwy szok kulturowy. Znajome pozycje “Widgety” i “Menu” znikają, zastąpione blokami. Część wtyczek, które rejestrowały widgety, dostarcza dziś bloki, a kilka starszych udostępnia swój widget tylko przez starszy blok Widget jako most zgodności. Audyt zgodności wtyczek jest więc realnym krokiem, zanim zobowiążesz klienta do motywu blokowego.

#5. Porównanie funkcji motywu blokowego i klasycznego

Tabela podsumowuje, gdzie oba modele rozchodzą się w codziennej pracy.

Czytaj tabelę jako pomoc w decyzji, nie tablicę wyników. Żadna kolumna nie jest lepsza zawsze; właściwy wybór zależy od tego, kto edytuje stronę i ile własnej logiki serwerowej niosą szablony.

#6. Czy motywy blokowe są szybsze od klasycznych

Przez lata odpowiedź brzmiała wyraźnie “tak”, a od WordPress 6.9 różnica jest dużo mniejsza.

1. Style bloków rdzenia: motywy blokowe ładują CSS bloków rdzenia osobno i tylko dla bloków, które się renderują, bo _add_default_theme_supports() włącza should_load_separate_core_block_assets i should_load_block_assets_on_demand. Motywy klasyczne dostawały wcześniej zbiorczy arkusz wp-block-library na każdej stronie. Od 6.9 funkcja wp_load_classic_theme_block_styles_on_demand() ustawia te same dwa filtry dla motywów klasycznych i dodaje bufor wyjścia, który przenosi późno wypisane style do sekcji head. Bufor ma koszt: wyłącza streaming odpowiedzi, więc czas do pierwszego bajtu może lekko wzrosnąć. Motyw, który potrzebuje streamingu, wyłączy go filtrem wp_should_output_buffer_template_for_enhancement.
2. Design tokens zamiast arkuszy stylów: theme.json emituje zmienne CSS zamiast ciężkiej kaskady. Motyw klasyczny dostaje te same tokeny, gdy tylko dołoży plik theme.json.
3. Własny arkusz motywu: tu realna różnica zostaje. Motyw klasyczny często niesie jeden duży style.css ze wszystkimi komponentami, a motyw blokowy trzyma większość stylów w theme.json i w stylach per blok.
4. Czystsze znaczniki, z zastrzeżeniem: wynik FSE bywa uporządkowany, ale zagnieżdżone bloki układu potrafią wygenerować nadmiar opakowujących div (“divoza”), jeśli wzorce buduje się niedbale.

Motyw nie ma wyniku w Lighthouse, ma go strona. Na prawdziwej witrynie o wyniku decyduje dużo bardziej baner zgód, osadzone mapy i formularze, pliki fontów i rozmiary obrazków niż typ motywu. Mierz własne strony; jak to robić, opisuje przewodnik po Core Web Vitals.

Doświadczenie programisty jest bardziej zróżnicowane i zależy od zespołu. Tworzenie motywów blokowych opiera się na konfiguracji JSON, znacznikach bloków i JavaScripcie dla własnych bloków (block.json, register_block_type, zestaw narzędzi @wordpress/scripts). Zespoły z głębokimi korzeniami w PHP, ale z małym doświadczeniem w React i narzędziach blokowych, mają przed sobą realną krzywą nauki. Praca z motywem klasycznym jest od razu znajoma każdemu programiście PHP, ale nie daje klientowi edycji wizualnej ani systemu design tokens bez dodatkowej pracy. W praktyce najszybsza droga dla zespołu mocnego w PHP to motyw hybrydowy: najpierw theme.json i wzorce, potem stopniowo własne bloki.

#7. Migracja z motywu klasycznego na blokowy

Migracja rzadko jest jednym przełącznikiem. Treść w bazie danych (wpisy, strony, media) pozostaje nietknięta, ale warstwę prezentacji trzeba zbudować od nowa.

Praktyczne kwestie:

• Szablony: każdy szablon PHP potrzebuje odpowiednika blokowego. Złożone szablony warunkowe trzeba czasem rozbić na wzorce plus block bindings.
• Menu: istniejące menu nie konwertują się automatycznie; odtwarzasz je jako bloki Nawigacja, choć same pozycje menu zwykle odtwarza się szybko.
• Widgety: obszary widgetów nie istnieją w motywie blokowym, więc widgety z sidebaru i stopki stają się częściami szablonu albo blokami.
• Ustawienia Customizera: opcje ustawione w Customizerze (logo, kolory, własny CSS) przechodzą do theme.json i stylów globalnych. Własny CSS można na czas przejścia zachować w polu dodatkowego CSS w stylach globalnych.
• Wyjście wtyczek: sprawdź, czy każda aktywna wtyczka dostarcza bloki albo shortcode’y, a nie polega na widgetach czy hookach szablonu, których motyw blokowy nie wywołuje tak samo.

Bezpieczna ścieżka jest stopniowa: najpierw zamień motyw klasyczny w hybrydowy, dodając theme.json i obsługę wzorców bloków, sprawdź design tokens i pracę w edytorze, a potem zastępuj szablony PHP szablonami blokowymi jeden po drugim. Unikasz ryzykownego przepisania wszystkiego naraz i możesz przetestować każdy szablon na prawdziwej treści i na Core Web Vitals, zanim pójdziesz dalej.

Aktualizacja, 27 października 2026. W sklepie WooCommerce punkt o wyjściu wtyczek wymaga osobnego testu. Wiele wtyczek do WooCommerce wypisuje przyciski i plakietki z klasycznych hooków pętli sklepu. W motywie blokowym siatka produktów to blok Product Collection, a gdy ten blok nie korzysta z zapytania sklepu, jak siatka produktów na stronie głównej, te hooki się w nim nie wykonują. Wyjście wtyczki znika wtedy bez żadnego komunikatu, a jej arkusz stylów może się na tej stronie w ogóle nie załadować. Zanim przeniesiesz sklep na motyw blokowy, wstaw Product Collection na stronę główną, otwórz stronę sklepu zbudowaną z bloków i na obu sprawdź każdą wtyczkę: czy jej wyjście jest na miejscu i czy jej arkusz stylów się ładuje. Nasze wtyczki działają w obu miejscach: plakietki Marks, przycisk porównania z Versus i przycisk szybkiego zakupu z Swift wyświetlają się w siatkach Product Collection i na stronie sklepu zbudowanej z bloków.

#8. Kiedy zostać przy motywie klasycznym

Motyw klasyczny to nadal dobry wybór, gdy:

• Projekt niesie dużo własnej logiki PHP w widokach, na przykład zaawansowane warunki wyświetlania, własne pętle albo głębokie nadpisania szablonów WooCommerce.
• Klient nie czuje się pewnie z pełną edycją i trzeba zapobiec przypadkowym zmianom układu w nagłówku lub stopce.
• Strona stoi na page builderze, takim jak Elementor czy Divi, które wciąż zakładają klasyczną strukturę i w dużej mierze omijają FSE.
• Utrzymujesz dojrzałą witrynę, na której koszt migracji wyraźnie przewyższa korzyść.
• Zespół jest przede wszystkim PHP-owy i ma teraz mało przestrzeni na inwestycję w narzędzia blokowe.

#9. Kiedy wybrać motyw blokowy

Motyw blokowy to mocniejszy wybór, gdy:

• Strona opiera się na treści: witryna firmowa, blog, serwis publikacyjny albo portfolio.
• Właściciel chce edytować nagłówki, stopki i szablony bez programisty przy każdej zmianie.
• Chcesz mieć domyślnie design tokens i style per blok zamiast dużego arkusza stylów motywu.
• Liczy się elastyczność marki, a wariacje stylów dają realną wartość.
• Chcesz iść w kierunku rdzenia WordPressa, który koncentruje rozwój na doświadczeniu blokowym i FSE.

#10. Motyw blokowy czy klasyczny dla WooCommerce, bloga i LMS

• Strona małej firmy lub korporacyjna: motyw blokowy. Redaktorzy dostają bezpieczną kontrolę nad całym układem.
• Blog lub serwis publikacyjny: motyw blokowy. Blok Pętla zapytania, wzorce i czyste znaczniki dobrze pasują do pracy redakcyjnej.
• Portfolio lub strona wizytówka: motyw blokowy, często z kilkoma wariacjami stylów na sezonowe zmiany wyglądu.
• Sklep WooCommerce: to zależy. Nowoczesny koszyk i checkout oparte na blokach pasują do motywu blokowego, ale sklepy z rozbudowanymi własnymi szablonami produktu w PHP mogą zostać przy motywie klasycznym albo hybrydowym.
• Członkostwo, LMS albo złożona aplikacja: motyw klasyczny lub hybrydowy. Ciężką logikę widoków i integracje zewnętrzne łatwiej kontrolować w szablonach PHP.
• Strona oparta na page builderze: motyw klasyczny. Builder i tak zarządza układem, więc FSE niewiele dodaje.

#Czym jest motyw hybrydowy

To pragmatyczny złoty środek. Klasyczny motyw PHP, który dodaje theme.json (dla palety kolorów, typografii i tokenów odstępów w edytorze) i obsługę wzorców bloków, a zachowuje wybrane szablony PHP, takie jak header.php czy single.php, dla kontroli nad strukturą. Wiele profesjonalnych projektów w 2026 roku powstaje dokładnie tak: edycja blokowa tam, gdzie pomaga, PHP tam, gdzie ma znaczenie.

#Które funkcje edytora witryny działają w motywach klasycznych, według wersji WordPressa

Granica między dwoma typami motywów przesuwała się niemal z każdym wydaniem. Theme Handbook nazywa motywy hybrydowe “motywami klasycznymi, które przejęły część nowoczesnych funkcji związanych z blokami” i zaznacza, że hybrydowy nie jest oficjalnym typem motywu (What is a theme, tłumaczenie własne). Tabela pokazuje, co i kiedy trafiło do motywów klasycznych; daty wydań pochodzą z archiwum wydań WordPressa.

W obecnym rdzeniu wp-admin/menu.php daje motywowi klasycznemu pełną pozycję Projekt (Design) w edytorze witryny, gdy motyw ma theme.json albo deklaruje wsparcie editor-styles, a w przeciwnym razie tylko pozycję Wzorce. Motyw blokowy dostaje pozycję Edytor. Dlatego w 2026 roku praktyczne pytanie rzadko brzmi “klasyczny czy blokowy” w oderwaniu od projektu. Brzmi: które z tych funkcji projekt przejmuje, w jakiej kolejności i czy ostatni krok, dodanie templates/index.html, w ogóle się opłaca.

#Motyw blokowy czy klasyczny w WordPressie: co wybrać w 2026

Decyzja zależy od trzech czynników: złożoności projektu, umiejętności technicznych klienta i wymagań długoterminowego utrzymania.

Wybierz motyw blokowy, gdy:

• Klient musi edytować nagłówki, stopki i szablony bez pomocy programisty
• Redaktorzy mają zmieniać szablony i style globalne bez wdrożenia
• Chcesz używać theme.json do design tokens (kolory, typografia, odstępy) zamiast rozproszonego CSS
• Projekt startuje od zera, bez starego kodu do utrzymania

Wybierz motyw klasyczny, gdy:

• Potrzebujesz złożonej logiki PHP w szablonach (własne pętle, układy warunkowe, nadpisania WooCommerce)
• Projekt opiera się na widgetach, klasycznych menu albo Customizerze
• Zespół ma duże doświadczenie w PHP, a małe w tworzeniu bloków Gutenberga
• Utrzymujesz istniejącą witrynę, a koszt migracji przewyższa korzyść

Podejście hybrydowe: wiele profesjonalnych projektów WordPress w 2026 roku używa motywu klasycznego z wybiórczym wsparciem bloków. Rejestruj wzorce i szablony blokowe tam, gdzie dają wartość, a szablony PHP zostaw tam, gdzie dają więcej kontroli. WordPress nie wymusza wyboru wszystko albo nic.

WordPress 7.0 ukazał się 20 maja 2026, a 7.1 19 sierpnia 2026; bieżące wydanie to 7.1.3 z 6 października 2026. Abilities API pojawiło się wcześniej, w 6.9, i działa tak samo przy obu typach motywów, więc nie jest argumentem za żadną z architektur.

#Podsumowanie

Świat WordPressa podzielił się na dwa obozy. Nie walcz z tym. Naucz się składni theme.json, to umiejętność tak ważna w 2026 roku, jak znajomość CSS w 2015.

Wybór między motywem klasycznym a blokowym najczęściej sprowadza się do tego, kto będzie później zmieniał układ strony: redakcja czy deweloper. Pomagamy przejść na theme.json bez utraty tego, co już działa, jako część budowy motywów blokowych.