'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żam za standard. Szczegółowy przegląd samego wydania, funkcja po funkcji, jest w tekście co nowego w WordPressie 4.9. Ten artykuł opisuje to, co przyszło później.

#Co wniósł WordPress 4.9

1. Drafty w Customizerze: Po raz pierwszy mogłem 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.

Według przewodnika po WordPressie 4.9 widget tekstowy zaczął obsługiwać shortcode’y, obrazy, galerie, wideo, audio i osadzenia, a notka wydania dodaje, że menu i widgety lepiej zachowywały swoje miejsca przy zmianie motywu. Ta sama notka wymienia dwa zabezpieczenia w edytorach kodu: ostrzeżenie przed zapisaniem kodu z błędem i ostrzeżenie, że bezpośrednia edycja plików motywów i wtyczek z panelu to niebezpieczna praktyka.

#Dlaczego widgety z WordPressa 4.9 nazywano protoblokami

Widget galerii wygląda na drobną funkcję sidebara, ale notka, która go zapowiadała, wiąże go wprost z Gutenbergiem. W tekście Introducing the Gallery widget na make.wordpress.org (25 września 2017) Weston Ruter napisał:

“Widgety multimedialne powstają z myślą o Gutenbergu, bo widgety to w gruncie rzeczy protobloki.” (Weston Ruter, make.wordpress.org, tłumaczenie własne)

Ta sama notka zapowiada, że gdy Gutenberg dojrzeje, widgety przejdą na bloki, a widgety obrazu, wideo, audio i galerii zostaną wtedy zmigrowane. Odnotowuje też ruch w drugą stronę: Gutenberg miał już widgety Kategorie i Ostatnie wpisy przeniesione do bloków dynamicznych, więc treść zarezerwowana wcześniej dla sidebarów dawała się wstawić do wpisu. WordPress 4.8 dodał wcześniej widgety obrazu, wideo i audio, a galeria z 4.9 powstała na tej samej podstawie.

Plan zrealizowano prawie cztery lata później. WordPress 5.8 “Tatum” (notka wydania, 20 lipca 2021) wprowadził bloki zarówno do ekranu widgetów, jak i do Customizera. Strony, które nie były gotowe, mogą wrócić do starych ekranów dzięki wtyczce Classic Widgets. To oficjalna wtyczka utrzymywana przez zespół WordPressa, a katalog wtyczek podaje ponad 2 miliony aktywnych instalacji. Kto utrzymuje motyw z epoki 4.9, powinien wiedzieć, że obszary widgetów zbudowane z widgetów tekstowych i multimedialnych zmieniają się jako pierwsze, gdy włącza się blokowy edytor widgetów.

#Co zmieniły WordPress 4.9.6 i 4.9.8 przed Gutenbergiem

Gałąź 4.9 była aktualna przez ponad rok, a dwa wydania serwisowe zmieniły więcej niż poprawki błędów.

WordPress 4.9.6 (notka wydania, 17 maja 2018) był wydaniem poświęconym prywatności. Dodał:

• ustawienie wskazujące stronę z polityką prywatności, wyświetlaną potem na stronach logowania i rejestracji;
• narzędzie eksportu, które tworzy plik ZIP z danymi osobowymi użytkownika, łącznie z danymi zebranymi przez wtyczki, które to obsługują;
• narzędzie usuwania tych samych danych (w polskim panelu “Eksportuj dane osobiste” i “Usuń dane osobiste”);
• potwierdzanie żądań eksportu i usunięcia danych przez e-mail;
• pole wyboru w formularzu komentarzy, w którym niezalogowany komentujący decyduje, czy jego imię, e-mail i adres strony zostaną zapisane w przeglądarce.

WordPress 4.9.8 (notka wydania, 2 sierpnia 2018) dodał do kokpitu komunikat “Try Gutenberg”, opisany jako okazja do wypróbowania edytora blokowego przed jego wydaniem w WordPressie 5.0. To, kto go widział, zależało od strony:

• gdy Gutenberg nie był zainstalowany ani włączony: administratorzy pojedynczych stron i superadministratorzy sieci multisite;
• gdy Gutenberg był zainstalowany i włączony: użytkownicy z rolą Współtwórca i wyższymi;
• gdy włączona była wtyczka Classic Editor: nikt.

