Otwórz ankietę dla autorów motywów WordPress na temat plików JSON i motywów blokowych

WordPress 5.8 wprowadził system opt-in dla motywów do konfiguracji ustawień bloków, stylów, szablonów i nie tylko. Odbywa się to za pomocą nowego pliku theme.json , który autorzy mogą umieścić w katalogu głównym swoich folderów motywów. Anne McCarthy, szefowa programu FSE Outreach Program, ogłosiła dzisiaj ankietę, aby uzyskać opinie od programistów na temat tej funkcji.

„Ponieważ ten nowy mechanizm jest wczesnym krokiem w kierunku kompleksowego systemu stylów dla przyszłości WordPressa, ważne jest, aby usłyszeć od wszystkich, którzy obecnie używają theme.json , aby dowiedzieć się więcej o tym, jak ludzie korzystają z tego narzędzia i co może być sensowne do włączenia w Core w przyszłości” – napisała w ogłoszeniu.

Ankieta jest otwarta dla wszystkich autorów motywów, którzy korzystali z theme.json , co daje im szansę na wstawienie wczesnych opinii i pomoc w kierowaniu statkiem w przyszłości.

Ponieważ pracowałem intensywnie z tym systemem w ciągu ostatnich kilku miesięcy, miałem kilka rzeczy do powiedzenia. Poza tym po prostu lubię brać udział w ankietach związanych z WordPressem. Zdecydowałem również, że będzie to okazja do podzielenia się niektórymi z moich niefiltrowanych przemyśleń z perspektywy rozwoju na temat obecnego stanu theme.json .

Poniżej znajdują się moje odpowiedzi na pytania ankiety — cóż, wersja uporządkowana.

Uwaga: jest to post skoncentrowany na programistach, który może nie przemawiać do wszystkich naszych czytelników. Próbowałem wyjaśnić niektóre rzeczy w przyjaznej dla użytkownika terminologii, ale może być konieczna pewna wstępna wiedza na temat tworzenia motywów.

Doświadczenie

Pierwsze pytanie ankiety jest dość stonowane. Pyta, jakie masz doświadczenia z motywami bloków konstrukcyjnymi lub używaniem theme.json . Zapewnia cztery opcje (i opcję „inną”):

• Zbudowałem i uruchomiłem motywy blokowe.
• Eksperymentowałem z motywami bloków konstrukcyjnych.
• Zbadałem używając theme.json z klasycznym motywem.
• Użyłem motywu blokowego, ale jeszcze go nie zbudowałem.

Wybrałem pierwszą opcję, ponieważ zbudowałem już dwa motywy blokowe dla rodziny i przyjaciół. Były to proste strony osobiste, które już utrzymuję za darmo — szczerze, muszę zacząć ładować . Pracuję również nad tematem, który mam nadzieję opublikować publicznie.

Jak to się zaczęło i jak leci

Drugie pytanie dotyczy tego, jak zacząć korzystać z motywów blokowych i theme.json . Do wyboru są między rozwidleniem istniejącego motywu, użyciem pustego motywu lub zaczynaniem od zera.

Ponownie, jest to jedna z tych rzeczy, w których eksperymentowałem z każdym kierunkiem, ale nie pamiętam dokładnego punktu wyjścia. Większość mojej pracy pochodzi z rozwidlenia tematu, nad którym ostatnio pracowałem w 2019 roku.

Planuję wydać to jako nowy motyw za darmo w pewnym momencie. Przeważnie czekam na:

• Opracowanie bloku nawigacyjnego, aby się uspokoić
• Blok autora posta, który zostanie podzielony na mniejsze bloki
• Solidny zestaw bloków związanych z komentarzami
• Blok opublikuj polecany obraz, aby mieć opcję rozmiaru

Myślę, że mógłbym realistycznie wydać wersję beta mojego motywu do użytku na własne ryzyko, gdyby te elementy zostały rozwiązane.

Szablony i części szablonów

W ankiecie zapytano, które szablony i motywy części szablonów zawsze zawierają w swoich motywach blokowych. Znajdowało się tam pole komentarza o dowolnej formie — kroki na mydelniczce…

W tej chwili mam związek miłości/nienawiści z szablonami blokowymi. Statyczny charakter szablonów HTML przypomina mi prostsze czasy, kiedy tworzenie motywów było mniej skomplikowane. Stanowi to jednak również problem w systemie dynamicznym.

Nie pamiętam, kiedy ostatnio zbudowałem tradycyjny motyw oparty na PHP z więcej niż jednym szablonem najwyższego poziomu: index.php . Dynamiczne kawałki zawsze były wnętrznościami, które są częściami szablonowymi. Dzięki PHP łatwo jest ustawić jakąś zmienną lub użyć wywołania funkcji do kontekstowego załadowania części szablonów niezbędnych dla dowolnej strony, którą użytkownik aktualnie przegląda w witrynie.

System szablonów bloków nie działa w ten sposób. Zasadniczo zmusza deweloperów do złamania zasady Don't Repeat Yourself (DRY).

Na przykład, jeśli projektant chciałby wyświetlić inną część szablonu nagłówka dla stron i postów, musiałby tylko utworzyć szablon header-page.php lub header-post.php w tradycyjnych motywach. Jednak ponieważ system szablonów bloków jest inny, muszą teraz utworzyć dwa szablony najwyższego poziomu, single.html (post) i page.html , aby osiągnąć to samo.

Jest to „zła rzecz”, ponieważ autorzy motywów muszą powielać cały pozostały kod w każdym z szablonów najwyższego poziomu. Nie ma możliwości kontekstowego załadowania różnych części szablonu.

Odpowiadając na pytanie: z konieczności używam prawie wszystkich możliwych szablonów najwyższego poziomu.

