Tworzenie motywów Gatsby dla stron internetowych opartych na WordPress

Gatsby to platforma typu open source zbudowana na bazie React. Dzięki Gatsby możesz pobierać dane z (prawie) z dowolnego miejsca i używać ich do generowania statycznych lub dynamicznych stron internetowych. Dane można pobrać z CMS, co zdecydowanie przenosi WordPressa do tabeli. Zyskujesz zalety statycznej strony internetowej (szybkość, bezpieczeństwo, statyczny hosting), kontynuując zarządzanie treścią za pośrednictwem pulpitu WordPress.

Jedną ze szczególnych cech frameworka Gatsby jest to, że proponuje motywy jako narzędzie do dostosowywania. Jako osoba z silnym doświadczeniem w WordPressie uważam, że koncepcja motywów Gatsby jest szczególnie atrakcyjna. Kiedyś projektowałem i rozwijałem motywy WordPress. Jednak wraz z rosnącym zainteresowaniem rozwiązaniami Jamstack, stopniowo przestawiłem się na pracę z WordPressem jako bezgłowym CMSem. W tym artykule chciałbym podzielić się niektórymi koncepcjami, których nauczyłem się podczas tego przejścia.

Uwaga: Zanim przejdziemy dalej, skupmy się na narzędziach, z których będziemy korzystać. Gatsby udostępnia oficjalną wtyczkę gatsby-source-wordpress. Aby to zadziałało, musimy przygotować naszą końcówkę WordPress. Dokładniej, musimy ujawnić dane WordPress o smaku Gatsby'ego za pośrednictwem interfejsu API GraphQL. W praktyce oznacza to zainstalowanie dwóch wtyczek WordPress WPGraphQL i WPGatsby. Oba są dostępne za pośrednictwem oficjalnego repozytorium wtyczek WordPress i nie wymagają żadnej konfiguracji.

Czym są motywy Gatsby?

Motyw Gatsby to zbiór wspólnych funkcjonalności wyodrębnionych w pakiecie Node.js. Motyw jest zatem przeznaczony do opublikowania (w rejestrze, takim jak npm) i ponownego użycia jako instalowalna zależność.

Ponieważ mówimy tutaj o Gatsby i WordPress , wyjaśnię to od razu — istnieją podobieństwa z motywami WordPress, ale nie powinniśmy utożsamiać pojęcia motywów WordPress z motywami Gatsby. Dla kogoś, kto ma doświadczenie w WordPressie (tak jak ja), dysocjacja może być trudna na początku.

Motyw WordPress to obowiązkowy system szablonów, który definiuje to, co widzimy na interfejsie. Tutaj kończy się odpowiedzialność dobrego motywu WordPress. Nie powinien wprowadzać żadnych funkcjonalności, ponieważ funkcjonalności są terytorium wtyczek. W ekosystemie WordPressa istnieje zatem ścisła separacja między motywami a wtyczkami. Motywy powinny dbać o warstwę prezentacyjną, a wtyczki o aspekty funkcjonalne.

Zgodnie z definicją Gatsby’ego za funkcjonalności odpowiadają motywy . Czy nie powinniśmy więc nazywać ich wtyczkami? W rzeczywistości Gatsby, podobnie jak WordPress, ma zarówno wtyczki, jak i motywy. Wtyczki, podobnie jak motywy, są instalowalnymi pakietami Node.js, które implementują interfejsy API Gatsby. W rzeczywistości motyw Gatsby to wtyczka Gatsby. Jeśli wtyczka jest właścicielem sekcji, strony lub części strony w witrynie — nazywamy to motywem.

Co więcej, w przeciwieństwie do WordPressa, Gatsby nie wymaga używania motywów do budowy strony. Zamiast tego prawdopodobnie zacząłbyś tworzyć swoją witrynę, konfigurując projekt o następującej strukturze:

To jest w porządku, dopóki nie będziesz mieć więcej niż jednej witryny do utrzymania. W takim przypadku możesz wyodrębnić wspólne części procesu i zarządzać nimi (wersją i aktualizacją) oddzielnie.

Dzięki systemowi motywów Gatsby możesz łączyć współdzielone części w pakiet (lub wiele pakietów), publikować pakiety i na koniec instalować je w wielu aplikacjach. Zauważ, że użyłem pakietów w liczbie mnogiej — możesz łączyć wiele motywów w ramach projektu.

