Dlaczego nie budujemy stron WordPress na starter themes i wybieramy własny framework

Framework, na którym pracujemy, jest teraz dostępny na licencji open source. Zobacz, jak rozwijamy CHISEL, narzędzie, z którego korzystamy na co dzień.

Kiedyś każdy projekt WordPress zaczynał się tak samo, od budowania fundamentów, które składaliśmy już kilkanaście razy. Siadałeś, żeby coś stworzyć, a pierwszy poranek spędzałeś na walce z konfiguracją builda. Zanim wszystko zadziałało, mijała połowa dnia, a strona wciąż była pusta.

Stracone godziny to jedno, ale prawdziwy problem dotyczył całego zespołu. Każdy konfigurował projekt trochę inaczej, więc żadne dwa nie wyglądały tak samo, a przejście z jednego do drugiego oznaczało szukanie od nowa, gdzie co leży. Testowaliśmy dostępne wtedy starter themes, ale albo nie pasowały do naszego sposobu pracy, albo były tak skomplikowane, że generowały więcej pracy, niż oszczędzały. Które dokładnie, po dekadzie trudno sobie przypomnieć, ale wniosek został. Zbudowaliśmy własne rozwiązanie, czyli jedną wspólną strukturę, jeden zestaw konwencji i gotowy punkt startowy zamiast pustego folderu. Dzięki temu czas programisty idzie na to, za co klient faktycznie płaci. Nazwaliśmy go CHISEL.

Dziś to framework open source. Budujemy na nim w xfive, korzystają z niego także zespoły spoza naszej firmy, a my wciąż go rozwijamy.

CHISEL jest fundamentem każdego projektu, w którym zajmujemy się tworzeniem stron WordPress, od nowych serwisów po migracje i rozbudowę istniejących platform.

Czego nauczyło nas dziesięć lat

Większość wniosków z tych dziesięciu lat dotyczy nie tyle samego WordPressa, ile tego, jak pracują zespoły i jak oprogramowanie się starzeje.

Programista, który dziesiątki razy budował na tym samym fundamencie, przestaje o nim myśleć

Ta sama struktura folderów, te same komponenty Twig i ten sam sposób podłączania stylów i bloków w każdym projekcie. Nic się nie zmienia między wdrożeniami, więc nikt nie musi uczyć się tego od nowa. Nowy programista jest produktywny już po kilku dniach, bo drugi projekt wygląda dokładnie tak jak pierwszy.

Każdy nowy projekt otwierał tę samą dyskusję o nazewnictwie i strukturze

Nazewnictwo, strukturę plików, wzorce dla problemów powtarzających się w każdym projekcie i standardy kodowania ustaliliśmy raz, na poziomie frameworka, a ich pilnowanie oddaliśmy narzędziom. Lintery i pre-commit hook sprawiają, że każdy projekt wygląda tak samo, niezależnie od tego, kto go pisał. Nikt na starcie nie wraca do sporów o nazwy klas czy układ folderów, a raz poprawnie ustawione zasady zostają na stałe.

CHISEL jest w całości nasz

Cały framework opiera się na jednej zależności uruchomieniowej, Timber. Porzucona przez twórców wtyczka nie może dyktować nam kierunku rozwoju. Kiedy WordPress przeszedł na bloki, mogliśmy sami przebudować całą warstwę renderowania, zamiast czekać, aż zrobi to ktoś inny (więcej o tym niżej). Klienci dostają spójny produkt zbudowany na narzędziu, które aktywnie rozwijamy i nie zamierzamy porzucać.

Praca nigdy się nie kończy, a „nadążanie” ciągle znaczy coś innego

Dziesięć lat temu nadążanie oznaczało porządny proces budowania i rozsądny sposób pisania CSS. Potem przebudowę pod edytor blokowy. Ostatnio oznacza własną warstwę CHISEL do pracy z AI. Narzędzie, które przestaje się rozwijać, w końcu staje się czymś, co budzi pytania u wszystkich. CHISEL nigdy nie był „skończony” i po dziesięciu latach przestaliśmy tego oczekiwać.