Odpowiedziałem również na drugą część pytania i wymieniłem najczęściej używane części szablonu (w podziale na hierarchię):

• nagłówek
• Zawartość
  - Pętla
  - Pasek boczny
• Stopka

Części szablonu content-*.html i loop-*.html to te, które mają najwięcej odmian.

Definiowanie kolorów

W następnej części ankiety zapytano, jak autorzy motywów definiują swoje slugi palety kolorów w theme.json . Wierzcie lub nie, ale nazewnictwo kolorów może być od lat najbardziej kontrowersyjnym tematem w świecie motywów. Jedyne dwie ogólnie uzgodnione rzeczy to kolory „tła” i „pierwszego planu”.

Morten Rand-Hendriksen otworzył bilet w 2018 r. za ujednolicenie schematu nazewnictwa motywów kolorystycznych. Nie była to pierwsza i nie ostatnia dyskusja. Problemem, który miał rozwiązać, były slugi kolorów w systemie, czyli sposób, w jaki motywy definiują swoje palety. Gdy użytkownik użyje wstępnie ustawionego koloru, ślimak jest na stałe zakodowany w jego treści. Przełącz się na inny motyw z różnymi ślimakami, a stare kolory znikną i nie zmienią się automatycznie na kolory nowego motywu.

Używam nazw semantycznych, które podążają za czymś, co bardzo przypomina system cieniowania frameworka Tailwind CSS. Zamiast red-medium (opisowy), użyłbym na przykład primary-500 (semantycznego). Podejście semantyczne umożliwiłoby autorom motywów zdefiniowanie zestawu kolorów, które są aktualizowane za każdym razem, gdy użytkownik przełącza motyw.

Oczywiście istnieją inne szkoły myślenia i nawet każdy, kto woli nazewnictwo semantyczne, nie zgadza się na ten sam system. Opisałem moje podejście bardziej szczegółowo w nowszym bilecie GitHub i mam plik theme.json dla innych, którzy mogą chcieć go wypróbować.

Inne ustawienia motywu JSON

Poza kolorami i typografią w ankiecie pyta się, z jakich innych motywów ustawień korzystali autorzy. To kolejny scenariusz, w którym zazwyczaj używam wszystkiego — jeśli jest na to opcja, to ją definiuję.

Jednym z przypadków użycia, dla którego WordPress nie ma obecnie ustawienia wstępnego, jest odstęp globalny. Większość autorów motywów używa jednej wartości dla większości marginesów pionowych (spacji między blokami i elementami). Jest również często używany do domyślnego dopełnienia pionowego i poziomego.

Nie jestem pewien, czy potrzebuję ustawienia wstępnego, ponieważ nie wiem, w jaki sposób WordPress go użyje. Jest to coś, o co prosili inni i jest prawie wszechobecne w użyciu. Zdefiniowanie całego systemu wokół niego może spowodować ból głowy, ale nadal chciałbym zobaczyć dyskusję na temat implementacji przynajmniej standardowego ustawienia globalnych odstępów.

Ustawienia i style poszczególnych bloków

Ta sekcja ankiety była pytaniem tak/nie, pytającym po prostu, czy autorzy motywów uwzględnili ustawienia lub style poszczególnych bloków w swoich plikach theme.json . Oczywiście zostawiłem kilka dodatkowych komentarzy później w sekcji komentarzy opcjonalnych.

Jestem zadowolony z systemu, jeśli chodzi o ustawienia, które pozwalają motywom określić, które funkcje są włączone globalnie lub na podstawie bloku. Jednak nie jestem sprzedany na dodawanie stylów za pośrednictwem theme.json .

Pisanie CSS w JSON, zasadniczo to, o czym mówimy, wydaje się niewłaściwe na tak wielu poziomach. Obecnie ogranicza się tylko do kilku konfigurowalnych stylów, więc wszystko poza tym i tak wymaga zagłębienia się w rzeczywisty plik CSS. Jest to problematyczne, ponieważ połowa kodu CSS motywu jest podzielona między theme.json i osobny plik CSS. Z punktu widzenia rozwoju sprawia, że ​​baza kodu jest trudniejsza w utrzymaniu.

Początkowo zacząłem ścieżkę konfigurowania stylów na blok i elementów z theme.json . Jednak od tego czasu przeniosłem stylizację z powrotem do plików CSS. Czuje się bardziej naturalnie i mam dodatkową korzyść ze wszystkich narzędzi, do których jestem przyzwyczajony. W tej chwili nie wyobrażam sobie scenariusza, w którym bym się cofnął.

Oprócz zapisania kilku bajtów kodu, nie widziałem wielu korzyści z dodawania stylów dla większości rzeczy za pośrednictwem JSON. Może to się zmieni w przyszłości i będę konwertytą. Na razie trzymam się głównie CSS.

Inne opinie: warstwa PHP

Mówiłem to już wcześniej, ale trzeba to powtórzyć. Potrzebujemy warstwy PHP dla tego systemu konfiguracji theme.json . Obecnie istnieje otwarty bilet na rozwiązanie tego problemu.

Taki system ma dwie główne zalety. Posiadanie API PHP do składania konfiguracji będzie znacznie bardziej naturalne dla tradycyjnych twórców motywów. Patrzę na to jak na gałązkę oliwną, okaz dobrej wiary, że programiści core/Gutenberg uznają, że wielu autorom motywów będzie miało łatwiejszy dostęp do funkcji FSE za pomocą znanego języka programowania.

Drugą zaletą jest to, że istnieje niezliczona liczba pomysłów na wtyczki do rozszerzenia globalnych stylów, edycji witryny i nie tylko, jeśli istnieje łatwy sposób na podłączenie się do systemu motywów JSON i nadpisanie rzeczy. Prosty haczyk na filtr sprawi, że będzie to bezbolesne.