Motywy potomne i cieniowanie

Pracując z Gatsby i WordPress, zidentyfikujesz kilka podstawowych funkcji, które są wspólne dla wszystkich projektów. Mam tu na myśli: pozyskiwanie danych i dynamiczne budowanie stron. Wydaje się, że warto mieć motyw, który zajmie się logiką pozyskiwania danych i tworzenia stron. Z drugiej strony sposób, w jaki zdecydujesz się wyświetlać swoje strony, może się zmieniać w zależności od projektu. Cokolwiek ustawisz na poziomie podstawowym, prawdopodobnie w pewnym momencie będziesz musiał zmienić ustawienia.

Jednym z możliwych podejść jest posiadanie głównego motywu (rodzica) i budowanie motywów potomnych na głównym motywie.

Co rozumiem przez motyw potomny Gatsby'ego?

Przejdźmy do porównania motywów potomnych WordPress. Motywy potomne WordPressa pozwalają nam dodawać funkcjonalności i zastępować szablony. Zapewniają bezpieczny sposób ulepszania i modyfikowania istniejącego motywu.

Motyw potomny Gatsby używa motywu nadrzędnego jako wtyczki. Możemy wtedy użyć koncepcji tworzenia cienia, która daje motywowi potomnemu możliwość nadpisania plików motywu rodzica; jest to podobne do zastępowania szablonów WordPress w motywie potomnym. Shadowing oznacza, że ​​możemy nadpisać pliki z katalogu src zawartego w pakiecie webpack. Warto podkreślić, że shadowing jest możliwy na poziomie projektu (gdzie wykorzystujemy nasze motywy jako pakiety). Zobaczymy to w akcji w dalszej części tego artykułu.

W WordPressie jesteśmy ograniczeni tylko do jednego motywu nadrzędnego, tylko jednego motywu potomnego i dalsze łączenie nie jest możliwe. Dzięki elastyczności motywów Gatsby możemy pójść znacznie dalej. Możliwe jest zbudowanie różnych konfiguracji łańcuchów podrzędnych-rodzicowych.

Zobaczmy teraz motyw Gatsby w akcji. W naszym przykładzie zbudujemy dwa motywy, gatsby-theme-wp-parent i jego motyw potomny gatsby-theme-wp-child . Wybrałem tę konfigurację ze względu na prostotę. W rzeczywistym scenariuszu możesz chcieć rozłożyć swoje funkcje na więcej tematów, z których każdy ma określoną odpowiedzialność.

Opublikujemy nasze motywy, zainstalujemy je w projekcie i dodamy dalsze dostosowania za pomocą shadowingu na poziomie projektu.

Konfiguracja rozwoju

Ostatnia ilustracja przedstawia strukturę projektu użytkownika końcowego ( witryny) , w którym wykorzystywane są motywy. Są instalowane jako zależności projektu. Ta konfiguracja zakłada, że ​​motywy są dostępne za pośrednictwem jakiegoś repozytorium npm, co oznacza, że ​​już je opublikowaliśmy. Jeszcze nas tam nie ma. Najpierw musimy zbudować motywy rodzica i dziecka. Ale jak wygląda konfiguracja programistyczna ? Nasze motywy to dwa niezależne pakiety, ale musimy pracować nad nimi równolegle w ramach jednego projektu podczas rozwoju. Co więcej, chcemy stworzyć demo w tym samym projekcie, który bezpośrednio implementuje motywy.

Jednym z możliwych rozwiązań są miejsca pracy z przędzą. Dzięki obszarom roboczym przędzy pracujemy w jednym mono-repo z jednym plikiem blokady na poziomie głównym projektu. Co więcej, zależności można ze sobą łączyć, co oznacza, że ​​obszary robocze są od siebie zależne, a podczas programowania używamy wersji lokalnych.

Jak skonfigurować obszary robocze przędzy? Po pierwsze, upewnij się, że przędza jest zainstalowana na całym świecie. Następnie w katalogu głównym swojego monorepo dodaj plik package.json , który określa obszary robocze:

 { "private": true, "workspaces": [ "packages/*", "demo" ] }

Teraz każdy motyw jest podfolderem w packages z własnym plikiem package.json i pustym wpisem głównym index.js . Postępuję tak z każdym dodanym motywem:

 mkdir packages/gatsby-theme-wp-parent touch packages/gatsby-theme-wp-parent/package.json packages/gatsby-theme-wp-parent/index.js

