WordPress 4.9 - Nowości, Funkcje i Ulepszenia Edytora Kodu

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

#Kontekst: gdzie stał WordPress przed 4.9

Wersja 4.8 przyniosła nowe widgety multimediów. 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 „pre-block” release’em, w którym Customizer i widgety dostały prawdziwy polish. Jeśli utrzymujesz legacy motyw bez FSE, wiele z tych funkcji nadal jest Twoim codziennym narzędziem.

#Najważniejsze nowości

#Ulepszony edytor kodu

WordPress 4.9 podpiął CodeMirror pod miejsca, w których redaktorzy wklejali CSS i HTML: Dodatkowy CSS, edycja plików motywu, widgety HTML. Efekt praktyczny:

• kolorowanie składni dla CSS i HTML,
• numeracja linii i lepsze przewijanie długich arkuszy,
• podpowiedzi i podstawowe sprawdzanie błędów,
• mniej „ślepego” debugowania białej strony po literówce w selektorze.

Dla agencji oznaczało to mniej ticketów typu „włączyłem CSS i padł layout”. Dla freelancera - szybsze poprawki bez IDE, gdy klient prosi o zmianę z telefonu.

#Customizer: szkice, harmonogram, podgląd

Customizer przestał być wyłącznie „zmień i opublikuj”. Pojawiły się:

• zapisywanie wersji roboczych zmian wyglądu,
• planowanie publikacji na konkretną datę (np. start kampanii),
• linki podglądu do udostępnienia stakeholderom bez logowania administracyjnego,
• lepsze zarządzanie widgetami w podglądzie responsywnym.

W praktyce: marketing mógł zobaczyć nowy hero w piątek, a produkcja odpalała się w poniedziałek rano bez ręcznego „nie klikaj Publish”. Dziś podobną rolę pełnią stagingi i preview deploymentów, ale na hostingach współdzielonych Customizer draft nadal bywa najtańszym sposobem na review.

#Ulepszenia widgetów

4.9 rozwinęło linię z 4.8:

• widget Gallery - szybka siatka zdjęć bez shortcode’ów,
• widget Media - audio i wideo w paskach bocznych,
• wygodniejsze dodawanie multimediów z biblioteki.

W erze bloków widgety klasyczne są legacy, ale migracje 4.9 → 6.x nadal wymagają mapowania tych widgetów na bloki Gallery / Embed / Group. Znajomość tego, co 4.9 wprowadziło, skraca inventarz przed przebudową sidebara.

#Bezpieczeństwo zapisu kodu

Rdzeń zaczął ostrzegać przed zapisaniem uszkodzonego CSS. To nie zastępuje Code Review, ale blokuje najczęstszy błąd redaktora: brakującą klamrę i „biały ekran” na froncie. Walidacja działa w Additional CSS i powiązanych polach - warto o tym pamiętać przy automatyzacjach, które wstrzykują CSS przez REST lub WP-CLI.

#Dla developerów: haczyki i CodeMirror

Możesz dostosować ustawienia edytora kodu filtrem wp_code_editor_settings:

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;
} );

Gdy ładujesz własny edytor w ekranie ustawień wtyczki, użyj wp_enqueue_code_editor() i wp_add_inline_script z wp.codeEditor.initialize. Dzięki temu klient dostaje ten sam UX co w rdzeniu, a Ty nie dociągasz osobnego CodeMirror z CDN.

Checklist przy własnym polu CSS w wtyczce:

1. Enqueue przez API WordPressa, nie ręczny bundle z 2017.
2. Sanityzuj zapis (wp_strip_all_tags nie wystarczy dla CSS - rozważ allowlistę lub bibliotekę CSS parsera).
3. Nie zapisuj CSS od subskrybentów bez manage_options.
4. Loguj nieudane zapisy, jeśli walidacja odrzuci składnię.

#Wymagania i ścieżka aktualizacji z 4.9

Oficjalne minimum w erze 4.9:

• PHP 5.2.4+ (zalecane już wtedy 7.0+),
• MySQL 5.0+ (zalecane 5.6+).

W 2026 te liczby są tylko historyczne. Aktualna gałąź WordPressa wymaga nowszego PHP; trzymanie site’u na 4.9 to ryzyko bezpieczeństwa i kompatybilności wtyczek. Plan migracji, który stosuję przy „żywych” 4.9 / 5.x:

