Style responsywne bez CSS w WordPress 7.1 — i cztery miejsca, w których nie zadziałają

Aktualizacja pojawiła się w panelu w środku innej roboty. Wchodzimy na kokpit studio.ifox.pl po coś zupełnie niezwiązanego, a tam czeka WordPress 7.1 — wydany 19 sierpnia na WordCamp US w Phoenix, u nas dostępny w nocy z 19 na 20.

Poszliśmy najpierw na staging, przejrzeliśmy te kilka podstron, z których składa się nasza strona, i skoro wszystko wyświetlało się prawidłowo — puściliśmy na produkcję. Ekran powitalny „Witaj w WordPressie 7.1" zobaczyliśmy o 1:01.

Zaznaczamy od razu: to nie jest procedura, którą zalecamy komukolwiek na cudzej stronie, i pod koniec tekstu wyjaśniamy dlaczego mimo to zrobiliśmy tak u siebie.

Piszemy więc ten tekst świeżo po aktualizacji własnej strony, nie przed premierą. To ma znaczenie, bo nagłówek tego wydania brzmi obiecująco: style responsywne bez pisania CSS. Ustawiasz w edytorze inny rozmiar nagłówka na telefonie, inny padding na tablecie, i gotowe. Koniec z dopisywaniem media queries do „Dodatkowego CSS", które i tak znika przy zmianie motywu.

To prawda. Tylko że między „prawdą" a „zadziała u Ciebie" jest kilka progów, o których nie przeczytacie w zapowiedziach — bo zapowiedzi pisano na podstawie roadmapy, a te progi widać dopiero w notatkach deweloperskich i w panelu.

Po kolei.

Co się faktycznie zmieniło

Do 7.0 przełącznik urządzeń w edytorze zmieniał wyłącznie podgląd. Klikałeś „telefon", widziałeś wąską kolumnę i tyle — żeby cokolwiek na niej poprawić, otwierałeś arkusz stylów.

W 7.1 ten sam przełącznik zmienia tryb edycji. Przechodzisz na widok mobilny, zmieniasz rozmiar tekstu, i ta zmiana zapisuje się tylko dla telefonu. W panelu bloku pojawia się plakietka informująca, który widok właśnie edytujesz.

Mechanika jest prostsza, niż się wydaje. Istnieją dokładnie dwa stany responsywne — @mobile i @tablet. Nie ma stanu @desktop. Domyślny styl bloku jest stylem desktopowym i obowiązuje wszędzie, dopóki węższy widok go nie nadpisze. Czyli: kaskada w dół, nie w górę.

Działa to na dwóch poziomach: w Stylach globalnych dla całego typu bloku i na pojedynczej instancji bloku na konkretnej podstronie. Obejmuje wszystkie bloki korzystające z systemowych block supports — typografię, kolor, tło, obramowanie, wymiary, odstępy i układ.

W kodzie wpisu wygląda to tak:

html

<!-- wp:paragraph {"style":{"@mobile":{"typography":{"fontSize":"1rem"}}}} -->
<p>Akapit z responsywnym rozmiarem pisma.</p>
<!-- /wp:paragraph -->

Na froncie WordPress generuje z tego CSS opakowany w media query i dokleja blokowi wygenerowaną, stabilną klasę.

Przy okazji drobiazg, który nas ucieszył bardziej niż całe responsive styling: płótno edytora można teraz przeciągnąć na dowolną szerokość, nie tylko trzy presety. Wreszcie widać, gdzie dokładnie układ się łamie, zamiast zgadywać między 768 a 1024.

Cztery miejsca, w których to nie zadziała

1. Strona na page builderze

To pierwszy próg i dla polskiego rynku najważniejszy, bo dotyczy większości firmowych stron — łącznie z naszą.

Wszystko, co opisaliśmy wyżej, dotyczy bloków. Jeśli strona stoi na Divi, Elementorze albo WPBakery, to Twój układ nie składa się z bloków, tylko z modułów buildera. Nowy przełącznik responsywności nie ma czego przełączać. Zobaczysz go w edytorze wpisów, ale strona główna, oferta i kontakt zbudowane builderem pozostaną dokładnie tam, gdzie były.

Nie jest to zarzut wobec 7.1 — buildery mają własne kontrolki responsywne od lat, zwykle lepsze. To po prostu ostrzeżenie przed rozczarowaniem: aktualizacja nie odblokuje funkcji, o której czytałeś, jeśli nie pracujesz w edytorze blokowym.

Kto zyska naprawdę: strony na motywach blokowych, czyli Twenty Twenty-Four i nowsze oraz motywy FSE. Kto siedzi na klasycznym motywie z builderem — dostaje to wydanie głównie jako aktualizację bezpieczeństwa i usprawnienia mediów.

