No replies to this topic

[Wiktor66]

  19 sierpnia wyszedł WordPress 7.1 „Mary Lou". Dwa dni temu. To dobry moment, żeby odświeżyć wątek „Gutenberg czy Elementor", bo połowa argumentów, które padały tu jeszcze rok temu, właśnie się zdezaktualizowała. Poniżej konkrety — co edytor blokowy realnie potrafi w tej chwili, gdzie nadal przegrywa i jak nad nim pracować, żeby aktualizacja strony zajmowała minuty, a nie wieczór. 1. Gutenberg to już nie jest „edytor tekstu"

W 2018 (WP 5.0) Gutenberg był edytorem treści dla wpisów i stron. Dziś to warstwa, w której składasz całą witrynę:

• edytor treści (wpisy, strony),
• Edytor witryny (FSE) — nagłówek, stopka, szablony archiwum, single, 404,
• globalne style — typografia, paleta, odstępy zdefiniowane raz, w theme.json,
• wzorce (patterns) i części szablonu — powtarzalne sekcje jako jeden byt.

Zmiana jest głównie mentalna: przestajesz formatować tekst, a zaczynasz składać strukturę. Kto tego nie przeskoczy, będzie walczył z Gutenbergiem w nieskończoność.

2. Logika bloków w pięć minut

Rzeczy, które realnie skracają pracę:

• Bloki kontenerowe (Grupa / Wiersz / Stos / Siatka) to fundament. 90% frustracji bierze się stąd, że ktoś styluje pojedyncze akapity zamiast kontenera, który je obejmuje. Ustaw tło, padding i wyrównanie na Grupie — nie na czterech blokach osobno.
• Widok listy (Ctrl+Alt+O) — traktuj jak drzewko DOM. Przeciąganie bloków tutaj jest nieporównywalnie pewniejsze niż na kanwie, a przy okazji od razu widzisz hierarchię nagłówków.
• Ukośnik / — wstawianie bloku z klawiatury. /kolumny, /przycisk, /obraz. Bez sięgania po myszkę.
• Kopiuj-wklej działa między witrynami. Bloki to zwykły HTML z komentarzami <!-- wp:paragraph -->. Ctrl+C na bloku w jednym WordPressie, Ctrl+V w drugim — przenosi się razem ze stylami.
• Wzorce niesynchronizowane vs synchronizowane. Pierwsze to szablon do jednorazowego wstawienia. Drugie — jedna edycja aktualizuje wszystkie wystąpienia na stronie. Do CTA, boksu kontaktowego czy sekcji z opiniami to różnica między minutą a godziną przy każdej zmianie.
• Blokowanie bloków (block locking) — jeśli oddajesz stronę klientowi, zablokuj krytyczne sekcje przed przesuwaniem i usuwaniem. Oszczędza telefony „strona się rozjechała".

3. Co faktycznie zmieniło się w 7.0 i 7.1

WordPress 7.0 (20 maja 2026) — pierwsze wydanie „x.0" od czasu 5.0:

• WP AI Client — SDK po stronie PHP wbudowane w rdzeń, plus Abilities API standaryzujące, jak wtyczki i motywy sięgają po modele (uwierzytelnianie, limity, kontekst).
• minimalne wymagane PHP podniesione do 7.4,
• odświeżony panel administracyjny,
• współpraca w czasie rzeczywistym ostatecznie NIE weszła do wydania — została wycofana na etapie RC. Warto to wiedzieć, bo część publikacji zdążyła ją ogłosić jako gotową.

WordPress 7.1 „Mary Lou" (19 sierpnia 2026) — wydanie typu „dokończmy, co zaczęliśmy":

• responsywne style natywnie — inne wartości dla mobile / tabletu / desktopu bez pisania media queries,
• stany interaktywne :hover, :focus, :active ustawiane z interfejsu (wsparcie zależy jeszcze od bloku — sprawdź te, których używasz),
• nowe bloki Zakładki (Tabs) i Playlist blok Spisu treści przesunięto na 7.2,
• przebudowany edytor mediów i skalowanie obrazów w przeglądarce przed uploadem — koniec z timeoutami przy wrzucaniu zdjęć 6000 px prosto z telefonu,
• Notatki: @wzmianki, tryb sugestii, formatowanie, reakcje — czyli asynchroniczne uwagi do treści bez wychodzenia do maila,
• przeorganizowana paleta poleceń, stały pasek admina w edytorach, linki do konkretnych rewizji,
• dla deweloperów: Icons API i wymuszony iframe edytora — własne bloki i wtyczki warto przetestować,
• 7 lipca odwołano planowane wycofanie bloku Classic, więc stare treści nie zostają osierocone.

I teraz sedno w kontekście odwiecznego sporu: dwa najczęściej podnoszone argumenty za page builderem — precyzyjna kontrola responsywności i stany hover bez dotykania CSS — właśnie trafiły do rdzenia. Za darmo.

