Gutenberg od kilku lat jest domyślnym edytorem WordPressa i całkowicie zmienia sposób tworzenia treści. Zamiast jednego dużego pola tekstowego pracujemy z modułami – blokami, które można przesuwać, klonować, stylować i ponownie wykorzystywać. Dla twórców stron i deweloperów otwiera to ogromne możliwości: można przygotować własne, dopasowane do projektu bloki, które ułatwią klientom edycję i zachowanie spójności wizualnej. Poniższy poradnik pokazuje krok po kroku, jak podejść do tworzenia własnych bloków Gutenberg w WordPressie – od fundamentów, przez konfigurację środowiska, po praktyczny przykład.
Dlaczego warto tworzyć własne bloki Gutenberg
Standardowy zestaw bloków dostępny w WordPressie jest bogaty, ale w profesjonalnych projektach szybko okazuje się niewystarczający. Każdy klient, marka czy serwis ma swoje wymogi: indywidualny design, specyficzne typy treści, powtarzalne sekcje wymagające łatwej edycji. Właśnie wtedy na scenę wkraczają niestandardowe bloki, które pozwalają połączyć elastyczność edycji z pełną kontrolą nad wyglądem.
Tworzenie własnych bloków przynosi kilka kluczowych korzyści. Po pierwsze, umożliwia zablokowanie zbyt dowolnej edycji layoutu przez użytkowników nietechnicznych, co chroni witrynę przed chaosem. Po drugie, gotowe bloki z logiką biznesową (np. sekcja opinii, cennik, slider, kafelki ofertowe) znacznie przyspieszają budowanie podstron. Po trzecie, własny zestaw bloków ułatwia standaryzację pracy agencji i przenoszenie sprawdzonych rozwiązań między projektami.
Gutenberg to w rzeczywistości warstwa UI nad bardziej rozbudowaną infrastrukturą opartą na React i REST API. Każdy blok składa się z definicji w JavaScript, opcjonalnego kodu PHP oraz stylów CSS. Celem tego artykułu nie jest dogłębną nauka Reacta, ale przedstawienie konkretnej ścieżki, jak przejść od nowej instalacji WordPressa do własnego funkcjonalnego bloku. Nawet jeżeli nie jesteś programistą na pełen etat, zrozumienie tych zasad pozwoli Ci lepiej współpracować z deweloperami i świadomie planować strukturę treści w projektach.
Istotną motywacją do nauki jest też trend w samym WordPressie – z wersji na wersję rośnie nacisk na pełną edycję witryny (Full Site Editing) oraz bloki oparte na JSON. Coraz więcej szablonów i rozszerzeń jest zbudowanych w oparciu o blokowy paradygmat. Inwestując czas w naukę tworzenia bloków, inwestujesz w przyszłość swojego ekosystemu WordPress, zamiast opierać się na rozwiązaniach, które stopniowo będą tracić znaczenie.
Podstawy architektury bloków w WordPressie
Aby świadomie tworzyć bloki, warto najpierw zrozumieć, z czego się składają i jak WordPress je rejestruje. Na najprostszym poziomie blok jest zdefiniowany przez metadane (najczęściej w pliku block.json) oraz logikę odpowiedzialną za renderowanie widoku w edytorze i na froncie. W tradycyjnym podejściu wykorzystywano głównie rejestrację bloków przez JavaScript, obecnie coraz silniej promowany jest format oparty na JSON, który upraszcza wiele czynności.
Kluczowym elementem klasycznego bloku jest funkcja registerBlockType. To właśnie ona określa nazwę bloku, kategorię w inserterze, ikonkę, zestaw atrybutów oraz funkcje edycji i zapisu. Atrybuty definiują to, co użytkownik może wpisać, wybrać lub przełączyć, a następnie przechowywane są w treści wpisu (w strukturze komentarzy HTML) lub w metadanych. Dlatego poprawne opisanie atrybutów jest ważne także z punktu widzenia zgodności wstecznej i migracji danych.
Po stronie PHP WordPress potrzebuje informacji, że dany blok w ogóle istnieje. W najprostszej wersji wystarczy użyć funkcji register_block_type z odpowiednią ścieżką lub tablicą argumentów. Gdy wykorzystujemy plik block.json, ta funkcja może załadować metadane bez konieczności powielania definicji. Dodatkowo, po stronie PHP można zdefiniować serwerowy sposób renderowania – przydaje się to, gdy blok pobiera dynamiczne dane, np. listę wpisów z bazy.
Struktura katalogowa też ma znaczenie. Dobrą praktyką jest umieszczenie każdego bloku w osobnym folderze, zawierającym minimum pliki: block.json, skrypt dla edytora, skrypt frontowy (jeśli potrzebny) oraz arkusz stylów. Dzięki temu łatwo utrzymać porządek, a także szybko odnaleźć kod odpowiedzialny za konkretny element interfejsu. Taki układ jest szczególnie wygodny, jeśli w jednym motywie lub wtyczce masz kilkanaście lub kilkadziesiąt różnych bloków.
Na architekturę bloków wpływ ma również podział na statyczne i dynamiczne. Bloki statyczne zapisują pełne HTML w treści wpisu, a ich rola sprowadza się głównie do dodania właściwych klas i atrybutów. Bloki dynamiczne generują zawartość podczas renderowania strony na podstawie aktualnego stanu bazy danych lub ustawień. W zależności od potrzeb projektu trzeba zdecydować, które podejście jest odpowiednie, bo wpływa to zarówno na wydajność, jak i na możliwości edycji.
Przygotowanie środowiska do tworzenia bloków
Tworzenie bloków Gutenberg wymaga minimalnego przygotowania środowiska developerskiego. Po pierwsze, potrzebujesz instalacji WordPressa, najlepiej lokalnej, aby szybko testować zmiany bez wpływu na stronę produkcyjną. Popularne rozwiązania to Local, XAMPP, Laragon czy Docker. Ważne, aby mieć wygodny dostęp do plików motywu oraz konsolę systemową obsługującą npm.
Kolejnym krokiem jest instalacja Node.js oraz menedżera pakietów npm lub yarn. Większość narzędzi do bundlowania skryptów bloków (Webpack, Vite, Parcel) oraz gotowe boilerplate’y korzystają z ekosystemu JavaScript i wymagają zainstalowania zależności. W przypadku WordPressa warto sięgnąć po oficjalne pakiety @wordpress/scripts, które udostępniają prekonfigurowane narzędzia do kompilacji nowoczesnego JS ze wsparciem JSX i kompatybilnością z React.
W praktyce praca nad blokami najczęściej odbywa się w ramach motywu potomnego lub dedykowanej wtyczki. Druga opcja bywa wygodniejsza wtedy, gdy chcesz mieć przenośny zestaw bloków, niezależny od konkretnego szablonu. Niezależnie od wyboru kluczowe jest jasne oddzielenie kodu obsługującego bloki od reszty logiki, co ułatwi utrzymanie i ewentualną migrację. Rozsądnie jest przygotować od razu strukturę katalogów przewidującą rozwój.
Ważnym elementem konfiguracji jest też zadbanie o poprawne wersjonowanie i ładowanie skryptów. Funkcje wp_enqueue_script oraz wp_enqueue_style powinny być użyte w taki sposób, aby nie powodować konfliktów z innymi pluginami i motywami. W praktyce oznacza to stosowanie unikalnych nazw uchwytów, zależności zadeklarowanych na bazie pakietów WordPressa (np. wp-blocks, wp-element) oraz ewentualnych wersji opartych na czasie modyfikacji pliku, co ułatwia odświeżanie cache w trakcie prac.
Nie trzeba jednak konfigurować wszystkiego od zera. Z pomocą przychodzą narzędzia takie jak @wordpress/create-block, które generują bazową strukturę wtyczki z jednym blokiem i gotowym środowiskiem buildowym. To dobra droga na start – zamiast walczyć z webpackiem, można od razu skupić się na logice i wyglądzie. W dalszej części artykułu pokażemy, jak ręcznie przejść przez ten proces, aby lepiej zrozumieć, co dzieje się pod maską, ale korzystanie z generatorów znacząco przyspiesza codzienną pracę.
Rejestracja własnego bloku za pomocą PHP i block.json
Jednym z najważniejszych kroków podczas tworzenia własnego bloku jest jego prawidłowa rejestracja w WordPressie. Tradycyjnie wykorzystywano do tego wyłącznie kod JS, jednak obecnie rekomendowanym wzorcem jest połączenie pliku block.json z funkcją register_block_type po stronie PHP. Pozwala to w centralny sposób opisać wszystkie parametry bloku i wykorzystać te metadane w narzędziach deweloperskich.
Plik block.json znajduje się zwykle w katalogu danego bloku. Zawiera takie informacje jak unikalna nazwa (np. plugin/hero-box), tytuł, opis, kategoria, ikona, a także ścieżki do skryptów i stylów. Dodatkowo można w nim zdefiniować atrybuty i tryb renderowania. Dzięki temu WordPress oraz narzędzia typu create-block są w stanie automatycznie rozpoznać strukturę i poprawnie załadować odpowiednie pliki w edytorze oraz na froncie.
Po stronie PHP w pliku głównym wtyczki lub motywu należy dodać fragment kodu, który wywoła funkcję register_block_type z parametrem wskazującym na lokalizację block.json. W najprostszym wariancie sprowadza się to do wywołania register_block_type przy inicjalizacji, np. na hooku init. To właśnie ten moment decyduje, że blok staje się widoczny w inserterze Gutenberg i może zostać użyty w treści wpisów lub stron.
Jeśli blok ma być dynamiczny, w tablicy argumentów przekazywanej do register_block_type można określić parametr render_callback, wskazujący na funkcję PHP odpowiedzialną za generowanie HTML. Dzięki temu zawartość bloku jest wyliczana w locie na podstawie aktualnych danych z bazy, co przydaje się np. do listowania najnowszych wpisów, elementów z custom post types czy zewnętrznych API. Atrybuty przekazane z edytora są wówczas dostępne w parametrze callbacku.
Duże znaczenie ma także poprawne określenie zależności między skryptami. Gdy korzystasz z @wordpress/scripts i importujesz moduły WordPressa, bundler automatycznie zadba o prawidłowe powiązania, jednak pozytywne nawyki obejmują również ręczne deklarowanie dependencies w rejestracji skryptów. Przejrzysta deklaracja ułatwia debugowanie, gdy w projekcie współistnieje wiele wtyczek ingerujących w edytor bloków.
Warto pamiętać, że block.json stanowi nie tylko techniczny opis bloku, ale też czytelny punkt dokumentacji dla innych członków zespołu. Dobrze opisane pola, przemyślane nazwy i spójne nazewnictwo przestrzeni nazw ułatwiają życie przy większych implementacjach, w których dziesiątki bloków muszą tworzyć harmonijny ekosystem. Zignorowanie tej warstwy porządku zwykle mści się przy pierwszej większej rozbudowie projektu.
Tworzenie logiki edycji i wyglądu bloku w JavaScript
Po zarejestrowaniu bloku w systemie WordPress nadchodzi etap definiowania jego zachowania w edytorze, czyli napisania odpowiedniego skryptu JavaScript. To tutaj decydujesz, jakie pola edycyjne zobaczy użytkownik, jak będą one reagować na wpisywany tekst, wybierane kolory czy przełączane opcje. Całość opiera się na wykorzystaniu komponentów dostarczanych przez pakiet @wordpress/components oraz funkcji i hooków z @wordpress/block-editor.
Kluczowym elementem jest funkcja edit, która odpowiada za renderowanie widoku bloku wewnątrz edytora Gutenberg. Otrzymuje ona obiekt props, zawierający m.in. atrybuty, ustawienia, funkcje służące do ich aktualizacji oraz informacje o kontekście. Wewnątrz funkcji najczęściej używa się JSX, aby deklaratywnie opisać strukturę interfejsu, łącząc elementy HTML z komponentami WordPressa. To właśnie tutaj umieszczasz pola edycyjne, panele boczne i akcje.
Druga ważna funkcja to save, która definiuje, jaki HTML trafi finalnie do treści wpisu. Dla bloków statycznych zapisuje ona wynikową strukturę, korzystając z aktualnych wartości atrybutów. W przypadku bloków dynamicznych save może zwracać null, ponieważ całe renderowanie odbywa się po stronie serwera w callbacku PHP. W obu scenariuszach istotne jest zachowanie stabilnej struktury HTML, aby uniknąć problemów przy aktualizacjach i refaktoryzacjach.
Projektując interfejs edycji, warto wykorzystywać komponenty przygotowane specjalnie z myślą o Gutenberg: panele z zakładkami, selektory kolorów, suwaki, pola wyboru, kontrolki typografii. Pozwala to zachować spójność z resztą edytora i ułatwia użytkownikom intuicyjne korzystanie z bloku. Zamiast wymyślać własne patterny UI, lepiej oprzeć się na istniejących rozwiązaniach, co dodatkowo minimalizuje koszty utrzymania.
Atrybuty bloku pełnią tu kluczową rolę, bo to właśnie one są łącznikiem między edytorem a zapisanym HTML. Każda zmiana wprowadzona przez użytkownika powinna aktualizować odpowiednie pole atrybutu, a następnie propagować się do widoku. Przy większych blokach kontrola nad liczbą atrybutów, ich typami i domyślnymi wartościami staje się ważnym elementem architektury, wpływającym na wydajność i czytelność kodu.
W nowoczesnym podejściu do tworzenia bloków coraz częściej pojawiają się hooki Reacta oraz własne hooki specyficzne dla Gutenberga. Pozwalają one np. na zarządzanie stanem lokalnym, reagowanie na zmiany kontekstu czy pobieranie danych z innych źródeł. Chociaż na początku może się to wydawać skomplikowane, w praktyce otwiera drogę do budowania bardzo zaawansowanych bloków, które nie ustępują złożonością rozbudowanym aplikacjom webowym.
Styling i integracja z motywem
Sam kod JS i PHP to dopiero połowa sukcesu. Aby blok dobrze prezentował się w edytorze i na froncie, trzeba zadbać o warstwę wizualną. W ekosystemie Gutenberg oznacza to najczęściej przygotowanie dwóch plików stylów: jednego przeznaczonego dla edytora, drugiego dla części publicznej. Taki podział pozwala uniknąć niepotrzebnego obciążenia frontu efektami, które mają znaczenie tylko podczas edycji (np. linie pomocnicze, podgląd placeholderów).
Podstawową zasadą jest wykorzystanie klas CSS zdefiniowanych w szablonie generowanym przez funkcje save lub render_callback. Blok zawsze otrzymuje własną klasę bazową (np. wp-block-plugin-hero-box), którą można wykorzystać jako punkt odniesienia. Wokół niej buduje się hierarchię elementów wewnętrznych, pamiętając o spójności z systemem typografii, siatki i kolorów stosowanym w motywie. Dzięki temu blok wtapia się w całość, zamiast wyglądać jak obcy element.
Najnowsze wersje WordPressa oferują również system globalnych stylów i zmiennych, które można wykorzystywać w blokach. Dotyczy to zarówno kolorów, jak i ustawień typografii czy odstępów. Im lepiej dopasujesz blok do mechanizmu theme.json oraz narzędzi globalnego stylowania, tym łatwiej będzie użytkownikom zarządzać wyglądem bez grzebania w kodzie. To ważny krok w stronę bardziej designerskiego, a mniej developerskiego zarządzania witryną.
Przy stylowaniu bloków warto pamiętać o responsywności. Nawet jeśli w edytorze blok wygląda idealnie na szerokim ekranie, musi też zachować przejrzystość na tabletach i smartfonach. Odpowiednie media queries lub wykorzystanie elastycznych jednostek pozwalają zapewnić poprawne skalowanie. W niektórych przypadkach konieczne jest zaoferowanie użytkownikom dodatkowych opcji sterujących układem na różnych breakpointach, co wiąże się z rozbudową atrybutów.
Nie można też pominąć kwestii wydajności. Nadmierna liczba plików CSS ładowanych bezrefleksyjnie na każdej podstronie szybko odbija się na czasie ładowania. Dlatego sensowne jest grupowanie stylów bloków w jednym lub kilku arkuszach, zamiast generowania osobnego pliku dla każdego najmniejszego komponentu. Z drugiej strony zbyt agresywne łączenie wszystkiego w jeden plik utrudnia modularne utrzymanie. Optymalny kompromis zależy od skali projektu i przyjętej strategii cache’owania.
Praktyczny przykład: prosty blok sekcji hero
Teoria staje się znacznie bardziej przystępna, gdy przełożymy ją na konkretny przykład. Załóżmy, że chcesz stworzyć prosty blok typu hero – duży nagłówek, podtytuł, przycisk z linkiem oraz tło w formie obrazu lub koloru. Celem jest umożliwienie edytorowi treści szybkiego dodania takiej sekcji na dowolnej stronie bez konieczności wchodzenia w customizer czy edycję kodu szablonu. Tego typu blok pojawia się w wielu projektach, więc łatwo będzie go potem wielokrotnie wykorzystać.
Pierwszym krokiem jest przygotowanie struktury katalogów, np. w ramach wtyczki: folder hero-block, a w nim plik block.json, plik JS z logiką edycji i ewentualnego zapisu, plik CSS oraz skrypt PHP rejestrujący blok. W block.json definiujesz nazwę bloku, etykiety i pola atrybutów: tytuł, opis, tekst przycisku, adres URL oraz ustawienia tła. Już na tym etapie warto przemyśleć domyślne wartości, aby po wstawieniu bloku od razu było coś widać.
Następnie w pliku JS piszesz funkcję edit, która wyświetli w edytorze kontrolki dla tytułu, treści oraz przycisku. Możesz wykorzystać komponenty takie jak RichText do edytowalnych pól tekstowych, TextControl do adresu URL, a także panel boczny z ColorPalette dla wyboru koloru tła. Każda zmiana wywołuje setAttributes, aktualizując odpowiednie pola w obiekcie atrybutów. Równocześnie w tym samym komponencie JSX renderujesz podgląd hero z zastosowaniem bieżących ustawień.
W funkcji save definiujesz ostateczną strukturę HTML: div otaczający, nagłówek, paragraf, link stylizowany jako przycisk oraz odpowiednie klasy. Stylowanie sekcji hero przenosisz do CSS, gdzie ustawiasz np. duże marginesy, wycentrowanie treści i rozmiary typografii. Dzięki temu edytor treści, przeciągając blok w różne miejsce strony, zawsze widzi atrakcyjną, gotową do użycia sekcję, a Ty masz pewność, że całość pozostanie spójna wizualnie.
Taki blok można stopniowo rozbudowywać: dodać opcję wyrównania tekstu, wybór szerokości, przełącznik jasnej i ciemnej wersji, integrację z globalnymi stylami motywu. Z czasem pojawi się też potrzeba reużywania bloku w wielu projektach – wtedy przeniesienie go do osobnej wtyczki staje się naturalnym krokiem. Z jednego prostego przykładu zaczyna powstawać mała biblioteka bloków, która stanowi istotną przewagę konkurencyjną w pracy freelancera lub agencji.
Najczęstsze problemy i dobre praktyki
Podczas tworzenia własnych bloków Gutenberg nietrudno natrafić na typowe pułapki. Jednym z częstszych problemów są konflikty nazw – zarówno w przestrzeni nazw bloków, jak i uchwytów skryptów czy stylów. Zawsze stosuj unikalny prefiks związany z nazwą wtyczki lub motywu. To prosty nawyk, który pozwala uniknąć trudnych do zdiagnozowania błędów, gdy w projekcie pojawia się wiele pluginów od różnych dostawców.
Kolejna kwestia to kompatybilność wersji WordPressa. Korzystanie z najnowszych API Gutenberga w środowiskach, gdzie aktualizacje są opóźnione, może prowadzić do problemów. Dlatego warto świadomie dobierać minimalną wersję WordPressa, którą chcesz wspierać, oraz testować bloki na tej właśnie wersji. Jeżeli projekt wymaga wstecznej zgodności, konieczne mogą być warunkowe ścieżki ładowania lub rezygnacja z niektórych najnowszych udogodnień.
Istotnym obszarem jest też dostępność. Tworząc bloki, łatwo skupić się na efektowności wizualnej, zapominając o czytnikach ekranu, nawigacji klawiaturą czy właściwych atrybutach ARIA. Zadbaj, aby struktura HTML była semantyczna, przyciski miały zrozumiałe etykiety, a kontrast tekstu do tła był odpowiednio wysoki. To nie tylko kwestia standardów, ale również praktyczny wymóg w wielu projektach komercyjnych, zwłaszcza dla sektora publicznego.
W projektach obejmujących wiele bloków ogromne znaczenie ma także dokumentacja. Krótkie opisy przeznaczenia każdego bloku, zrzuty ekranu, wskazówki dla edytorów treści – wszystko to skraca czas wdrożenia nowych osób w projekcie i zmniejsza liczbę pytań kierowanych do działu technicznego. Warto zintegrować dokumentację z samym WordPressem, np. korzystając z zakładek pomocy w panelu lub krótkich opisów w inserterze.
Na koniec nie można pominąć testów. Zmiany w blokach mają bezpośredni wpływ na treści istniejących wpisów, więc nawet drobna modyfikacja struktury atrybutów czy HTML powinna być testowana na kopii bazy danych. W środowiskach produkcyjnych rozsądne jest stosowanie stopniowego wdrażania, np. poprzez tworzenie nowych wersji bloków i migratorów atrybutów, zamiast agresywnej, destrukcyjnej aktualizacji. Dzięki temu unikasz niespodzianek i zachowujesz zaufanie użytkowników.
Podsumowanie i dalsze kierunki rozwoju
Stworzenie własnego bloku Gutenberg to proces, który łączy w sobie kilka kompetencji: znajomość WordPressa, podstaw PHP, JavaScriptu oraz stylowania. Jednak po przejściu początkowej krzywej nauki zyskujesz narzędzie, które radykalnie usprawnia budowę i rozwój serwisów. Zamiast za każdym razem projektować stronę od zera, możesz pracować na zestawie przetestowanych, dopracowanych bloków, dostosowanych do potrzeb klientów i specyfiki branży.
Wraz z rozwojem pełnej edycji witryny oraz rozszerzania możliwości theme.json, rola bloków będzie stale rosnąć. Coraz więcej elementów, które dawniej należały wyłącznie do motywu, przenosi się do warstwy bloków i globalnych stylów. Mając tę świadomość, warto już teraz inwestować w pogłębienie wiedzy o architekturze bloków, narzędziach takich jak @wordpress/scripts, a także standardach projektowych i dostępnościowych, które decydują o jakości końcowego produktu.
Dalsze kroki mogą obejmować eksperymenty z blokami dynamicznymi, integracją z zewnętrznymi API, tworzeniem bardziej zaawansowanych paneli ustawień czy budową całych bibliotek bloków dystrybuowanych jako wtyczki. Innym kierunkiem jest zgłębianie ekosystemu React i hooków, co pozwoli tworzyć jeszcze bardziej interaktywne i rozbudowane komponenty. Niezależnie od wybranej ścieżki, fundament pozostaje ten sam: dobrze zaprojektowane, konsekwentnie wdrożone bloki są dziś jednym z kluczowych elementów profesjonalnego środowiska WordPress.
FAQ
Jak zacząć tworzyć własny blok Gutenberg bez dużej wiedzy o JavaScript?
Najłatwiej skorzystać z narzędzia @wordpress/create-block, które generuje gotową strukturę wtyczki z przykładowym blokiem. Następnie modyfikujesz tytuł, pola i wygląd krok po kroku, obserwując efekt w edytorze. Na start wystarczy rozumieć podstawy JSX oraz mechanizm atrybutów i funkcji edit/save; z czasem możesz stopniowo zgłębiać React.
Czy lepiej umieszczać bloki w motywie czy we wtyczce?
Jeśli blok jest ściśle związany z jednym motywem i nie planujesz go używać gdzie indziej, możesz trzymać go w motywie potomnym. Gdy jednak blok ma być przenośny między projektami, bezpieczniej zbudować osobną wtyczkę. Pozwala to zmieniać motywy bez utraty funkcjonalności i ułatwia aktualizacje, a także dystrybucję pakietu bloków w zespole lub w repozytorium.
Czy tworzenie własnych bloków ma wpływ na wydajność strony?
Tak, sposób implementacji bloków wpływa na wydajność. Zbyt wiele osobnych plików JS i CSS, ładowanych na każdej podstronie, może spowolnić witrynę. Należy grupować zasoby, stosować cache i dbać o lekkość kodu. Dobrze zaprojektowane bloki, korzystające z istniejących bibliotek WordPressa, zwykle są znacznie szybsze i stabilniejsze niż rozbudowane page buildery.
Jak zadbać o zgodność bloków z przyszłymi wersjami WordPressa?
Kluczowe jest unikanie prywatnych, nieudokumentowanych API Gutenberga oraz oparcie się na oficjalnych pakietach @wordpress. Warto śledzić changelogi, testować bloki na wersjach beta oraz stosować migratory atrybutów przy większych zmianach. Dobrą praktyką jest także utrzymywanie minimalnej obsługiwanej wersji WordPressa i regularne aktualizowanie środowiska developerskiego.
Czy można tworzyć bloki bez Reacta, używając tylko PHP?
Możliwe jest tworzenie bloków dynamicznych renderowanych po stronie serwera, ale interfejs edycji w Gutenbergu opiera się na React. Całkowite pominięcie JS oznaczałoby rezygnację z wygodnych kontrolek i podglądu. W praktyce najlepiej zaakceptować cienką warstwę React/JS, skupiając logikę biznesową w PHP, jeśli czujesz się w nim pewniej; taki kompromis sprawdza się w wielu projektach.
601 162 666
