WordPress 4.9: nowości w Customizerze, edytorze kodu i widgetach

WordPress 4.9 „Tipton” (listopad 2017) wprowadził ulepszenia, które do dziś widać w panelu: podświetlanie składni w edytorze kodu, planowanie zmian w Customizerze oraz bezpieczniejsze zapisywanie CSS i PHP. Ten tekst to praktyczny przegląd z perspektywy 2026: co 4.9 dało wtedy, co zostało w rdzeniu i jak to czytać, gdy aktualizujesz starą instalację do nowoczesnego WordPressa. Opieram się na oficjalnym ogłoszeniu wydania, przewodniku po wersji 4.9 na make.wordpress.org i stronie wersji w dokumentacji WordPressa, z linkami, żebyś mógł sprawdzić każdy punkt.

#Kiedy wyszedł WordPress 4.9 i kto go prowadził

WordPress 4.9 „Tipton”, nazwany na cześć muzyka i lidera zespołu jazzowego Billy’ego Tiptona, został ogłoszony 16 listopada 2017 roku w oficjalnym ogłoszeniu wydania. Strona wersji w dokumentacji WordPressa podaje 15 listopada, czyli ten sam moment widziany ze strefy czasowej USA. To ostatnie duże wydanie, w którym domyślnym edytorem był edytor klasyczny.

Według ogłoszenia wydanie prowadzili Mel Choyce i Weston Ruter. W podziękowaniach wymieniono 443 osoby, z czego 185 po raz pierwszy, a w dniu premiery 4.9 było w pełni przetłumaczone na 43 języki. Strona dokumentacji dodaje dwie liczby przydatne przy oględzinach starej instalacji: wersja bazy danych została na poziomie 38590, a wydanie odpowiada rewizji 42195 w Tracu.

Przewodnik po wersji 4.9, opublikowany przed premierą, liczy w cyklu około 400 zamkniętych błędów, 181 usprawnień, 7 próśb o funkcje i 42 zadania.

#WordPress 4.8 a 4.9, co się zmieniło

Wersja 4.8 przyniosła widgety obrazka, audio i wideo. 4.9 domknęła cykl przed rewolucją bloków: Gutenberg wylądował w 5.0. Dla developerów motywów klasycznych 4.9 był ostatnim dużym wydaniem sprzed bloków, w którym Customizer i widgety dostały prawdziwe dopracowanie. Jeśli utrzymujesz starszy motyw bez FSE, wiele z tych funkcji nadal jest Twoim codziennym narzędziem.

#Co nowego w Customizerze WordPress 4.9

#Szkice i harmonogram zmian w Customizerze

Customizer przestał być wyłącznie „zmień i opublikuj”. Pierwszy raz można było zapisać zmiany wyglądu (kolory, CSS, widgety, menu) jako szkic i wrócić do nich później.

Fundament był starszy niż przycisk. Changesety, czyli zapis oczekujących zmian Customizera jako wpisu typu customize_changeset z identyfikatorem UUID, weszły w WordPress 4.7. Jak tłumaczy Weston Ruter w notatce dla developerów o changesetach w 4.9, 4.7 nie miał dla nich interfejsu. Changeset siedział we wpisie auto-draft, który po tygodniu był sprzątany, jeśli go nie dotknąłeś.

WordPress 4.9 dodał interfejs. Po pierwszej zmianie obok przycisku publikacji pojawia się ikona koła zębatego z ustawieniami publikacji: opublikuj, zapisz szkic albo zaplanuj. Link Porzuć zmiany przywraca Customizer do ostatniego opublikowanego stanu.

W praktyce: marketing mógł zobaczyć nowy nagłówek w piątek, a zmiana wchodziła w poniedziałek rano bez ręcznego „nie klikaj Opublikuj”. Dziś podobną rolę pełnią stagingi i podglądy wdrożeń, ale na hostingach współdzielonych szkic w Customizerze nadal bywa najtańszym sposobem na review.

Harmonogram działa, bo changeset wchodzi na stronę w chwili, gdy jego wpis przechodzi w status publish. Notatka pokazuje, że mechanizm istniał jeszcze przed interfejsem, na przykładzie polecenia WP-CLI, które planuje zmianę tytułu strony:

wp post create \
    --post_type=customize_changeset \
    --post_name=$( uuidgen ) \
    --post_status=future \
    --post_date="2018-01-01 00:00:00" \
    --post_content='{"blogname":{"value":"Happy New Year!"}}'

