'Ewolucja wordpressa: Od wersji 4.9 do ery gutenberga (5.0+)'

WordPress 4.9 “Tipton” (wydany w 2017 roku) był wersją szczególną. Było to ostatnie duże wydanie przed Rewolucją 5.0, która wprowadziła edytor Gutenberg.

Patrząc z perspektywy roku 2026, wersja 4.9 była momentem, w którym WordPress “dojrzewał” jako platforma dla developerów, wprowadzając udogodnienia, które dziś uważamy za standard.

#Co wniósł WordPress 4.9?

1. Drafty w Customizerze: Po raz pierwszy mogliśmy wprowadząć zmiany w wyglądzie strony (Kolory, CSS), zapisać je jako “Szkic” i wysłać link klientowi do podglądu, bez publikowania zmian na żywo!
2. CodeMirror: Edytory kodu w panelu (np. w “Edytorze motywu” czy “Dodatkowym CSS”) dostały w końcu kolorowanie składni i numerację linii. Koniec z psuciem strony przez brakujący średnik.
3. Widgety z Galerią: Dodanie galerii zdjęć do sidebara stało się natywne.

#Co było potem?

Zaledwie rok później pojawił się WordPress 5.0 z Gutenbergiem. Społeczność podzieliła się na dwa obozy.

• Tradycjonaliści zostali przy “Edytorze Klasycznym” (wtyczka Classic Editor ma miliony instalacji do dziś).
• Nowocześni twórcy przyjęli model Full Site Editing (FSE), gdzie wszystko, łącznie z nagłówkiem i stopką, budujemy z bloków.

Dziś, w 2026, spór ten jest już historią. Bloki wygrały. Ale warto pamiętać o wersji 4.9 jako o “ostatnim bastionie” klasycznego podejścia do budowania motywów PHP.

#Co ta zmiana naprawdę zrobiła z pracą developera

Gutenberg nie był kosmetyczną zmianą edytora. Zmienił miejsce, w którym mieszka wygląd strony.

W świecie 4.9 wygląd był w PHP. Motyw miał header.php, single.php, functions.php i hierarchię szablonów, a treść w bazie leżała jako surowy HTML z ewentualnymi shortcode’ami. Żeby zmienić układ wpisu, edytowałeś plik motywu.

W świecie bloków treść w bazie to nadal HTML, ale opakowany w komentarze typu <!-- wp:paragraph -->. To jest ważniejsze niż wygląda: format zostaje czytelny bez WordPressa, więc treść da się przenieść, a jednocześnie edytor wie, gdzie kończy się jeden komponent, a zaczyna drugi. Shortcode w bazie tego nie dawał, bo był nieprzezroczystym ciągiem znaków.

Kolejne wydania dołożyły resztę układanki. WordPress 5.8 wprowadził theme.json, czyli jedno miejsce na kolory, typografię i odstępy, oraz block.json jako sposób rejestrowania bloków. WordPress 5.9 dołożył motywy blokowe, w których szablony to pliki HTML w katalogu templates/, a nagłówek i stopka mieszkają w parts/. Dopiero w tym momencie obietnica z 5.0 została domknięta, bo do tego czasu blokami składało się treść wpisu, a resztą strony nadal rządził PHP.

Dla osoby, która wyceniała motywy w 2017 roku, konsekwencja jest praktyczna. Praca przesunęła się z pisania szablonów do konfigurowania systemu projektowego: definiujesz paletę, skalę typograficzną i zestaw wzorców, a redakcja składa z tego strony bez kontaktu z kodem. To dobra wiadomość dla utrzymania i zła dla wycen opartych na liczbie podstron.

#Kiedy migracja na bloki się nie opłaca

Nie każdy klasyczny motyw trzeba przepisywać. Trzy sytuacje, w których lepiej zostawić go w spokoju:

• Strona jest zamrożona. Wizytówka, która od trzech lat nie dostała nowej podstrony, nie zyska nic na przepisaniu. Aktualizuj PHP i wtyczki, resztę zostaw.
• Treść jest generowana z kodu. Jeśli podstrony powstają z custom post type i pól, a redakcja nigdy nie dotyka układu, edytor bloków nie rozwiązuje żadnego problemu, który ktoś faktycznie ma.
• Motyw jest mocno zależny od zewnętrznego page buildera. Tu migracja jest realnym projektem przepisania treści, nie zmianą motywu, i trzeba ją wycenić jako taki projekt, a nie doklejać do zlecenia na odświeżenie wyglądu.

Migracja opłaca się wtedy, gdy ktoś regularnie prosi o “nową sekcję na stronie głównej” i za każdym razem trafia to do developera. Wtedy koszt przepisania zwraca się w miesiącach, a nie latach.

#Co się psuje przy niedbałej migracji

Lista rzeczy, które w praktyce wychodzą po fakcie, zwykle od klienta, a nie z testów:

