Edytor blokowy Gutenberg całkowicie zmienił sposób pracy z treścią w WordPressie. Daje dużą swobodę wizualnej edycji, ale aby utrzymać spójność marki i wyglądu strony, warto zdefiniować własną paletę kolorów. Dzięki temu redaktorzy nie muszą ręcznie wpisywać kodów HEX czy RGB, a zamiast tego korzystają z gotowych, opisanych barw. Poniżej znajdziesz szczegółowy przewodnik, jak dodać własne kolory do Gutenberga krok po kroku, z uwzględnieniem różnych podejść i pułapek, których lepiej unikać.
Dlaczego warto dodać własne kolory do edytora Gutenberg
Gdy kilka osób pracuje nad treściami w WordPressie, bardzo łatwo o chaos wizualny. Jeden redaktor korzysta z przypadkowych odcieni niebieskiego, inny wybiera dowolną zieleń, a kolejny wstawia ręcznie kody kolorów z ulubionego generatora. Efekt końcowy na stronie jest daleki od założeń identyfikacji wizualnej i psuje odbiór całego projektu.
Dodając zdefiniowaną paletę barw w Gutenbergu, wprowadzasz jasne zasady: użytkownicy wybierają tylko te kolory, które zostały wcześniej zaprojektowane. Każdy odcień może otrzymać własną nazwę powiązaną z marką lub funkcją, na przykład kolor główny, akcentowy, kolor tła sekcji, kolor ostrzeżeń. Dzięki temu nawet osoba bez wiedzy graficznej szybko wie, który wariant zastosować.
Spójna paleta to nie tylko estetyka. Ma też duże znaczenie dla użyteczności i dostępności. Dobrze dobrane kontrasty pomiędzy tłem i tekstem ułatwiają czytanie i spełniają wymagania WCAG. Jeśli raz zaprojektujesz poprawny zestaw barw i zablokujesz możliwość użycia przypadkowych odcieni, minimalizujesz ryzyko tworzenia stron nieczytelnych dla części użytkowników.
Własne kolory w Gutenbergu wiążą się także z wygodą pracy. Zamiast za każdym razem wklejać kod koloru HEX, autor wybiera go jednym kliknięciem z listy. To przyspiesza przygotowanie treści, szczególnie gdy trzeba dodać kilka bloków z przyciskami, nagłówkami lub elementami dekoracyjnymi. Dobrze przygotowana paleta powinna obejmować kilka kluczowych kolorów oraz ich odcienie (ciemniejsze i jaśniejsze), tak aby można było zbudować czytelne hierarchie wizualne.
Nie można też zapominać, że Gutenberg jest stale rozwijany. Wykorzystanie oficjalnych mechanizmów dodawania kolorów (za pomocą motywu lub pliku konfiguracyjnego) zapewnia kompatybilność z kolejnymi wersjami edytora. Zamiast kombinować z własnymi panelami czy nietypowymi rozwiązaniami, korzystasz z wbudowanych opcji, które są wspierane przez społeczność i dokumentację WordPressa.
Dodawanie własnych kolorów przez functions.php i add_theme_support
Najbardziej klasyczna i wciąż bardzo popularna metoda tworzenia palety kolorów dla Gutenberga polega na użyciu funkcji add_theme_support w pliku functions.php motywu. Rozwiązanie to jest przejrzyste, stabilne i nie wymaga zaawansowanych narzędzi. Wystarczy mieć dostęp do plików motywu (przez FTP, SSH lub edytor w panelu administracyjnym) i rozumieć podstawowe zasady działania PHP w WordPressie.
Na początek warto przygotować listę kolorów, które mają być dostępne w edytorze. Każdy kolor powinien mieć zdefiniowany identyfikator, nazwę widoczną dla użytkownika oraz wartość HEX. Identyfikator będzie wykorzystywany w klasach CSS generowanych przez Gutenberga, a nazwa pojawi się w interfejsie edytora. Dzięki temu użytkownik wybiera z listy na przykład kolor Marka – Niebieski zamiast zgadywać po samym odcieniu.
Aby włączyć obsługę niestandardowej palety, otwórz plik functions.php w katalogu aktywnego motywu (lub motywu potomnego). Następnie w odpowiednim miejscu (najczęściej w funkcji inicjującej wsparcie dla motywu) dodaj fragment obsługujący editor-color-palette. Całość powinna być zawarta w funkcji podpiętej do akcji after_setup_theme, dzięki czemu WordPress załaduje ustawienia w odpowiednim momencie.
Przykładowa struktura w PHP może wyglądać następująco (bez znaków formatowania Markdown, aby łatwo było przenieść kod):
add_action( 'after_setup_theme’, 'moj_motyw_gutenberg_colors’ );
function moj_motyw_gutenberg_colors() {
add_theme_support( 'editor-color-palette’, array(
array(
'name’ => 'Niebieski marki’,
'slug’ => 'brand-blue’,
'color’ => '#0055ff’,
),
array(
'name’ => 'Pomarańczowy akcent’,
'slug’ => 'accent-orange’,
'color’ => '#ff7a00′,
),
array(
'name’ => 'Ciemne tło’,
'slug’ => 'dark-background’,
'color’ => '#111111′,
),
) );
}
Po zapisaniu pliku i odświeżeniu edytora blokowego, nowe kolory powinny pojawić się w panelu wyboru barwy w blokach, które wspierają konfigurację kolorystyczną (np. akapit, nagłówek, przycisk). Każdy zdefiniowany slug spowoduje również pojawienie się dodatkowych klas CSS w kodzie HTML generowanym przez Gutenberg. Przykładowo, dla koloru brand-blue edytor doda klasę has-brand-blue-color dla tekstu lub has-brand-blue-background-color dla tła elementu.
Kolejnym krokiem jest dopasowanie stylów frontendowych, aby wartości kolorów z edytora zgadzały się z wyglądem na stronie. W wielu przypadkach WordPress sam powiąże klasy z wartościami, jeśli korzystasz z pliku style.css lub stylów definiowanych w motywie blokowym. W innych projektach możesz chcieć dodatkowo dopracować niektóre elementy, na przykład dodać efekt hover dla przycisków używających konkretnego koloru. Wtedy w arkuszu stylów definiujesz reguły CSS odwołujące się do klas generowanych przez Gutenberga.
Warto też zadbać o to, aby nikt nie mógł dodawać dowolnych kolorów spoza palety. Można to osiągnąć wyłączając niestandardowy wybór kolorów przez funkcję add_theme_support z parametrem disable-custom-colors. W ten sposób panel edytora będzie pokazywał tylko przygotowaną przez ciebie paletę, co zwiększy spójność i kontrolę nad wizualną warstwą treści:
add_theme_support( 'disable-custom-colors’ );
Zachowanie porządku w pliku functions.php jest kluczowe, szczególnie gdy motyw rośnie i z czasem dochodzą kolejne funkcje. Dobrym zwyczajem jest wydzielenie konfiguracji edytora do osobnego pliku i załadowanie go przez require_once, aby uniknąć chaosu i trudności z utrzymaniem kodu. Dzięki temu zmiany w palecie kolorów wprowadzisz szybciej i bez ryzyka, że przypadkiem modyfikujesz fragment odpowiedzialny za inne części motywu.
Wykorzystanie theme.json do definiowania palety kolorów
Nowoczesne motywy blokowe coraz częściej opierają się na pliku konfiguracyjnym theme.json. To potężny mechanizm, który centralizuje ustawienia edytora i stylów, w tym także definicje kolorów. Jeśli tworzysz lub rozwijasz motyw przystosowany do Gutenberga, warto poznać tę metodę, bo ułatwia zarządzanie wyglądem i pozwala na bardziej rozbudowane scenariusze niż klasyczne add_theme_support.
Plik theme.json umieszcza się w katalogu motywu. Można w nim zdefiniować sekcję settings, w której znajduje się podsekcja color. To tutaj opisujesz paletę oraz zachowanie edytora w odniesieniu do kolorów. Struktura jest czytelna: każda barwa to obiekt z nazwą, slugiem i wartością. Dodatkowo możesz w prosty sposób wyłączyć niestandardowe kolory czy gradienty, co jeszcze bardziej kontroluje efekty pracy redaktorów.
Minimalny przykład konfiguracji kolorów w theme.json może wyglądać tak:
{
„version”: 2,
„settings”: {
„color”: {
„palette”: [
{
„name”: „Niebieski marki”,
„slug”: „brand-blue”,
„color”: „#0055ff”
},
{
„name”: „Szare tło”,
„slug”: „section-gray”,
„color”: „#f3f3f3”
}
],
„custom”: false
}
}
}
Parametr custom ustawiony na false blokuje możliwość wprowadzania dowolnych kolorów spoza palety. W nowszych wersjach WordPressa dostępne są również dodatkowe opcje, takie jak zarządzanie gradientami, ustawieniami tła czy automatycznym generowaniem zmiennych CSS. Dzięki temu raz zdefiniowana paleta może być wykorzystywana na wielu poziomach: w edytorze, w arkuszu stylów oraz przez motyw blokowy sterujący całym layoutem.
Plik theme.json ma jeszcze jedną ważną zaletę: umożliwia tworzenie palet globalnych i lokalnych. Paleta globalna dotyczy całej strony, natomiast w motywach blokowych można też definiować konfiguracje dla konkretnych bloków. Jeśli chcesz, by przyciski korzystały tylko z części kolorów, a inne były dostępne tylko dla nagłówków, możesz doprecyzować to w sekcji styles lub settings dla danego bloku. To poziom kontroli, który trudno osiągnąć klasycznymi metodami.
Korzystanie z theme.json sprzyja utrzymaniu porządku i dokumentowaniu projektu. Zamiast rozproszonych funkcji PHP, masz jedno źródło prawdy na temat palety, typografii, odstępów i innych parametrów. Zmiany wprowadzane w tym pliku są też stosunkowo bezpieczne, bo WordPress interpretuje konfigurację i generuje na jej podstawie odpowiednie style. Jeśli popełnisz błąd w strukturze JSON, dość szybko go zauważysz, a poprawka zwykle nie wymaga przekopywania wielu plików.
W praktyce wiele nowoczesnych motywów łączy obie metody: używa theme.json do ogólnej konfiguracji, a funkcji PHP tylko do bardziej specyficznych zadań. Jeśli dopiero zaczynasz pracę z Gutenbergiem i tworzysz nowy motyw, warto postawić na podejście oparte głównie na theme.json. Ułatwi to późniejszą rozbudowę, integrację z edytorem pełnej strony (Full Site Editing) oraz korzystanie z narzędzi takich jak Global Styles.
Stylowanie backendu i frontendu oraz klasy CSS Gutenberga
Samo zdefiniowanie palety kolorów to dopiero początek. Aby doświadczenie użytkownika było spójne, musisz zadbać zarówno o wygląd w edytorze (backend), jak i na stronie (frontend). Gutenberg generuje klasy CSS na podstawie slugów przypisanych do kolorów, a WordPress często troszczy się o podstawowe mapowanie barw. Jednak w bardziej złożonych projektach niezbędne jest ręczne dopracowanie stylów.
Kluczowym elementem są klasy postaci has-slug-color i has-slug-background-color, które edytor dodaje do odpowiednich bloków. Jeśli zdefiniujesz kolor o slugu brand-blue, pojawią się klasy has-brand-blue-color dla tekstu oraz has-brand-blue-background-color dla tła. W motywach opartych o theme.json WordPress tworzy na tej podstawie zmienne CSS i reguły, ale w klasycznych motywach bywa, że trzeba je uzupełnić w style.css, szczególnie gdy korzystasz z niestandardowych komponentów.
Przykładowe reguły mogą wyglądać tak:
.has-brand-blue-color {
color: #0055ff;
}
.has-brand-blue-background-color {
background-color: #0055ff;
}
Dodatkowo możesz tworzyć bardziej złożone efekty. Na przykład dla przycisków wykorzystujących określony kolor tła warto zdefiniować styl hover, aby lepiej sygnalizować interakcję użytkownika. Zrobisz to poprzez selektory łączące klasy Gutenberga z klasami bloków lub własnymi klasami motywu. To pozwala zachować rozpoznawalność kolorów marki przy jednoczesnym uwzględnieniu zasad użyteczności, takich jak wyraźne stany najechania i kliknięcia.
Backend to osobne wyzwanie. Użytkownik powinien w edytorze widzieć możliwie wierną kopię tego, jak treść zaprezentuje się na stronie. W motywach klasycznych często dodaje się osobny arkusz stylów dla edytora, za pomocą funkcji enqueue_block_editor_assets i pliku CSS z dopasowanymi kolorami. W tym pliku powielasz najważniejsze reguły kolorystyczne, aby podgląd bloków w Gutenbergu nie różnił się radykalnie od frontendu.
Przykładowy fragment funkcji w functions.php:
function moj_motyw_editor_assets() {
wp_enqueue_style(
'moj-motyw-editor-style’,
get_theme_file_uri( '/assets/css/editor-style.css’ ),
array(),
'1.0′
);
}
add_action( 'enqueue_block_editor_assets’, 'moj_motyw_editor_assets’ );
W pliku editor-style.css umieszczasz reguły dotyczące klas has-*-color i has-*-background-color, a także inne elementy stylistyczne istotne dla edytora. Dzięki temu autorzy treści widzą przybliżony efekt końcowy bez konieczności otwierania podglądu strony po każdej zmianie. Różnica pomiędzy backendem i frontendem zawsze w jakimś stopniu pozostanie, ale im bardziej zbliżysz je do siebie, tym mniejsza frustracja osób pracujących z Gutenbergiem.
Warto także pamiętać o testach na różnych blokach. Nie wszystkie komponenty Gutenberga reagują na kolory w ten sam sposób. Niektóre bloki umożliwiają jedynie zmianę koloru tła, inne pozwalają modyfikować zarówno tekst, jak i obramowanie, a jeszcze inne mają własne, bardziej rozbudowane ustawienia stylów. Po dodaniu palety dobrze jest przejść przez kluczowe bloki (akapit, nagłówek, przycisk, kolumny, listy, cytaty) i sprawdzić, czy wszystko zachowuje się zgodnie z oczekiwaniami.
Najczęstsze problemy i dobre praktyki przy pracy z kolorami w Gutenbergu
Dodając własne kolory do edytora, łatwo natknąć się na typowe trudności. Jednym z najczęstszych problemów jest sytuacja, w której paleta pojawia się w edytorze, ale nie działa poprawnie na stronie. Powodem bywa brak odpowiednich reguł CSS na froncie lub konflikt z innymi stylami motywu lub wtyczek. W takich przypadkach warto skorzystać z narzędzi deweloperskich przeglądarki, sprawdzić klasy przypisane do elementu i prześledzić, które reguły CSS faktycznie decydują o jego wyglądzie.
Inny problem to zbyt rozbudowana paleta. Gdy użytkownik ma do wyboru kilkadziesiąt kolorów, trudno zachować porządek. Lepiej przygotować kilka kluczowych barw oraz ich logiczne odmiany (jaśniejszą, ciemniejszą, delikatny wariant tła) niż zasypywać autora niezliczonymi możliwościami. Paleta powinna wynikać z identyfikacji wizualnej marki, projektu graficznego i założeń dotyczących dostępności, a nie z przypadkowych inspiracji.
Dobrą praktyką jest nadawanie kolorom opisowych nazw. Zamiast ogólnych określeń w stylu Niebieski 1, Niebieski 2, zastosuj oznaczenia powiązane z funkcją: Link podstawowy, Tło sekcji jasne, Tło ostrzeżenia, Nagłówek akcent. Ułatwi to pracę osobom, które nie pamiętają wszystkich szczegółów identyfikacji wizualnej, a jednocześnie pozwoli uniknąć nadmiernych eksperymentów wizualnych.
Warto także od początku uwzględnić zasady dostępności. Kontrast pomiędzy tekstem a tłem powinien być wystarczający, aby osoby ze słabszym wzrokiem mogły swobodnie czytać treści. Możesz skorzystać z narzędzi online sprawdzających kontrast i na ich podstawie dobrać odpowiednie pary kolorów. Następnie w dokumentacji projektu zaznacz, które kombinacje są rekomendowane (np. ciemny tekst na jasnym tle) i postaraj się, aby to właśnie te pary były najłatwiejsze do wybrania w edytorze.
Przy większych serwisach lub sklepach internetowych dobrym rozwiązaniem jest stworzenie mini przewodnika dla redaktorów, w którym opiszesz, jak używać przygotowanej palety. Można to zrobić w formie wpisu w dokumentacji wewnętrznej, prostego PDF-a lub strony w panelu administracyjnym. Wskazanie typowych zastosowań (kolor tła sekcji hero, kolor przycisku głównego, kolor wyróżnionych nagłówków) znacznie zwiększa szansę, że narzędzia Gutenberga zostaną właściwie wykorzystane.
Nie zapominaj też o wpływie aktualizacji. Zmiana koloru w palecie może mieć konsekwencje dla już istniejących treści. Jeśli na przykład zmienisz wartość HEX przypisaną do slug brand-blue, wszystkie elementy na stronie korzystające z tego koloru automatycznie się zaktualizują. To zaleta, gdy chcesz odświeżyć identyfikację, ale także potencjalne zagrożenie, jeśli nie przetestujesz wystarczająco dobrze nowej wersji kolorystyki. Zawsze wykonuj kopię zapasową i testuj zmiany na środowisku deweloperskim.
Alternatywy: wtyczki, motywy potomne i migracja istniejących stron
Nie zawsze masz możliwość swobodnej edycji plików motywu. Jeśli korzystasz z gotowego szablonu, który nie udostępnia łatwej konfiguracji kolorów w Gutenbergu, możesz rozważyć inne ścieżki. Jedną z nich jest utworzenie motywu potomnego. Dzięki temu nie ingerujesz bezpośrednio w pliki motywu nadrzędnego, a wszystkie własne zmiany wprowadzisz w osobnej strukturze, bez ryzyka ich nadpisania przy aktualizacjach.
Motyw potomny pozwala dodać własny plik functions.php oraz theme.json, w których skonfigurujesz paletę kolorów. Dziedziczysz przy tym większość wyglądu i funkcjonalności motywu nadrzędnego. To rozwiązanie szczególnie wygodne, jeśli chcesz stopniowo rozbudowywać projekt i dodawać kolejne elementy dopasowane do potrzeb klienta lub redakcji. W ten sposób tworzysz własną warstwę nad gotowym szablonem, ale z zachowaniem jego stabilności.
Inną możliwością są wtyczki rozszerzające panel Gutenberga o dodatkowe opcje kolorystyczne. Istnieją rozwiązania, które pozwalają definiować własne palety przez interfejs w panelu administracyjnym, bez konieczności edycji kodu. To kuszące podejście, ale warto podchodzić do niego ostrożnie. Zależność od wtyczki oznacza, że w razie jej porzucenia lub konfliktów z innymi elementami strony możesz mieć problem z utrzymaniem spójności kolorów.
Przy migracji istniejących stron na Gutenberga sytuacja bywa bardziej złożona. Jeśli wcześniej korzystałeś z klasycznego edytora lub rozbudowanego page buildera, definicje kolorów mogły być rozsiane po różnych częściach motywu, shortcode’ach czy modułach. W takim wypadku warto zacząć od audytu obecnej kolorystyki, spisania wszystkich wykorzystywanych barw i ich ról, a następnie przeniesienia ich do ujednoliconej palety Gutenbergowej. W trakcie migracji możesz też uprościć schemat barw, usuwając duplikaty i nieużywane odcienie.
W projektach, w których rozwój odbywa się etapami, często stosuje się rozwiązanie hybrydowe. Część treści nadal korzysta ze starych mechanizmów (np. page buildera), a nowe podstrony tworzone są już w Gutenbergu z użyciem zdefiniowanej palety. W takim przypadku szczególnie ważne jest, aby kolory były zbieżne wizualnie, nawet jeśli technicznie pochodzą z różnych źródeł. Możesz wtedy odtworzyć najważniejsze barwy dawnego systemu w nowej palecie i stopniowo przenosić kolejne sekcje serwisu.
Podsumowanie korzyści z pracy na własnej palecie kolorów
Starannie przygotowana paleta kolorów zintegrowana z Gutenbergiem to inwestycja, która szybko się zwraca. Strona zyskuje spójny i profesjonalny wygląd, a redaktorzy mają do dyspozycji proste w obsłudze narzędzie, które prowadzi ich przez proces tworzenia treści. Zamiast walczyć z przypadkowo dobranymi barwami, mogą skupić się na merytorycznej warstwie wpisów i podstron.
Wprowadzenie palety poprzez functions.php lub theme.json zwiększa kontrolę nad projektem i ułatwia wprowadzanie zmian w przyszłości. Dzięki slugom i klasom CSS masz pełny wpływ na wygląd elementów na froncie, a odpowiednie style dla edytora zapewniają realistyczny podgląd w panelu administracyjnym. Dodając do tego dobre praktyki związane z dostępnością, dokumentacją i testowaniem, tworzysz środowisko pracy wygodne zarówno dla projektantów, jak i autorów treści.
Niezależnie od tego, czy budujesz mały blog, rozbudowany portal czy serwis firmowy, własna paleta kolorów w Gutenbergu powinna stać się jednym z pierwszych kroków podczas konfiguracji motywu. To fundament, na którym opierasz całą wizualną narrację marki. Dobrze dobrane barwy porządkują strukturę strony, wspierają czytelność i wzmacniają skojarzenia z marką, a jednocześnie redukują liczbę błędów popełnianych przez osoby odpowiedzialne za publikowanie treści.
FAQ
Jak dodać własne kolory do Gutenberga bez edycji plików motywu?
Możesz skorzystać z wtyczek umożliwiających definiowanie palety kolorów z poziomu panelu administracyjnego. Takie rozwiązanie jest wygodne, gdy nie masz dostępu do plików przez FTP lub nie czujesz się pewnie w edycji kodu. Pamiętaj jednak, że uzależniasz projekt od wtyczki, więc wybieraj rozwiązania dobrze wspierane i aktualizowane.
Czy zmiana kolorów w palecie wpłynie na już opublikowane treści?
Tak, jeśli zmodyfikujesz wartość koloru przypisaną do konkretnego sluga, wszystkie bloki używające tego koloru zostaną zaktualizowane. To zaleta, gdy odświeżasz identyfikację wizualną, ale wymaga dokładnych testów. Zawsze przeglądaj kluczowe podstrony po wprowadzeniu zmian i wykonuj kopie zapasowe, aby w razie potrzeby szybko wrócić do poprzedniej wersji.
Czy warto blokować możliwość wyboru dowolnych kolorów w Gutenbergu?
W większości profesjonalnych projektów to dobre podejście. Ograniczenie palety do wcześniej zaprojektowanych kolorów pomaga utrzymać spójność i zgodność z identyfikacją wizualną. Włączenie opcji disable-custom-colors lub custom: false w theme.json sprawia, że redaktorzy nie dobierają losowych barw, co zmniejsza ryzyko chaotycznego wyglądu strony.
Jak zadbać o dostępność przy definiowaniu kolorów w edytorze?
Przede wszystkim sprawdź kontrast pomiędzy kolorem tekstu a tłem przy użyciu narzędzi online zgodnych z wytycznymi WCAG. Unikaj par o niskim kontraście (np. jasnoszarego tekstu na jasnym tle). W palecie wyraźnie oznacz kolory przeznaczone do tekstu i te do tła. Jeśli to możliwe, przygotuj dokument z rekomendowanymi kombinacjami dla redaktorów.
Czy theme.json zastępuje całkowicie functions.php przy dodawaniu kolorów?
W motywach blokowych theme.json jest podstawowym sposobem definiowania palety i innych ustawień edytora, ale nie wyklucza użycia functions.php. Możesz korzystać z obu podejść równolegle, np. theme.json do konfiguracji kolorów, a funkcji PHP do ładowania dodatkowych stylów czy skryptów. Ważne, aby unikać duplikowania tych samych ustawień w dwóch miejscach.
601 162 666