1. Pełny backup plików + bazy i smoke test restore na stagingu.
2. Inwentaryzacja wtyczek: co ma aktualizację, co jest porzucone.
3. Podbicie PHP na stagingu do wersji wspieranej przez hosta i docelowy WP.
4. Aktualizacja rdzenia etapami (nie skok 4.9 → latest w jednym strzale na produkcji bez stagingu).
5. Przebicie motywów potomnych pod test / theme check i ręczne regresje koszyka / formularzy.
6. Dopiero potem produkcja + monitoring 24–48 h (logi PHP, uptime, formularze).

#Co 4.9 przygotowało pod Gutenberga

Edytor kodu z podświetlaniem składni był sygnałem: WordPress inwestuje w komfort edycji w przeglądarce. Gutenberg poszedł dalej - bloki zamiast pól CSS. Customizer drafts nauczyły redaktorów workflow „najpierw podgląd, potem publish”, który dziś wraca w patternach i revision history bloków.

Jeśli Twoja strona nadal stoi na kodzie z tamtej epoki (klasyczny motyw, sidebary, Additional 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ą.

#Częste pytania

#Czy warto jeszcze instalować WordPress 4.9 na nowym projekcie?

Nie. 4.9 ma wartość historyczną i migracyjną. Nowe wdrożenia startuj na aktualnej wersji LTS/hostingowo wspieranej. Trzymanie 4.9 na produkcji bez planu upgrade to dług techniczny i ryzyko CVE.

#Czy Customizer z 4.9 działa w motywach blokowych?

Motywy FSE opierają się o Site Editor i theme.json. Customizer może być ograniczony albo nieobecny. Funkcje szkiców i harmonogramu z 4.9 dotyczą primarily classic themes. Przy migracji na bloki zaplanuj przeniesienie Additional CSS do theme.json / child styles.

#Co z widgetami Gallery po przejściu na bloki?

Classic widgets da się trzymać wtyczką kompatybilności, ale długoterminowo mapuj je na bloki Gallery / Image. Zrób inventory sidebara przed update’em major - inaczej po aktualizacji zobaczysz puste obszary widgetów.

#Jak sprawdzić, czy Additional CSS z 4.9 nadal jest w bazie?

W Customizerze albo w opcji motywu w bazie (`theme_mods_*`). Przy migracji skopiuj CSS na staging, porównaj z repozytorium motywu potomnego i przenieś reguły do plików wersjonowanych w Git.

#Czy filtr wp_code_editor_settings nadal działa?

Tak w klasycznych ekranach opartych o CodeMirror w rdzeniu. Zawsze sprawdzaj w docs aktualnej wersji i testuj po major update - API bywa rozszerzane, ale kontrakt filtra jest stabilny od lat.

#Lekcje z 4.9, które nadal stosuję przy audytach

Po pierwsze: Additional 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 „publish” nie musi być natychmiastowy - ten nawyk warto przenieść na staging i preview URL w CI. Po trzecie: walidacja CSS w panelu 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 ZIP-a z wordpress.org trzeba zmergować albo odrzucić przed major update. Edytor kodu z CodeMirror ułatwił psucie produkcji - i jednocześnie ułatwił szybkie hotfixy. Granicą jest proces: produkcja bez DISALLOW_FILE_EDIT to zaproszenie do chaosu.

#Podsumowanie praktyczne

WordPress 4.9 domknął erę Customizera i bezpieczniejszej edycji CSS tuż przed Gutenbergem. Dla historyków changelogów to „Tipton”. Dla utrzymaniowców - przypomnienie, że komfort edycji w panelu i walidacja składni zmniejszają liczbę awarii spowodowanych ręcznym CSS. Traktuj 4.9 jako punkt na osi czasu migracji, nie jako wersję docelową.

Edytor kodu z podświetlaniem składni był w 4.9 zapowiedzią kierunku, który później rozwinął Gutenberg. Jeśli Twoja strona nadal stoi na kodzie z tamtych czasów, przygotujemy plan aktualizacji jako część opieki technicznej nad WordPressem. Szczegóły współpracy i kontakt: wppoland.com/pl/kontakt/.