Praktyczne ostrzeżenie z tej samej notatki nadal obowiązuje. Zaplanowane changesety publikuje WP-Cron, zwykle w ciągu minuty od ustalonej godziny. Na stronie z małym ruchem cron może się spóźnić, więc notatka zaleca systemowy cron wywołujący wp-cron.php co minutę, gdy godzina ma znaczenie.

#Linki podglądu dla klienta

Podgląd changesetu to operacja tylko do odczytu, więc każdy, kto zna UUID, zobaczy stronę z oczekującymi zmianami, zalogowany czy nie. WordPress 4.9 zamienił to w link podglądu, który wysyłasz współpracownikom i klientom. Ogłoszenie przedstawia go jako sposób na zebranie uwag przed zaplanowaniem publikacji i tak używały go agencje.

#Blokada edycji i autozapis w Customizerze

Skoro zapisany szkic ładuje się teraz każdemu, kto otworzy Customizer, dwie osoby mogły nadpisać sobie pracę. Odpowiedzią w 4.9 była blokada changesetu wzorowana na blokadzie wpisów: druga osoba widzi komunikat o blokadzie i może się wycofać albo przejąć edycję, a Customizer podtrzymuje blokadę przez WP Heartbeat.

Autozapis też się poprawił. Jeśli przypadkiem zamknąłeś przeglądarkę, przy następnym otwarciu Customizer proponował przywrócenie ostatniego auto-draftu. Strony i wpisy utworzone z Customizera w trakcie szkicu były oznaczane na liście w panelu jako szkice z Customizera.

#Changesety w trybie liniowym i rozgałęzionym

Rdzeń działa w trybie, który notatka nazywa liniowym: naraz może istnieć tylko jeden changeset zapisany jako szkic albo zaplanowany. Jeśli zaplanujesz zmianę tytułu na przyszły tydzień, nie opublikujesz dziś niezależnej zmiany opisu bez porzucenia albo opublikowania obu. Zmiana motywu też jest zablokowana, dopóki istnieje szkic lub zaplanowany changeset.

Strony z kilkoma intensywnymi użytkownikami Customizera mogą przywrócić dawne zachowanie, w którym każda sesja ma własny changeset, jednym filtrem:

add_filter( 'customize_changeset_branching', '__return_true' );

#Przeglądanie i zmiana motywów w Customizerze

Customizer dostał nową przeglądarkę motywów. Ogłoszenie mówi, że można było wyszukiwać, przeglądać i podglądać ponad 2600 motywów bez wychodzenia z Customizera, z filtrami według tematyki, funkcji i układu, a przewodnik dodaje, że po raz pierwszy dało się w tym samym miejscu instalować motywy z WordPress.org.