Z package.json w następujący sposób:

 { "name": "@pehaa/gatsby-theme-wp-parent", "version": "1.0.0", "license": "MIT", "main": "index.js" }

Omówimy temat publikacji nieco dalej. Ale na razie zauważmy, że opublikujemy nasze motywy jako pakiety z zakresem; Jako zakresu używam tutaj mojego pseudonimu @pehaa . Pamiętaj, że jeśli zdecydujesz się opublikować pakiety objęte zakresem w publicznym rejestrze npm https://registry.npmjs.org, musisz jawnie określić dostęp publiczny i dodać następujące elementy do ich plików package.json :

 "publishConfig": { "access": "public" }

Oprócz motywów będziemy potrzebować również demo obszaru roboczego, z którego wypróbujemy nasz kod. Demo musi być "private" pakietem, ponieważ nie powinno być publikowane.

 // demo/package.json { "private": true, "name": "demo", "version": "1.0.0", "scripts": { "build": "gatsby build", "develop": "gatsby develop", "clean": "gatsby clean" } }

Po skonfigurowaniu obszarów roboczych możemy uruchamiać skrypty programistyczne lub kompilacyjne z dowolnego miejsca w naszym monorepo, określając skrypt i obszar roboczy w następujący sposób:

 yarn workspace demo develop

Nawiasem mówiąc, nie jesteś ograniczony do jednego demo . Na przykład nasze GatsbyWPThemes GatsbyWPThemes zawiera wiele wersji demonstracyjnych, które dodajemy do katalogu examples . W takim przypadku plik package.json poziomu głównego definiuje obszary robocze w następujący sposób:

 "workspaces": [ "packages/*", "examples/*" ]

Budowanie motywów Gatsby

Przede wszystkim musimy zainstalować response , gatsby react-dom i react . Musimy zainstalować te trzy jako zależności równorzędne ( -P ) w każdym motywie i jako zależności w naszym demo. Instalujemy również motyw nadrzędny jako zależność motywu potomnego, a motyw potomny jako zależność wersji demonstracyjnej.

 yarn workspace @pehaa/gatsby-theme-wp-parent add -P react react-dom gatsby yarn workspace @pehaa/gatsby-theme-wp-child add -P react react-dom gatsby yarn workspace @pehaa/gatsby-theme-wp-child add "@pehaa/gatsby-theme-wp-parent@*" yarn workspace demo add react react-dom gatsby "@pehaa/gatsby-theme-wp-child@*"

Uwaga : nie można dodać @pehaa/gatsby-theme-wp-parent ani @pehaa/gatsby-theme-wp-child bez numeru wersji. Musisz określić go jako @* lub @1.0.0 . Bez tego npm spróbuje pobrać pakiet z repozytorium zamiast korzystać z lokalnego. Później, gdy opublikujemy nasze pakiety z Lerną, wszystkie * zostaną automatycznie zaktualizowane do aktualnych wersji motywów i będą zsynchronizowane.

Motyw nadrzędny

Skupmy się teraz na motywie nadrzędnym i jego zależnościach:

 yarn workspace @pehaa/gatsby-theme-wp-parent add gatsby-source-wordpress gatsby-plugin-image gatsby-plugin-sharp gatsby-transformer-sharp gatsby-awesome-pagination

Obowiązkiem naszego motywu nadrzędnego jest załadowanie wtyczki źródłowej i trzech wtyczek wymaganych do przetwarzania i wyświetlania obrazów. Wszystkie ładujemy do pliku gatsby-config.js .

 // gatsby-config.js module.exports = (options) => { return { plugins: [ 'gatsby-plugin-sharp', // must have for gatsby 'gatsby-transformer-sharp', // must have for gatsby images 'gatsby-plugin-image', { resolve: 'gatsby-source-wordpress', options: { url: `${options.wordPressUrl}/graphql`, }, }, ], } }