2. Breakpointy, które nie pasują do niczego

Wartości domyślne są takie:

Popatrzcie na to chwilę dłużej. Powyżej 782 px zaczyna się „desktop". Czyli iPad w pionie (768 px) łapie się jeszcze na tablet, ale iPad w poziomie, każdy laptop i każdy większy tablet dostają styl desktopowy. Zakres tabletu ma szerokość 302 pikseli.

To nie są breakpointy Bootstrapa, nie są Tailwinda, nie są też breakpointami żadnego popularnego motywu. 782 px to historyczna wartość z panelu administracyjnego WordPressa.

Da się je zmienić — ale wyłącznie w theme.json, nową sekcją najwyższego poziomu:

json

"settings": {
    "viewport": {
        "mobile": "30rem",
        "tablet": "48rem"
    }
}

I tu drugie ostrzeżenie: nie ma na to interfejsu. Klient tego nie zmieni, Ty też nie zmienisz tego z panelu. Trzeba dotknąć pliku motywu, czyli w praktyce mieć motyw potomny albo blokowy. Dodatkowo wartości muszą być w px, em lub rem — procenty, funkcje CSS i liczby bez jednostki są po cichu ignorowane. Jeśli ustawisz tablet mniejszy lub równy mobile, WordPress użyje samego mobile i nic Ci o tym nie powie.

Ustawienie jest globalne. Nie da się go zdefiniować osobno dla poszczególnych typów bloków.

3. Hover działa na dwóch blokach. Dosłownie dwóch

W komunikatach prasowych brzmi to jak rewolucja: stany :hover, :focus, :focus-visible i :active bez CSS-a.

W rzeczywistości kontrolki obejmują wyłącznie blok Przycisk i blok Odnośnik nawigacji. Nagłówki, obrazki, grupy, karty produktów — nie. Jeśli utrzymujesz arkusz stylów z hoverami, wyrzucisz z niego może dwie reguły.

Najzabawniejsze jest to, że sam WordPress wcale tego nie ukrywa. Wystarczy przeczytać ekran powitalny, który wyskakuje zaraz po aktualizacji: responsywność opisano tam jako dotyczącą wszystkich bloków, a stany najechania, fokusu i aktywne — jako dotyczące bloku Przycisk. W liczbie pojedynczej, z nazwą konkretnego bloku.

Polskie tłumaczenie panelu jest więc precyzyjniejsze niż połowa branżowych nagłówków, które sprzedały tę funkcję jako „hover bez CSS-a" i nie dopisały ani słowa zastrzeżenia.

Architektura jest przygotowana pod rozszerzenie na kolejne bloki w przyszłych wydaniach, ale w 7.1 to jest tyle. Warto o tym pamiętać, zanim obieca się klientowi, że „teraz sam sobie zmieni hover na kafelkach".

Osobna ciekawostka dla motywów: stan „bieżącej" pozycji menu (-current) można wreszcie ostylować deklaratywnie w theme.json, zamiast polować na .current-menu-item w CSS. Też bez interfejsu — tylko z pliku.

4. !important, którego nikt nie zapowiadał

To jest ten próg, na którym najłatwiej się przewrócić, i jedyny, który może popsuć działającą stronę.

Style responsywne ustawione na pojedynczej instancji bloku — te nielayoutowe — WordPress oznacza w wygenerowanym CSS jako !important. Powód jest logiczny: muszą przebić style inline, które blok już na sobie ma.

Skutek uboczny jest mniej logiczny. Jeżeli masz własny CSS, który celuje w ten sam blok i tę samą właściwość, to od teraz przegrywa — niezależnie od specyficzności selektora. Wystarczy, że ktoś kiedyś kliknął ustawienie w widoku mobilnym.

Do tego dochodzi zmiana, która idzie w przeciwną stronę: selektory presetów są teraz owinięte w :where(), co obniża ich specyficzność do zera. Część nadpisań, które pisaliście, żeby przebić presety motywu, przestanie być potrzebna — a część zacznie działać inaczej, niż zakładaliście.

Praktyczny wniosek: przejdźcie po własnym arkuszu i wyrzućcie reguły, które istnieją wyłącznie dlatego, że edytor kiedyś nie umiał czegoś sam. Duplikowanie tego, co WordPress robi teraz natywnie, nie daje spójności. Daje konflikt, którego nie widać na desktopie.

Jeśli oddajecie strony klientom, przeczytajcie to

