Szablony blokowe / Full Site Editing rok później — czy Klasyczne szablony to dług techniczny
WordPress 6.3+ dojrzał FSE. Czy Klasyczne szablony (ThemeForest, Astra, GeneratePress) to już dług techniczny? Z perspektywy agencji — co wybrać dla nowego projektu.

WordPress 5.9 (styczeń 2022) wprowadził Full Site Editing. Przez pierwsze dwa lata — technologia w beta, motyw Twenty Twenty-Two eksperymentalny, agencje instynktownie trzymały się klasyczne szablony z ThemeForest albo lekkich jak GeneratePress / Astra. W 2024 wszystko się zmieniło: Twenty Twenty-Four, Ollie, Ultimate Blocks, Kadence Blocks dojrzały. Rok 2026 to pierwszy moment, gdy z czystym sumieniem można powiedzieć: dla nowego projektu FSE wygrywa.
Poniżej — po roku implementacji u klientów, co się realnie zmieniło, co wciąż nie działa, i kiedy wciąż sensowne jest zostanie na classic.
Czym różni się Szablon blokowy od Classic
Klasyczny szablon (Astra, GeneratePress, OceanWP, motywy ThemeForest): struktura PHP + template files (header.php, footer.php, page.php), opcje przez Customizer, UI przez CSS i własne settingi. Content edytowany w Gutenbergu, ale layout całej strony (nagłówek, stopka, paski bocznej, szablony pojedynczego posta) pisane w PHP.
Szablon blokowy (Twenty Twenty-Four, Ollie): brak PHP templatów, wszystko w theme.json + HTML templates w templates/*.html. Cała strona — nagłówek, stopka, szablony postów, strona główna — edytowalna w Site Editor. Użytkownik może kliknąć i zmienić dowolny element bez znajomości kodu.
Co działa w FSE po roku dojrzewania
1. Site Editor jest stabilny
Do WP 6.3 regularne crash’e, utrata wprowadzonych zmian, bug z zapisywaniem. Od 6.4 stabilnie działa jak Gutenberg w poście. Klient może samodzielnie edytować nagłówek, stopkę, szablony bez programisty.
2. theme.json = jedno źródło prawdy
Kolory, typografia, spacing — wszystko w jednym pliku JSON. Classic motywy trzymały to w 3-5 miejscach (CSS variables w style.css, Customizer settings, theme options). theme.json zamienia to w deklaratywny config, łatwy do version control’u, spójny.
3. Patterns (wzorce) zamiast shortcodów
Zamiast [contact-form id=123] w treści, masz reusable Block Pattern z HTML + możliwością edycji in-place. Import z wbudowanej biblioteki WordPress.org (tysiące patternów), albo własne w /patterns/ folderze motywu.
4. Style Variations
Jeden motyw, wiele wariantów wizualnych — user wybiera w Site Editor między „Ocean Blue”, „Sunset Orange”, „Mono Dark” bez instalowania nowego motywu. Dla klientów, którzy chcą rebrand co rok — gigantyczny plus.
5. Performance
Szablony blokowe są domyślnie szybsze. theme.json generuje critical CSS per strona, bez nadmiaru. Twenty Twenty-Four waży ~15 KB JS + 20 KB CSS. ThemeForest „Avada” / „Enfold” — 200-400 KB samego JS + 300 KB CSS.
Benchmark (nasze pomiary, mobile throttled):
| Motyw | Home LCP | JS bundle | CSS total |
|---|---|---|---|
| Avada (Classic) | 3.8 s | 450 KB | 320 KB |
| Astra (Classic) | 2.4 s | 180 KB | 140 KB |
| GeneratePress (Classic) | 1.9 s | 95 KB | 80 KB |
| Twenty Twenty-Four (Block) | 1.3 s | 18 KB | 28 KB |
| Ollie (Block) | 1.4 s | 22 KB | 35 KB |
Różnica LCP między Avadą a Twenty Twenty-Four: 2.5 sekundy. Dla mobile traffic to różnica między zielonym a czerwonym Core Web Vitals.
Co wciąż nie działa / irytuje
1. Ekosystem wtyczek — mieszany
Popularne wtyczki (WooCommerce, Contact Form 7, Yoast) wspierają FSE. Mniejsze wtyczki — lottery. Wiele page builderów (Elementor, Beaver Builder, WPBakery) nie działa w szablonach blokowych z pełną funkcjonalnością.
Praktyka: przed wyborem Szablon blokowy dla klienta sprawdzamy, które z kluczowych wtyczek działają.
2. Migracja z Classic → Block = duża praca
Nie da się „zainstalować Szablon blokowy i gotowe”. Potrzeba:
- Migracja custom post types (ACF, CPT UI) — zwykle OK
- Przepisanie shortcodów na blocks (tu jest ból)
- Migracja menu + widgets na Site Editor
- Audit CSS (klasyczny szablon nadpisuje wiele styli inline, Szablon blokowy oczekuje
theme.json)
Dla sklepu 500 postów + 10 shortcodów: 30-50 godzin migracji. Dla small stronki 10 stron + blog: 8-12 godzin.
3. Developer experience dla agencji
Developerzy przyzwyczajeni do PHP templates muszą się uczyć HTML templating z Gutenberg syntax. <!-- wp:group {"layout":"constrained"} --> zamiast <div class="container">. Kilka tygodni na okres wdrożenia.
Dobra wiadomość: narzędzie Create Block Theme (wtyczka) pozwala generować struktury klikaniem, nie ręcznie pisać JSON.
4. Internationalization (i18n) z block patterns
Jeśli motyw ma lokalizowane patterns (różny HTML per język), infrastruktura jest niedojrzała. W dużych projektach multi-language musisz obchodzić custom hookiem.
5. Headless i szablony blokowe
Nie działa. FSE opiera się na server-side rendering. W headless (Next.js fetching REST API) dostajesz raw block content JSON, musisz renderować we własnym parserze. To było i pozostaje kluczowy blokier dla headless setups.
Kiedy Klasyczne szablony wciąż mają sens
- Klient ma silnie dostosowany motyw ThemeForest z hundreds hours customizacji. Migracja droższa niż utrzymanie.
- Integracje z starymi wtyczkami (LMS-y z 2019, custom CRM pluginy) które nie wspierają FSE.
- Zespoły redakcyjne przyzwyczajone do Elementora / Divi — brutalne wyrwanie z nawyku.
- Edge case performance — GeneratePress / Astra po ekstremalnej optymalizacji umieją schować się za Szablon blokowy na ~100 ms LCP.
Jeśli planujesz nowy projekt i nie masz pewności, czy w ogóle WordPress, czy alternatywa — zobacz nasze porównanie WordPress vs Joomla vs Drupal dla kontekstu decyzji CMS-owej.
Rekomendacja dla nowych projektów (agency lens)
Default: Szablon blokowy. Twenty Twenty-Four dla minimalizmu, Ollie / Ollie Pro dla startupów, Kadence Blocks gdy potrzeba zaawansowanych layout optionów bez page buildera.
Szablon blokowy plus ACF dla custom content heavy stron — potęga Gutenberga + elastyczność ACF dla structured data.
WooCommerce ze szablonem blokowym — tak, działa. WooCommerce ma od 8.3 (grudzień 2023) pełne blocks dla produktów, kartów, koszyka, checkoutu. Trochę mniej wtyczek WooCommerce collaboruje (stare skórki, sklepowe extras), ale kern jest solidny.
Klasyczne szablony dla nowych projektów — niemal nigdy, z wyjątkiem:
- Klient ma pakiet pluginów vendor-locked do classic
- Bardzo ograniczony budżet (szablony blokowe wymagają nieco więcej pracy deweloperskiej przy custom)
Migracja istniejących projektów — kiedy
Jeśli masz projekt na klasycznym szablonie, który działa i klient jest zadowolony, nie migraj dla samej migracji. Ale rozważ gdy:
- Performance score mobile < 50 i nie da się wycisnąć więcej z classic
- Motyw nie jest aktualizowany > 2 lata (dług bezpieczeństwa)
- Klient chce rebrand / redesign i tak
- Kilka nowych wymagań biznesowych wymaga edycji przez klienta bez programistę
Nie migraj gdy: sklep ma > 1000 produktów + customizacji (koszt niewspółmierny) albo gdy zespół redakcyjny właśnie nauczył się obsługi obecnego systemu.
W Devance nowe projekty od 2024 zaczynamy z Szablon blokowy (najczęściej Twenty Twenty-Four + ACF). Jeśli planujesz nowy projekt WordPress i rozważasz między classic a block — chętnie pomożemy wybrać. Dla istniejących projektów — audyt zawiera rekomendację czy warto migrować i przy jakim koszcie.

Doświadczony WordPress Developer z ponad 14-letnim stażem w tworzeniu zaawansowanych stron i sklepów internetowych. Specjalizuje się w WordPressie, dedykowanych wtyczkach i motywach.
Więcej o autorze