4. Gutenberg vs Elementor — uczciwie, po kryteriach   Gutenberg Elementor / Divi Koszt 0 licencja roczna, zwykle per liczba stron Wydajność lżejszy DOM i CSS, mniej zależności własny framework CSS/JS ładowany na każdej podstronie Lock-in zostaje czysty HTML po wyłączeniu zostają shortcode'y i puste divy Krzywa uczenia wymaga zrozumienia hierarchii kontenerów szybciej „intuicyjny" na start Utrzymanie aktualizuje się z rdzeniem dodatkowe ogniwo w łańcuchu zgodności motyw + builder + Woo + WP

Zastrzeżenie, żeby było fair: źle zrobiony motyw blokowy też potrafi być ciężki, a dobrze zoptymalizowany Elementor da przyzwoite Core Web Vitals. Różnica jest statystyczna, nie magiczna.

Gdzie builder nadal wygrywa: popupy, warunki wyświetlania, rozbudowany theme builder pod WooCommerce, zaawansowane animacje, gotowe kity, i — zupełnie serio — zespół, który ma w nim wypracowany proces i deadline na przyszły tydzień.

Środek drogi, o którym często się zapomina: GenerateBlocks, Kadence Blocks, Spectra. Rozszerzają natywne bloki i dają większość możliwości buildera bez jego narzutu.

5. SEO — bez ściemy

Gutenberg sam z siebie nie pozycjonuje. Co realnie wnosi:

• kontrola hierarchii nagłówków — Widok listy pokazuje strukturę H1–H6 na jednym ekranie, więc od razu wychwycisz dwa H1 albo przeskok z H2 na H4,
• mniejszy narzut CSS/JS → lepsze Core Web Vitals, głównie LCP i INP. To czynnik pomocniczy, nie przełącznik do topu,
• powtarzalna struktura treści — łatwiej utrzymać spójny szablon podstron ofertowych,
• lokalnie: dane NAP (nazwa, adres, telefon) jako wzorzec synchronizowany na wszystkich podstronach. Zmiana numeru = jedna edycja, zero rozjazdów w danych, które Google i tak porównuje z wizytówką. Strony lokalizacyjne buduj z jednego wzorca zamiast kopiuj-wklej,
• FAQ rób blokiem Szczegóły/Akordeon dla użytkownika i kontekstu — ale bez złudzeń: rozszerzone wyniki FAQ Google od 2023 pokazuje w praktyce tylko stronom rządowym i medycznym.

6. Ośmiopunktowa checklista, jeśli chcesz pracować szybciej

1. Naucz się Widoku listy zamiast klikania po kanwie.
2. Ustaw globalne style (typografia, kolory, odstępy) zanim zaczniesz budować podstrony.
3. Zrób 5–8 własnych wzorców: hero, CTA, sekcja opinii, boks kontaktowy, cennik.
4. CTA i dane kontaktowe → wzorce synchronizowane.
5. Zablokuj krytyczne bloki przed oddaniem strony klientowi.
6. Nagłówek i stopka → części szablonu, nie kopia na każdej stronie.
7. Własny CSS trzymaj w theme.json lub motywie potomnym, nie w polu „dodatkowy CSS" per strona.
8. Przed każdą dużą aktualizacją: kopia plików i bazy, plus test przywrócenia. Backup, którego nigdy nie odtworzyłeś, to poczucie bezpieczeństwa, nie bezpieczeństwo.

7. Kiedy Gutenberg nie jest odpowiedzią

• Masz 200 podstron w Elementorze i one działają. Migracja to koszt bez zwrotu — chyba że i tak robisz redesign.
• Potrzebujesz popupów, logiki warunkowej i theme buildera pod sklep. Natywnie to nadal domena wtyczek.
• Zespół ma wypracowany proces w builderze, a klient czeka. Narzędzie, którego nikt nie umie obsłużyć, nie jest lżejsze.

8. Migracja — trzy zdania prawdy

„Konwertuj na bloki" ogarnia proste treści z edytora klasycznego, ale layoutu buildera nie odtworzy. Z buildera migruje się przez przebudowę szablonów, nie przez wtyczkę-magika. Po migracji sprawdź: osierocone shortcode'y, obrazy z bibliotek buildera, formularze i przekierowania.

Dłuższe omówienie samego edytora, rodzajów bloków i różnic wobec edytora klasycznego opisaliśmy tutaj: Gutenberg w WordPress — co to jest i jak zmienia tworzenie treści
 

A Wy jak to robicie? Ciekawi mnie zwłaszcza, czy ktoś zdążył już przetestować responsywne style z 7.1 na produkcji i czy stany hover działają na wszystkich blokach, których używacie — bo wsparcie podobno bywa nierówne.