Nowe kontrolki są potężne i całkowicie nieodwracalne z poziomu „cofnij" po tygodniu. Klient, który odkryje przełącznik widoków i pobawi się nim przez kwadrans, potrafi rozjechać układ w sposób trudny do wyśledzenia — bo na desktopie wszystko wygląda dobrze.

WordPress 7.1 przewiduje ten scenariusz i daje dwa wyłączniki:

php

add_filter( 'block_editor_settings_all', function ( $settings ) {
    $settings['responsiveEditingEnabled']  = false; // widoki: mobile / tablet
    $settings['blockStatesEditingEnabled'] = false; // stany: hover / focus / active
    return $settings;
} );

Obie wartości domyślnie są ustawione na true. Po wyłączeniu znika przełącznik „Style responsywne" w menu Widok edytora oraz grupa „Widoki" w Stylach globalnych. Podgląd urządzeń działa dalej — znika tylko możliwość edycji per widok.

Najważniejsze: wyłączniki dotyczą wyłącznie interfejsu. Style responsywne zapisane wcześniej w theme.json, w Stylach globalnych albo w atrybucie bloku zostają nietknięte i nadal się renderują. Możecie więc ustawić responsywność sami, a potem zamknąć klientowi dostęp do kontrolek, nie tracąc efektu.

Dla nas to jest realnie najbardziej użyteczna rzecz w całym tym wydaniu.

Czy aktualizować

My zaktualizowaliśmy tej samej nocy. Wam byśmy tego nie doradzili — i to nie jest hipokryzja, tylko różnica w profilu ryzyka.

Nasza strona ma kilkanaście podstron, żadnych zamówień w toku, żadnych zewnętrznych autorów, a jak coś pęknie o trzeciej w nocy, to naprawiamy to sami i nikt tego nie zauważy. Sklep z ruchem, strona z rezerwacjami albo serwis, na którym publikuje pięć osób, to zupełnie inny rachunek. Tam koszt jednego dnia zwłoki jest bliski zeru, a koszt jednej nocy z zepsutym koszykiem — nie.

Sprawdziliśmy też rzeczy, których na oko nie widać: wysyłkę pliku do mediów, formularz kontaktowy, hover w nawigacji, listę wpisów w kółku. Bez niespodzianek — u nas nic nie pękło.

Z jednym zastrzeżeniem, które jest ważniejsze niż sam wynik: nasza strona stoi na builderze, więc znaczna część tego wydania fizycznie nie ma czego u nas dotknąć. Czysty przebieg na Divi z kilkunastoma podstronami nie mówi nic o tym, co stanie się na motywie blokowym z rozbudowanymi Stylami globalnymi i własnym arkuszem CSS. To jest dokładnie ten przypadek, w którym „u nas działa" znaczy głównie tyle, że u nas nie było czego zepsuć.

Cztery ryzyka opisane wyżej mają wspólną cechę — nie ujawniają się przy przeglądaniu strony wzrokiem. !importantprzebijający Wasz CSS pokazuje się dopiero poniżej 782 px, nowa ścieżka przetwarzania mediów dopiero przy wrzuceniu pliku, a formularz dopiero przy wysłaniu. Każdą z tych rzeczy trzeba kliknąć osobno i świadomie.

Jeśli robicie to porządnie, kolejność jest zwyczajna i nudna: kopia zapasowa, staging z tym samym motywem, tymi samymi wtyczkami i tą samą wersją PHP, przegląd własnego arkusza stylów pod kątem punktu 4, test wysyłki pliku i formularza, dopiero potem produkcja. Jeśli macie tydzień cierpliwości, poczekajcie na 7.1.1 — przy 7.0 pierwsze łatki przyszły szybko.

Jeśli natomiast siedzicie jeszcze na 7.0.2 albo starszej, to zupełnie inna rozmowa i inny priorytet: w lipcu i sierpniu wyszły trzy aktualizacje bezpieczeństwa pod rząd. Ten aspekt opisaliśmy osobno przy okazji WordPressa 7.0.3.

A czego w 7.1 nie ma, mimo zapowiedzi? Współpracy w czasie rzeczywistym. Znowu. Miała być gwoździem trzeciej fazy Gutenberga, przesunięto ją z 7.0, przesunięto z 7.1. Wygląda na to, że opiszemy ją najwcześniej przy 7.2 w grudniu — o ile tym razem dojedzie.

Aktualizowaliśmy studio.ifox.pl do 7.1 w nocy z 19 na 20 sierpnia — staging, przegląd, produkcja, ekran powitalny o 1:01. Media, formularz i nawigacja sprawdzone, bez problemów. Jeśli utrzymujecie stronę firmową i nie macie pewności, co zrobi u Was ta aktualizacja — napiszcie, sprawdzimy to na kopii, zanim dotkniecie produkcji.