1. Klasy CSS z klasycznych szablonów. Motyw blokowy generuje własne nazwy klas i własne zmienne, więc arkusz pisany pod stary HTML trafia w pustkę. Objaw jest mylący: strona wygląda “prawie dobrze”, bo typografia z theme.json przypadkiem przypomina poprzednią.
2. Boxy meta. Nadal działają, ale nie w każdej konfiguracji, a wtyczka, która rejestruje box bez deklaracji zgodności z edytorem bloków, potrafi po prostu go nie pokazać. Sprawdza się to wpisem, nie listą wtyczek.
3. Shortcode’y w treści. Działają dalej, bo jest blok shortcode, ale przestają być edytowalne wizualnie. Jeśli klient dostał informację, że “wszystko będzie klikalne”, to jest właśnie ta połowa, która klikalna nie będzie.
4. Widgety. Od WordPressa 5.8 obszary widgetów są edytorem bloków. Przy migracji zdarza się, że stopka zbudowana z widgetów tekstowych rozsypuje się cicho, bo HTML wewnątrz był pisany pod stare style.
5. Szerokość treści. Ustawienia contentSize i wideSize w theme.json zastępują to, co wcześniej robił kontener w PHP. Pominięcie ich daje tekst na całą szerokość ekranu na dużych monitorach i pierwsze pytanie od klienta brzmi “dlaczego strona się rozjechała”.

#Kolejność, która ogranicza ryzyko

Migrację najbezpieczniej robi się w czterech krokach, każdy na stagingu i każdy osobno wdrażany.

Zacznij od inwentaryzacji treści: ile jest podstron, ile z nich używa shortcode’ów, ile ma układ inny niż pojedyncza kolumna. To jedna kwerenda i pół godziny, a decyduje o wycenie całości.

Drugi krok to theme.json w istniejącym klasycznym motywie. Motyw klasyczny może korzystać z tego pliku bez przepisywania szablonów, więc masz paletę, skalę i odstępy pod kontrolą, zanim ruszysz cokolwiek innego. Jeśli projekt utknie na tym etapie, i tak zostaniesz z czymś wartościowym.

Trzeci krok to wzorce. Powtarzalne sekcje ze starej strony zamień na wzorce blokowe. To one zdejmują pracę z developera, a nie sam fakt, że edytor jest blokowy.

Czwarty krok to szablony. Dopiero teraz templates/index.html i reszta hierarchii. Zostawienie go na koniec oznacza, że przez cały projekt strona działa na produkcji w niezmienionej postaci.

#Jak sprawdzić, że wyszło

Weryfikacja po migracji jest tańsza niż telefon od klienta w piątek po południu.

• Porównaj widoczną treść przed i po, strona po stronie, na dziesięciu najczęściej odwiedzanych adresach z Search Console. Nie na losowych, tylko na tych, które faktycznie mają ruch.
• Otwórz każdy typ wpisu w edytorze i zapisz bez zmian. Blok, który po zapisaniu zgłasza “nieprawidłową zawartość”, jest błędem konwersji, a nie ostrzeżeniem do zignorowania.
• Sprawdź formularze i koszyk, jeśli są. To najczęstsze ofiary usuwania “niepotrzebnych” stylów i skryptów przy okazji migracji.
• Zrób zrzut widoku mobilnego dla strony głównej i dla najdłuższego wpisu. Motywy blokowe inaczej liczą odstępy i to widać najpierw na telefonie.

Wersja 4.9 jest dziś ciekawa nie jako lista funkcji, tylko jako punkt odniesienia. Pokazuje, ile pracy w WordPressie było kiedyś po stronie developera, a ile z tego przeszło do konfiguracji. Jeśli utrzymujesz stronę z tamtej epoki, to jest właśnie ta różnica, którą wyceniasz przy każdej kolejnej prośbie o “drobną zmianę”.

#Wtyczka Classic Editor to odroczenie, nie plan

Warto nazwać rzecz po imieniu: Classic Editor jest wtyczką zgodności, a wtyczka zgodności z definicji żyje tak długo, jak ktoś chce ją utrzymywać. Trzymanie na niej strony jest sensowne przez sezon, w którym kończysz inny projekt i nie chcesz dokładać zmian redakcji. Przestaje być sensowne, gdy staje się domyślną odpowiedzią na każde pytanie o edytor, bo wtedy przez kilka lat rośnie różnica między tym, jak wygląda twoja instalacja, a tym, co zakładają nowe wtyczki i motywy. Koszt nie znika, tylko przesuwa się w czasie i rośnie razem z liczbą podstron, które trzeba będzie przekonwertować. Jeśli włączasz Classic Editor, zapisz w projekcie datę, w której wrócisz do tej decyzji, i powód, dla którego ją wtedy podjąłeś.

Sporo stron wciąż stoi na klasycznych motywach z tamtej epoki i działa, dopóki nie trzeba czegoś w nich zmienić. Jeśli masz taki projekt do przeniesienia na bloki, zajmujemy się takimi migracjami.