Zmiana motywu stała się mniej niszcząca. Dokumentacja wymienia przypisywanie menu i widgetów na zasadzie najlepszego dopasowania (Trac #39692), więc menu i widgety częściej lądowały w sensownym miejscu nowego motywu. Przebudowano też tworzenie menu w Customizerze, z nowymi instrukcjami, jak utworzyć menu i przypisać je do położenia.

#Edytor kodu CodeMirror w WordPress 4.9

WordPress 4.9 podpiął CodeMirror pod miejsca, w których redaktorzy wklejali CSS i HTML. Notatka o edycji kodu wymienia cztery: Dodatkowy CSS w Customizerze, widget Własny HTML oraz edytory plików motywów i wtyczek.

To była druga próba. Podświetlanie składni w edytorach plików pojawiło się już w WordPress 2.8 z biblioteką CodePress i zniknęło w 2.8.1 przez problemy ze zgodnością przeglądarek. Funkcję zgłoszono ponownie w tickecie #12423 w Tracu i powrót zajął osiem lat.

Co dał CodeMirror w 4.9:

• kolorowanie składni z dołączonymi trybami, między innymi css, htmlmixed, javascript, php, sql, markdown i yaml,
• automatyczne domykanie i parowanie nawiasów oraz znaczników,
• lintowanie przez CSSLint, JSHint, HTMLHint i JSONLint,
• podpowiedzi dla właściwości CSS, znaczników HTML i obiektów DOM w JavaScripcie.

Dla agencji oznaczało to mniej zgłoszeń typu „włączyłem CSS i padł layout”. Dla freelancera: szybsze poprawki bez IDE, gdy klient prosi o zmianę na już.

#Walidacja CSS i HTML przed zapisem w WordPress 4.9

Gdy linter znajdzie błąd, WordPress każe go poprawić przed zapisem. W Dodatkowym CSS i w widgecie Własny HTML zapis jest zablokowany, dopóki kod nie będzie poprawny; w edytorach plików możesz ostrzeżenie zignorować i zapisać mimo to. W wersji 4.7 Dodatkowy CSS tylko liczył klamry i nawiasy, co dawało fałszywe alarmy, gdy klamra stała w komentarzu. Tę walidację po stronie serwera usunięto na rzecz CSSLint.

Z tego wynika rzecz ważna przy automatyzacjach: lintowanie działa w przeglądarce. CSS wstrzykiwany przez REST API albo WP-CLI omija tę kontrolę, więc skrypt, który zapisuje style do bazy, potrzebuje własnej walidacji.

Dwa szczegóły pokazują, jak ostrożnie dobrano zakres. CodeMirror nie trafił do zakładki tekstowej edytora wpisów, ze względu na dostępność dla użytkowników czytników ekranu i dlatego, że Gutenberg i tak miał ten edytor zastąpić. Każdy użytkownik dostał też w profilu opcję Podświetlanie składni, którą może CodeMirror wyłączyć.

#Bezpieczne edycje PHP w edytorze motywów i wtyczek

Ogłoszenie opisuje to jako ochronę przed białym ekranem. Mechanizm z ticketu #21622 to wycofanie zmiany. Przy zapisie pliku PHP w edytorze motywu albo wtyczki WordPress trzyma kopię starej zawartości, zapisuje Twoją zmianę i wysyła żądanie loopback do ekranu edytora z Twoimi ciasteczkami. Jeśli to żądanie skończy się błędem krytycznym, stary plik wraca na miejsce. Jeśli nie, drugie żądanie loopback sprawdza stronę główną. Przy każdym błędzie krytycznym dostajesz komunikat, a Twoja zmiana zostaje w edytorze do poprawienia. Gdy żądania loopback nie mogą się zakończyć, zmiana jest cofana, a WordPress odsyła Cię do SFTP.

Zapis idzie teraz przez Ajax, a wyjście ze strony z niezapisanymi zmianami otwiera okno potwierdzenia. Przed 4.9 edytor wtyczek próbował wyłapać błędy krytyczne, wyłączając i ponownie włączając wtyczkę, co mogło zostawić wyłączoną wtyczkę kluczową dla strony. Motywy nie miały żadnej ochrony.

Zmieniło się też otoczenie edytorów. Przy pierwszej wizycie wyświetla się ostrzeżenie, że bezpośrednia edycja plików jest ryzykowna, a edytor motywów odsyła do Dodatkowego CSS. Edytować można więcej typów plików (między innymi js, json, scss, md, svg i yml), otwierać pliki głębiej niż dwa katalogi, a lista plików stała się rozwijanym drzewem.

#Filtr wp_code_editor_settings i CodeMirror we własnej wtyczce

CodeMirror w 4.9 to także API. Funkcja wp_enqueue_code_editor() przyjmuje type pliku, nazwę file albo tablicę ustawień codemirror, dobiera domyślne ustawienia dla języka i zwraca je, albo zwraca false, gdy użytkownik wyłączył podświetlanie składni. Przykład z notatki zamienia pole biografii w profilu w edytor HTML:

add_action( 'admin_enqueue_scripts', function() {
	if ( 'profile' !== get_current_screen()->id ) {
		return;
	}

	// Ładuje edytor kodu i ustawienia dla HTML.
	$settings = wp_enqueue_code_editor( array( 'type' => 'text/html' ) );

	// Przerwij, jeśli użytkownik wyłączył CodeMirror.
	if ( false === $settings ) {
		return;
	}

	wp_add_inline_script(
		'code-editor',
		sprintf(
			'jQuery( function() { wp.codeEditor.initialize( "description", %s ); } );',
			wp_json_encode( $settings )
		)
	);
} );

Zanim ustawienia wrócą, przechodzą przez filtr wp_code_editor_settings, którym zmienisz je globalnie:

add_filter( 'wp_code_editor_settings', function( $settings ) {
	if ( empty( $settings['codemirror'] ) || ! is_array( $settings['codemirror'] ) ) {
		return $settings;
	}

	$settings['codemirror']['lineNumbers'] = true;
	$settings['codemirror']['lineWrapping'] = true;

	return $settings;
} );

Rdzeń rejestruje bibliotekę pod uchwytem wp-codemirror i udostępnia ją jako wp.CodeMirror, a nie globalny obiekt CodeMirror, żeby nie gryzła się z wtyczkami, które przynoszą własną kopię. Dzięki temu klient dostaje ten sam UX co w rdzeniu, a Ty nie dociągasz osobnego CodeMirror z CDN. W Customizerze ten sam edytor jest dostępny jako kontrolka WP_Customize_Code_Editor_Control.

Checklist przy własnym polu CSS we wtyczce:

1. Ładuj edytor przez API WordPressa, nie ręczny bundle z 2017.
2. Sanityzuj zapis po stronie serwera (wp_strip_all_tags nie wystarczy dla CSS, rozważ allowlistę lub parser CSS), bo lint w przeglądarce nie chroni przed zapisem przez API.
3. Nie zapisuj CSS od użytkowników bez manage_options.
4. Loguj nieudane zapisy, jeśli walidacja odrzuci składnię.

#Widgety w WordPress 4.9

#Widget Galeria i media w widgecie tekstowym

4.9 rozwinęło linię z 4.8. Widget Galeria (Trac #41914) dał siatkę zdjęć w pasku bocznym bez shortcode’ów.

Zmienił się też widget tekstowy. Dostał przycisk dodawania mediów (obrazki, wideo, audio) i zaczął wykonywać shortcode’y. To zgłoszenie (Trac #10457) czekało ponad osiem lat, a motywy i wtyczki przestały potrzebować add_filter( 'widget_text', 'do_shortcode' ). Widget tekstowy przyjmuje też oEmbedy, więc wklejony adres z YouTube staje się osadzonym odtwarzaczem, a widget wideo nauczył się obsługiwać dostawców innych niż YouTube i Vimeo.

Na ekranie widgetów w panelu nowy stan zmian pokazuje, czy widget został zapisany, i pyta o potwierdzenie przy próbie wyjścia bez zapisu.

W erze bloków widgety klasyczne są przestarzałe, ale migracje 4.9 do 6.x nadal wymagają mapowania tych widgetów na bloki Galeria, Osadzanie i Grupa. Znajomość tego, co 4.9 wprowadziło, skraca inwentaryzację przed przebudową paska bocznego.

#Bezpieczeństwo, role i zmiany dla developerów w WordPress 4.9

#Nowe uprawnienia i bezpieczeństwo konta

Strona dokumentacji i przewodnik wymieniają kilka zmian ważnych dla każdego, kto zarządza użytkownikami:

• osobne uprawnienia activate_plugin i deactivate_plugin, sprawdzane dla konkretnej wtyczki, więc rola może przełączać jedne wtyczki, a inne nie,
• osobne uprawnienia do instalowania i aktualizowania plików językowych,
• link potwierdzający wysyłany e-mailem, gdy użytkownik próbuje zmienić adres e-mail (Trac #16470),
• pewniejsza inicjalizacja ról i uprawnień przy przełączaniu stron w multisite oraz nowa funkcja get_site_by().

#API JS Customizera, MediaElement i usunięte elementy

Dla developerów API JavaScript Customizera pozbyło się wielu niedogodności wymienionych w przewodniku: domyślnych parametrów dla konstrukcji, bazowych szablonów kontrolek, kontrolki daty i godziny oraz powiadomień na poziomie globalnym, panelu i sekcji. MediaElement.js zaktualizowano do 4.2.6, co według ogłoszenia usuwa zależność od jQuery, poprawia dostępność i naprawia wiele błędów.

Część rzeczy opuściła rdzeń. Usunięto SWFUpload, a Press This przeniesiono do osobnej wtyczki. REST API zaczęło wymagać nazwanych parametrów w wyrażeniach regularnych tras, więc dopasowania numeryczne przestały działać. Dokumentacja odnotowuje też, że rdzeń i testy jednostkowe były w pełni zgodne z nadchodzącym wtedy PHP 7.2.

#WordPress 4.9 a Gutenberg w wersji 5.0

Ogłoszenie 4.9 samo zostało napisane w Gutenbergu i zachęcało do testowania go jako wtyczki. Edytor kodu z podświetlaniem składni był sygnałem, że WordPress inwestuje w komfort edycji w przeglądarce. Gutenberg poszedł dalej: bloki zamiast pól CSS. Szkice w Customizerze nauczyły redaktorów zasady „najpierw podgląd, potem publikacja”, która wraca w podglądzie i rewizjach edytora bloków.

Rok po 4.9 WordPress 5.0 zrobił z Gutenberga domyślny edytor, a dla stron, które chciały zostać przy starym ekranie, przygotowano wtyczkę Classic Editor. Wtyczka nadal ma miliony aktywnych instalacji. W latach 2019 do 2021 doszły wzorce bloków i prace nad Full Site Editing, a od 2022 motywy blokowe i edytor witryny są w rdzeniu, przy wciąż wspieranych motywach klasycznych i Customizerze.

Jeśli Twoja strona nadal stoi na kodzie z tamtej epoki (klasyczny motyw, paski boczne, Dodatkowy CSS na setki linii), 4.9 nie jest celem. Jest punktem odniesienia w changelogu. Celem jest bezpieczna, wspierana gałąź rdzenia i motyw, który da się utrzymać bez strachu przed każdą aktualizacją.

#Jak zaktualizować WordPress 4.9 do nowej wersji

Aktualna gałąź WordPressa wymaga znacznie nowszego PHP niż w 2017 roku; trzymanie strony na 4.9 to ryzyko bezpieczeństwa i zgodności wtyczek. Plan migracji, który stosuję przy żywych instalacjach 4.9 i 5.x:

1. Pełny backup plików i bazy oraz próbne odtworzenie na stagingu.
2. Inwentaryzacja wtyczek: co ma aktualizację, co jest porzucone.
3. Podbicie PHP na stagingu do wersji wspieranej przez hosta i docelowy WordPress.
4. Aktualizacja rdzenia etapami (nie skok z 4.9 na najnowszą wersję w jednym strzale na produkcji bez stagingu).
5. Sprawdzenie motywów potomnych narzędziem Theme Check i ręczne testy regresji koszyka oraz formularzy.
6. Dopiero potem produkcja i monitoring przez 24 do 48 godzin (logi PHP, uptime, formularze).

Jeśli zaplanowane zmiany w Customizerze mają przetrwać migrację, sprawdź przed nią wpisy customize_changeset w statusie future i draft: w trybie liniowym blokują zmianę motywu, a po przeniesieniu bazy opublikuje je dopiero działający cron.

#Jak zrobić audyt starej instalacji WordPress 4.9

Po pierwsze: Dodatkowy CSS w Customizerze to dług techniczny, jeśli rośnie ponad kilkadziesiąt linii. Przenieś reguły do motywu potomnego albo do pliku ładowanego warunkowo. Po drugie: szkice i harmonogram w Customizerze nauczyły zespoły marketingu, że publikacja nie musi być natychmiastowa, i ten nawyk warto przenieść na staging i podglądy w CI. Po trzecie: walidacja CSS w panelu działa tylko w przeglądarce i nie zwalnia z Code Review przy wtyczkach, które zapisują style do bazy.

Przy przejmowaniu starej instalacji zawsze pytam: czy ktoś edytował pliki motywu z panelu po 4.9? Jeśli tak, różnice względem paczki z wordpress.org trzeba scalić albo odrzucić przed dużą aktualizacją. Edytor kodu z CodeMirror ułatwił psucie produkcji i jednocześnie ułatwił szybkie poprawki, a loopback z 4.9 łapie tylko błędy krytyczne, nie błędy logiki. Granicą jest proces: produkcja bez DISALLOW_FILE_EDIT w wp-config.php to zaproszenie do chaosu.

#Podsumowanie praktyczne

WordPress 4.9 domknął erę Customizera i bezpieczniejszej edycji kodu tuż przed Gutenbergiem. Dla historyków changelogów to „Tipton”. Dla utrzymaniowców przypomnienie, że komfort edycji w panelu, lintowanie i wycofywanie błędnych edycji PHP zmniejszają liczbę awarii spowodowanych ręcznymi poprawkami. Traktuj 4.9 jako punkt na osi czasu migracji, nie jako wersję docelową.

Jeśli Twoja strona nadal stoi na kodzie z tamtych czasów, przygotuję plan aktualizacji jako część opieki technicznej nad WordPressem. Szczegóły współpracy i kontakt: wppoland.com/pl/kontakt/.