CHISEL, nowoczesny framework WordPress

CHISEL to nowoczesny framework do tworzenia stron WordPress, dostępny jako pakiet npm.

Jedno polecenie tworzy kompletny projekt (starter theme oparty na Timberze, nowoczesny pipeline budowania i nasze standardy kodowania), więc od pierwszego dnia budujesz funkcje, a nie kładziesz fundamenty.

Oddzielenie szablonów od logiki

Timber i Twig pozwalają nam oddzielić logikę od warstwy prezentacji, dzięki czemu szablony nie zamieniają się w plątaninę HTML i PHP. Szablon zawiera wyłącznie znaczniki i dane, które do niego trafiają.

‍{# views/components/post-item.twig #}
<article class="post-item">  
  <h2 class="post-item__title">{{ post.title }}</h2>  
  <div class="post-item__excerpt">{{ post.preview }}</div>  
  <a class="post-item__link" href="{{ post.link }}">Read more</a>
  </article>

Logika przygotowująca wpis jest w PHP, z dala od warstwy prezentacji.

Organizacja CSS i design tokeny

Style organizujemy według metodologii ITCSS (Inverted Triangle CSS) i korzystamy z nowoczesnych funkcji Sass, takich jak @use i @forward. Design tokeny są w pliku theme.json. Kolory, odstępy i rozmiary czcionek definiujemy raz, a helpery Sass, takie jak get-margin('large') czy get-font-size('small'), pobierają je bezpośrednio stamtąd. Wartości nie dublują się między konfiguracją edytora a arkuszami stylów, a token nie rozjedzie się niezauważenie.

Pipeline budowania

Build to hybrydowa konfiguracja, która łączy własny config Webpacka z oficjalnym pakietem @wordpress/scripts. Obejmuje bundlowanie JS i SCSS z hot reloadem, linting obu, hashowane i wersjonowane zasoby statyczne oraz wsparcie dla Reacta od razu po instalacji. Całość jest gotowa do pracy z Dockerem, więc nowy programista uruchamia spójne środowisko lokalne bez całego dnia konfiguracji.

Powtarzalną pracę przejmuje CHISEL

Duża część pracy z WordPressem to powtarzalne podłączanie elementów. Większość z tego CHISEL robi za ciebie.

• Automatyczna rejestracja bloków (natywnych i ACF), custom post types, stron opcji ACF oraz zasobów i skryptów.
• Watcher synchronizujący grupy pól ACF. Zmiany zatwierdza programista, więc nic nie wchodzi bez ostrzeżenia.
• Endpointy REST API dla zapytań AJAX, dzięki którym wywołania asynchroniczne nie muszą przechodzić przez cięższą, starszą ścieżkę wp_ajax, oraz helpery fetch, które upraszczają te wywołania.
• Gotowe komponenty, funkcje użytkowe i pomocnicze oraz własne hooki akcji i filtrów, na których można budować dalej.
• Podstawowe integracje z wtyczkami, z których korzystamy najczęściej, takimi jak Yoast, WPML i Gravity Forms, a także wsparcie dla WooCommerce i skonfigurowane skrypty startowe, na przykład Swiper.

Żadna z tych rzeczy nie jest egzotyczna. To elementy, których potrzebuje każdy projekt, zrobione dobrze i za każdym razem tak samo.

Razem z WordPressem, nie wbrew niemu

Najważniejsza decyzja architektoniczna CHISEL to rozwijanie go w tym samym kierunku co WordPress, zamiast wytyczania osobnej ścieżki. Framework korzysta z aktualnych wersji WordPressa, stawia na budowanie z bloków i obsługuje zarówno natywne bloki Gutenberga, jak i bloki ACF. Kiedy WordPress się zmienia, CHISEL idzie za nim. Dzięki temu pozostaje aktualny i nie zamienia się powoli w prywatny dialekt, który rozumiemy tylko my.

Ta decyzja ma swoją cenę. W pewnym momencie musieliśmy gruntownie przebudować CHISEL, żeby dopasować go do kierunku, w którym poszedł WordPress. Ten etap nazywamy dziś CHISEL 2.

W Japonii stoi chram Ise Jingū, który co dwadzieścia lat celowo rozbiera się i buduje od nowa, żeby rzemiosło przechodziło na kolejnych cieśli, zamiast odchodzić razem z poprzednimi. Nie planowaliśmy CHISEL 2 w ten sposób, ale efekt był ten sam. Osoby, które dziś rozwijają framework, to nie te same osoby, które go napisały, a przebudowa warstwy renderowania była dla nich sposobem, żeby naprawdę go poznać.

Na początku CHISEL miał tę samą słabość co większość starter themes. Po wygenerowaniu projektu jego fundament był zamrożony, a późniejsze ulepszenia frameworka nie trafiały do już zbudowanych stron. Przebudowa w CHISEL 2 rozwiązała i ten problem. Wprowadziła dwupoziomową strukturę, która oddziela rdzeń frameworka od warstwy projektu. Pre-commit hooki chronią pliki rdzenia przed przypadkową edycją, więc istniejący projekt można zaktualizować do nowszej wersji bez nadpisywania własnych zmian. Kod jest obiektowy, dlatego jego rozbudowa jest prosta, a nie jest walką z frameworkiem.

CHISEL i Full Site Editing (FSE)

CHISEL nie jest motywem Full Site Editing (FSE) i to świadoma decyzja.

Framework stosuje podejście hybrydowe. Bierze z ery bloków to, co naprawdę pomaga, czyli theme.json jako jedno źródło design tokenów, wzorce bloków i edytor blokowy do zarządzania treścią. Nie oddaje jednak całej strony w ręce Site Editora. Granica przebiega między strukturą a treścią. Szablony, które w FSE można by edytować w Site Editorze, zostają w uporządkowanym Twigu pod kontrolą programisty, więc projekt graficzny zachowuje swój kształt. Treść stron, wpisów i custom post types redakcja buduje z bloków, które może swobodnie dodawać i przestawiać.

To wniosek z doświadczenia. Większość projektów klienckich nie potrzebuje pełnego FSE. Potrzebuje czytelnego i intuicyjnego panelu do zarządzania treścią, szablonów zgodnych z zaakceptowanymi projektami i konfiguracji, którą trudno przypadkiem zepsuć. Full Site Editing zamienia tę kontrolę na elastyczność, z której większość klientów nigdy nie korzysta, a właśnie przez nią projekt często niezauważenie odchodzi od specyfikacji. Dlatego na razie CHISEL stawia na przewidywalność. Pełne wsparcie FSE jest w naszej roadmapie jako opcja, którą będzie można włączyć, gdy projekt naprawdę tego będzie wymagał.

Dokąd zmierza CHISEL

Z tego samego powodu CHISEL jest dziś fundamentem naszej pracy z agentami AI. Zbudowaliśmy na nim zestaw narzędzi AI, który uczy agenta naszych konwencji i pozostawia programistę w centrum procesu. To jednak temat na osobny artykuł.

[dodane] Więcej o tym, jak wsparcie AI w CHISEL przyspiesza pracę nad projektami WordPress, piszemy w artykule o AI-assisted WordPress development (link: wersja PL artykułu o AI w CHISEL).

CHISEL nadal jest naszym punktem wyjścia do budowania szybkich stron WordPress, które łatwo utrzymać. Doskonali go każdy kolejny projekt i ponad dziesięć osób, które współtworzyły go przez lata. To właśnie ta mieszanka, dekada zebranego i przedyskutowanego doświadczenia zamiast preferencji jednej osoby, sprawia, że można mu ufać. Jest też open source, więc może z niego korzystać każdy, nie tylko my. Przejrzyj kod, zrób forka, a jeśli ci się spodoba, gwiazdka na GitHubie zawsze nas ucieszy.

‍