Oprócz pozyskiwania treści, musimy dynamicznie tworzyć trasy dla naszych treści WordPress. Musimy stworzyć trasy dla statycznych stron WordPress, pojedynczych postów, archiwum blogów, archiwum kategorii i archiwum tagów. Gatsby dostarcza API createPages jako część Gatsby Node API. Rzućmy okiem na kod odpowiedzialny za tworzenie poszczególnych postów.

 exports.createPages = async ({ graphql, actions }) => { const { createPage } = actions const postsQuery = await graphql(` query GET_POSTS { allWpPost(sort: {order: DESC, fields: date}) { edges { node { uri id } } } } `) const posts = postsQuery.data.allWpPost.edges posts.forEach(({ node }) => { createPage({ path: node.uri, component: path.resolve('../src/templates/post-query.js'), context: { // Data passed to context is available in page queries as GraphQL variables // we need to add the post id here // so our blog post template knows which blog post it should display id: node.id }, }) }) }

Pełny kod można znaleźć w tym repozytorium GitHub. Możesz zauważyć, że różni się w zależności od typu strony. Inaczej jest w przypadku postu, strony czy archiwum, zwłaszcza z zaimplementowaną w tym drugim paginacją. Mimo to postępuje według tego samego wzoru:

• uruchom asynchroniczne graphql „pobierz elementy”;
• zapętlić wynikowe elementy i uruchomić funkcję pomocniczą createPage dla każdego elementu, przekazując:
  • ścieżka,
  • component — plik szablonu; Gatsby musi wiedzieć, co powinna wyświetlać każda strona,
  • context — wszelkie dane, których może potrzebować szablon (podany w polu component ).

Ponieważ nie chcemy martwić się o część interfejsu użytkownika w motywie nadrzędnym — delegujemy ją do komponentu, który ukryjemy w motywie potomnym.

 // src/templates/post-query.js import { graphql } from "gatsby" import Post from "../components/Post" export default Post export const pageQuery = graphql` query ($id: String!) { wpPost(id: { eq: $id }) { # query all usefull data } } `

Komponent Post ma dostęp do danych z zapytania strony graphql zdefiniowanego w pliku szablonu. Nasz komponent otrzymuje wyniki zapytania poprzez props jako props.data . Nasz plik komponentu jest oddzielony od szablonu, ale ma dostęp do jego danych. Dzięki tej konfiguracji jesteśmy w stanie ukryć komponent Post bez konieczności przepisywania zapytania.

 // src/components/Post.js import React from 'react' const Post = (props) => { return <pre>{JSON.stringify(props.data, null, 2)}</pre> } export default Post

Motyw potomny

Przejdźmy teraz do motywu potomnego i dodajmy jego zależności.

Uwaga : wybrałem użycie interfejsu użytkownika Chakra jako biblioteki komponentów, jest ona oparta na emocjach i zawiera własną wtyczkę Gatsby. Musimy również zainstalować style specyficzne dla treści WordPress z @wordpress/block-library .

 yarn workspace @pehaa/gatsby-theme-wp-child add @chakra-ui/gatsby-plugin @chakra-ui/react @emotion/react @emotion/styled @wordpress/block-library framer-motion gatsby-plugin-webfonts html-react-parser

Odpowiedzialność za motyw potomny jest częścią interfejsu użytkownika i musimy przesłonić dane wyjściowe gołej kości generowane przez motyw nadrzędny. Aby cieniowanie działało, musimy śledzić strukturę plików z motywu nadrzędnego. Na przykład, aby zastąpić komponent Post z gatsby-theme-wp-parent/src/components/Post.js , musimy utworzyć plik Post.js w gatsby gatsby-theme-wp-child/src/@pehaa/gatsby-theme-wp-parent/components . Folder pośredni @pehaa odpowiada zakresowi pakietu gatsby-theme-wp-parent .

Przekazywanie opcji do motywów

Wtyczki gatsby ładujemy i konfigurujemy w pliku gatsby-config.js . W naszej konfiguracji będziemy mieć trzy pliki konfiguracyjne, po jednym na każdym poziomie, motyw nadrzędny, motyw potomny i demo.

 ├── demo │ └── gatsby-config.js ├── packages │ ├── gatsby-theme-wp-child │ │ └── gatsby-config.js │ └── gatsby-theme-wp-parent │ └── gatsby-config.js └── ...

Na poziomie demo konfiguracja ładuje motyw potomny w następujący sposób:

 // demo/gatsby-config.js module.exports = { plugins: [ { resolve: '@pehaa/gatsby-theme-wp-child', options: { wordPressUrl: process.env.GATSBY_WP_URL, /* other options */ }, }, ], }

Jak widać powyżej, przekazujemy opcje do motywu potomnego. Będą one dostępne w pliku konfiguracyjnym na poziomie motywu potomnego. Jest to możliwe, ponieważ wtyczki Gatsby mają wyeksportowaną konfigurację jako funkcję. Tak więc, gdy ładujemy wtyczkę udostępniającą pewne opcje, wtyczka otrzymuje je jako argument swojej funkcji konfiguracyjnej. W szczególności opcje, które przekazujemy do motywu, można „przekierować” do motywu na poziomie nadrzędnym, na przykład:

 // gatsby-theme-wp-child/gatsby-config.js const defaultFonts = ... module.exports = (options) => { // destructure option to extract fonts const {fonts, ...rest} = options return { plugins: [ { resolve: `@pehaa/gatsby-theme-wp-parent`, options: { // "forward" the options gatsby-theme-wp-child options to its parent theme ...rest } }, '@chakra-ui/gatsby-plugin', { resolve: `gatsby-plugin-webfonts`, options: { fonts: fonts || defaultFonts }, }, ], } }

Spójrzmy ponownie na powyższy kod. Zwróć uwagę, że definiujemy kroje czcionek na poziomie motywu potomnego, ale zachowujemy możliwość ich modyfikacji za pomocą opcji motywu.

 // demo/gatsby-config.js module.exports = { plugins: [ { resolve: `@pehaa/gatsby-theme-wp-child`, options: { wordPressUrl: process.env.GATSBY_WP_URL, fonts: { google: [{family: "Rubik"}], }, }, }, ], }

Konfigurując nasze motywy należy pamiętać, że motyw to tylko pakiet, a użytkownik końcowy nie ma bezpośredniego dostępu do jego kodu. Dlatego warto myśleć z wyprzedzeniem i eksponować odpowiednie ustawienia. Jeśli nasz motyw ładuje wtyczkę wymagającą konfiguracji, prawdopodobnie powinniśmy przekazać opcje wtyczek z poziomu projektu (demo) do samego końca.

Spójrzmy na przykład. Nasz motyw nadrzędny korzysta z wtyczki gatsby-source-wordpress , która pobiera dane z WordPressa. Ta wtyczka zawiera kilka opcji, niektóre z nich mogą mieć kluczowe znaczenie dla procesu kompilacji, takie jak schema.requestConcurrency lub schema.timeout . Ale znowu, motyw nadrzędny jest tylko pakietem, a użytkownik końcowy nie może edytować jego pliku gatsby-config . Może się to wydawać oczywiste, ale jakoś przegapiliśmy to w pierwszym wydaniu Gatsby WP Themes. Jednak dzięki szybkiej naprawie użytkownik może przekazać opcje gatsby-plugin-source-wordpress z konfiguracji projektu…

 // user's project gatsby-config.js module.exports = { plugins: [ { resolve: `@pehaa/gatsby-theme-wp-child`, options: { wordPressUrl: process.env.GATSBY_WP_URL, gatsbySourceWordPressOptions: {}, // ... }, }, ], }

… przez motyw podrzędny i nadrzędny do wtyczki docelowej:

 // packages/gatsby-theme-wp-parent/gatsby-config.js module.exports = (options) => { return { plugins: [ // ... { resolve: `gatsby-plugin-source-wordpress`, options: { url: `${options.wordPressUrl}/graphql`, ...options.gatsbySourceWordPressOptions }, }, ], } }

Motywy CSS

Rozwiązania CSS-in-JS, które obsługują motywy, wydają się dobrze pasować do motywów Gatsby. Nasz motyw potomny Gatsby będzie używał frameworka Chakra UI, a my nieznacznie dostosujemy jego motyw CSS. Tak, interfejs użytkownika Chakra również używa pojęcia „motywu”. W tym kontekście motyw jest obiektem JavaScript, który przechowuje wartości stylów systemu projektowania, skale i/lub tokeny projektu. Aby uniknąć nieporozumień, będę nazywać go „motywem CSS”. Zainstalowaliśmy już wymagane pakiety @chakra-ui wraz z wtyczką Gatsby @chakra-ui/gatsby-plugin . Przyjrzyjmy się kodowi wtyczki, aby dowiedzieć się, jak to działa. W rzeczywistości zawija naszą aplikację Gatsby do ChakraProvider i udostępnia plik src/theme.js do tworzenia cienia, dzięki czemu możemy postępować w ten sposób:

 /* packages/gatsby-theme-wp-child/src/@chakra-ui/gatsby-plugin/theme.js */ import { extendTheme } from "@chakra-ui/react" const theme = { fonts: { body: "Karma, sans-serif", heading: "Poppins, sans-serif", }, styles: { global: { body: { color: "gray.700", fontSize: "xl", }, }, }, components: { Button: { baseStyle: { borderRadius: "3xl", }, defaultProps: { colorScheme: "red", }, }, }, } export default extendTheme(theme)

Po raz kolejny zastosowaliśmy koncepcję cieniowania. Kluczowym aspektem jest tutaj lokalizacja, w której utworzyliśmy plik theme.js .

Później zobaczymy, jak utworzyć cieniowanie motywu CSS na poziomie projektu użytkownika.

Publikowanie motywów z Lerna

Gdy Twoje motywy będą gotowe, musisz je opublikować. Jeśli chcesz udostępnić swój kod publicznie, najprawdopodobniej opublikujesz go w publicznym rejestrze npm. A jeśli nigdy wcześniej nie publikowałeś pakietu, możesz zapoznać się z procesem, grając z Verdaccio na swoim lokalnym komputerze.

W Gatsby WP Themes korzystamy z usługi premium od Cloudsmith. Cloudsmith obsługuje w pełni funkcjonalne rejestry dla pakietów npm z opcją premium dla rejestrów prywatnych i bezpłatnym rozwiązaniem dla rejestrów publicznych. Kontynuuję korzystanie z bezpłatnego rozwiązania Cloudsmith. Po utworzeniu konta utwórz nowe repozytorium; mój to pehaa/gatsby-wp-theming .

Aby wprowadzić zmiany w rejestrze Cloudsmith za pomocą wiersza poleceń, musisz podać swoje dane logowania do tego rejestru. Wystarczy wpisać:

 npm login --registry=https://npm.cloudsmith.io/organistion/repository_name/

i zostaniesz poproszony o podanie nazwy użytkownika, hasła (które jest kluczem API) i adresu e-mail.

Mając wielopakowe repozytorium git, możesz użyć Lerny do ułatwienia publikowania. Lerna dobrze komponuje się z miejscami do pracy z przędzą. Możesz zainstalować Lerna CLI globalnie za pomocą npm install --global lerna . Aby go zainicjować w naszym projekcie, uruchomimy następujące polecenie:

 lerna init --independent

Powyższe polecenie utworzy plik lerna.json w katalogu głównym monorepo. Musisz ręcznie dodać "useWorkspaces" : true i "npmClient": "yarn" ; może być również konieczne określenie command.publish.registry , jeśli nie jest to domyślny publiczny npm.

 { "npmClient": "yarn", "useWorkspaces": true, "version": "independent", "command": { "publish": { "registry": "https://cloudsmith.io/organisation/repository_name" } } }

Następnie polecenie lerna publish publikuje pakiety, które uległy zmianie od ostatniego wydania. Domyślnie Lerna wyświetla monity o zmianę wersji każdego aktualizowanego pakietu. Możesz pominąć monity, uruchamiając:

 lerna publish [major|minor|patch|premajor|preminor|prepatch|prerelease] --yes

Możesz również skonfigurować Lernę do używania specyfikacji Konwencjonalnych Commitów do określania wersji i generowania plików CHANGELOG.md. Mając wszystkie dostępne opcje, powinieneś być w stanie dostosować sposób korzystania z Lerny do swojego przepływu pracy.

Używanie motywu w projekcie

Teraz zatrzymajmy serwer deweloperski i spójrzmy z perspektywy użytkownika. Stworzymy nowy projekt gatsby-wp-site , który implementuje gatsby-theme-wp-child jako pakiet instalowany z repozytorium npm. W naszym folderze projektu zainstalujemy nasze cztery zależności: gatsby , react , react-dom , i sam motyw . Ponieważ użyliśmy Cloudsmith do publikowania pakietów @pehaa , będziemy musieli dodać plik .npmrc , w którym określamy repozytorium @pehaa w następujący sposób:

 mkdir gatsby-wp-site cd gatsby-wp-site echo "@pehaa:registry=https://npm.cloudsmith.io/pehaa/gatsby-wp-theming/" >> .npmrc yarn init -yp yarn add react react-dom gatsby @pehaa/gatsby-theme-wp-child

Nasza strona jest prawie gotowa. Musimy tylko utworzyć plik gatsby-config.file aby załadować motyw i podać adres URL WordPress. Po zakończeniu jesteśmy gotowi do uruchomienia gatsby build .

 // gatsby-config.js module.exports = { plugins: [ { resolve: "@pehaa/gatsby-theme-wp-child", options: { wordPressUrl: "https://yourwordpress.website" } } ] }

Nasza strona jest gotowa.

A co z personalizacją? Nadal możemy skorzystać z cieniowania. Co więcej, poziom projektu zawsze ma pierwszeństwo pod względem shadowingu. Zobaczmy to w akcji, zastępując komponent Footer. W tej chwili nasza stopka jest zdefiniowana w @pehaa/gatsby-theme-wp-child/src/components/Footer.js . Musimy stworzyć folder src i odtworzyć następującą strukturę plików:

 gatsby-wp-site ├── src │ └── @pehaa │ └── gatsby-theme-wp-child │ └── components │ └── Footer.js

Dzięki powyższej strukturze plików jesteśmy gotowi udostępnić nową wersję stopki serwisu. Na przykład:

 import React from "react" import { useStaticQuery, graphql } from "gatsby" import { Box } from "@chakra-ui/react" const Footer = () => { const data = useStaticQuery(graphql` query { wp { generalSettings { title } } } `) return ( <Box as="footer" p="6" fontSize="sm" bg="gray.700" color="white" mt="auto" textAlign="center" > <b>{data.wp.generalSettings.title}</b> - Built with WordPress and GatsbyJS </Box> ) } export default Footer

Na koniec zobaczmy, jak możemy pracować z motywem CSS. Za pomocą kodu jak poniżej, prawidłowo umieszczonego w src/@chakra-ui/gatsby-plugin/theme.js , możesz rozszerzyć domyślny motyw w ramach projektu.

 // src/@chakra-ui/gatsby-plugin/theme.js import { extendTheme } from "@chakra-ui/react" const theme = { /* ... */ } export default extendTheme(theme)

W większości przypadków nie jest to dokładnie to, czego potrzebujesz. Nowy motyw CSS ignoruje ten z gatsby-theme-wp-child , podczas gdy zamiast tego chcesz rozszerzyć motyw CSS ustawiony w motywie potomnym Gatsby. To drugie jest możliwe, ponieważ funkcja extendTheme umożliwia przekazywanie wielu obiektów. Aby to zadziałało, musisz zaimportować motyw CSS z gatsby-theme-wp-child i przekazać go jako drugi argument do funkcji extendTheme :

 // src/@chakra-ui/gatsby-plugin/theme.js import theme from "@pehaa/gatsby-theme-wp-child/src/@chakra-ui/gatsby-plugin/theme" import { extendTheme } from "@chakra-ui/react" const extendedTheme = { fonts: { body: "Rubik, sans-serif", heading: "Rubik, sans-serif", }, /* ... */ } export default extendTheme(extendedTheme, theme)

Możesz zobaczyć witrynę na żywo tutaj, jest ona wdrożona z głównej gałęzi tego repozytorium GitHub.

Zawijanie

Właśnie widziałeś motyw Gatsby'ego w akcji. Dzięki podejściu tematycznemu możesz szybko skonfigurować wiele witryn Gatsby z większością ich kodu utrzymywaną w ramach pakietów tematycznych. Zobaczyliśmy również, jak podzielić części projektu na pakiety i jak wykorzystać cieniowanie.

W naszym przykładzie zastosowaliśmy konfigurację dwóch motywów z relacją rodzic-dziecko między motywami. Nie zawsze jest to idealny wybór.

Czasami możesz chcieć zajść dość daleko w dostosowywaniu interfejsu użytkownika. W takim przypadku możesz rozważyć ładowanie i cieniowanie bezpośrednio motywu nadrzędnego zamiast używania motywu podrzędnego. W rzeczywistym scenariuszu prawdopodobnie wybrałbyś kilka motywów na poziomie potomnym odpowiedzialnych za różne części interfejsu użytkownika, które można ponownie wykorzystać (np. komentarze, formularze lub wyszukiwanie).

Dalsza lektura na Smashing Magazine

• Budowanie API z funkcjami Gatsby
• Funkcje bezserwerowe Gatsby'ego i międzynarodowa stacja kosmiczna
• Zarabiaj na oprogramowaniu Open Source z funkcjami Gatsby i Stripe
• Smashing Podcast Episode 20 z Marcy Sutton: Co to jest Gatsby?