To samo wydanie zawierało 18 poprawek prywatności do narzędzi z 4.9.6. Kolejność ma znaczenie przy czytaniu starych changelogów: edytor blokowy nigdy nie był częścią 4.9. Był osobną wtyczką, a 4.9.8 było pierwszym wydaniem rdzenia, które do niej odsyłało.

#Co było po WordPressie 4.9

Zaledwie rok później, 6 grudnia 2018, pojawił się WordPress 5.0 “Bebo” z Gutenbergiem. Społeczność podzieliła się na dwa obozy.

• Tradycjonaliści zostali przy “Edytorze Klasycznym” (wtyczka Classic Editor ma dziś ponad 8 milionów aktywnych instalacji według katalogu wtyczek).
• Nowocześni twórcy przyjęli model Full Site Editing (FSE), gdzie wszystko, łącznie z nagłówkiem i stopką, buduję 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 zawierał WordPress 5.0 Bebo

Notka wydania 5.0 wymienia trzy elementy. Edytor blokowy, opisany jako pierwszy krok w stronę uproszczonej edycji całej strony. Twenty Nineteen, nowy domyślny motyw, którego style odpowiadają domyślnym blokom, więc podgląd w edytorze zgadza się z opublikowaną stroną. I wspieraną drogę powrotu: wtyczkę Classic Editor, którą można było zainstalować z ekranu wtyczek, żeby przywrócić poprzedni edytor. Notka podaje 423 osoby z podziękowaniami (props) w tym wydaniu, prowadzonym przez Matta Mullenwega z jedenastoma współprowadzącymi.

#Jak długo wtyczka Classic Editor ma wsparcie

7 listopada 2018, miesiąc przed 5.0, Gary Pendergast opublikował na make.wordpress.org okno wsparcia wtyczki Classic Editor:

“Wtyczka Classic Editor będzie oficjalnie wspierana do 31 grudnia 2021 roku.” (Gary Pendergast, make.wordpress.org, tłumaczenie własne)

Wpis definiował oficjalne wsparcie jako poprawne działanie w najnowszym dużym wydaniu WordPressa i w poprzednim, a decyzję o utrzymaniu po 2021 roku uzależniał od liczby użytkowników. Odpowiedź jest na stronie samej wtyczki, która mówi dziś o pełnym wsparciu i utrzymaniu do 2024 roku albo tak długo, jak będzie to potrzebne. W październiku 2026 katalog wtyczek pokazuje wersję 1.7.0, ostatnio aktualizowaną w maju 2026, i ponad 8 milionów aktywnych instalacji. To właśnie klauzula “tak długo, jak potrzeba” w praktyce, i ta liczba powinna paść, zanim ktoś ogłosi, że edytor klasyczny umarł.

#Jak Gutenberg zmienił pracę developera WordPress

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. WordPress 5.9 otworzył Edytor witryny dla motywów blokowych, 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.

#Kamienie milowe WordPressa od 5.8 do 6.3 i fazy Gutenberga

Droga od 5.0 do strony zbudowanej w całości z bloków zajęła jeszcze cztery lata. Notki wydań wyznaczają kolejne etapy:

theme.json przyszedł w 5.8, wydanie przed Edytorem witryny, i dlatego klasyczny motyw może z niego korzystać bez przechodzenia na motyw blokowy. Notka 5.9 mówi wprost, że przy motywach blokowych Customizer nie jest już potrzebny, a to narzędzie, któremu 4.9 poświęciło całe wydanie.

Mapa drogowa WordPressa dzieli te wydania na fazy projektu Gutenberg. Faza 1 wprowadziła edytor blokowy w WordPressie 5.0. Faza 2 skupiła się na edycji strony i zakończyła w WordPressie 6.3, który jego notka wydania nazywa zwieńczeniem fazy 2. Faza 3, która trwa, dotyczy wspólnej edycji i przepływów pracy, a cele mapy drogowej na 2026 rok zakładają, że WordPress 7.0 rozwinie funkcje współpracy z tej fazy. Linia prowadząca do 4.9 jest prosta: szkice w Customizerze, linki podglądu i blokowanie projektu były pierwszą próbą pracy kilku osób nad zmianą przed publikacją, ograniczoną do Customizera. Faza 3 przenosi ten sam problem na cały edytor.

#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 psuje się przy migracji na motyw blokowy

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”.

#Jak bezpiecznie przeprowadzić migrację na bloki

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ć stronę po migracji na bloki

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ę”.

#Czy warto zostać przy wtyczce Classic Editor

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, zajmuję się takimi migracjami.