Verwendung des neuen Gatsby Source WordPress Plugins

In meinem vorherigen Artikel habe ich erläutert, wie ich gelernt habe, eine entkoppelte, von WordPress angetriebene Gatsby-Website zu erstellen, indem ich das Gatsby Source WPGraphQL Plugin verwendet habe. Das Projekt wurde nach der laufenden Entwicklungsversion von WPGraphQL und einem exzellenten Tutorial von Henrik Wirth umgesetzt. Obwohl WPGraphQL zu dieser Zeit auf einigen Produktionswebsites verwendet wurde, gab es viele Iterationen, die Breaking Changes einführten. Seit der Veröffentlichung von WPGraphQL v1.0 im letzten November ist das Plugin stabil und über das WordPress-Plugin-Verzeichnis verfügbar.

Das WPGraphQL-Plugin kann verwendet werden, um eine Website zu erstellen, die WordPress für die Inhaltsverwaltung nutzt, aber mit einem Frontend, das von Gatsby gesteuert wird. Wir nennen dies ein „entkoppeltes“ oder „headless“ CMS, da das Backend und das Frontend der Website separate Einheiten sind, die über APIs miteinander kommunizieren, wobei Komponenten im Frontend Daten aus dem CMS beziehen.

Die WPGraphQL-Plugin-Website bietet eine solide Schritt-für-Schritt-Dokumentation für den Einstieg, und der Veröffentlichungsankündigungspost listet neun Beispiele von Produktionswebsites auf, die das Plugin verwenden.

Im eigentlichen Sinne einer „entkoppelten“ oder „headless“ Website kann WPGraphQL verwendet werden, um WordPress-Daten auf andere Frameworks zu übertragen, wie z. B. Next.js, Vue.js und andere. Für das Gatsby-Framework wird das Gatsby Source WordPress Plugin empfohlen, das WPGraphQL zur Abfrage von Daten aus WordPress nutzt.

Lassen Sie uns alles gemeinsam einrichten und das Plugin erkunden.

Voraussetzungen

In meinem vorherigen Artikel haben wir die Voraussetzungen für die Einrichtung von WordPress- und Gatsby-Websites sowie die Übertragung von Backend-WordPress-Daten auf eine Gatsby-betriebene Frontend-Website mit anschließender Bereitstellung behandelt. Ich lasse viele dieser Details hier aus, da die grundlegenden Konzepte für diesen Artikel dieselben sind, abgesehen davon, dass die WordPress-Daten diesmal vom Gatsby Source WordPress Plugin abgerufen werden.

Wenn Sie neu bei Gatsby sind und gerade erst auf den Zug der von Gatsby generierten statischen Website-Generatoren aufspringen, empfehle ich Ihnen, „An Honest Review of Gatsby“ von React-Experte David Cramer und „Gatsby vs Next.js“ von Jared Palmer zu lesen. Was wir hier behandeln werden, ist nicht für jeden geeignet, und diese Artikel können hilfreich sein, um für sich selbst zu beurteilen, ob es die richtige Technologie für Sie und Ihr Projekt ist.

WPGraphQL oder GraphQL ist die primäre Abfragesprachen-API, die im Framework von Gatsby verwendet wird. Es gibt häufige Updates in GraphQL, die oft Expertenwissen erfordern und die Beobachtung von Breaking Changes notwendig machen. Schließlich wird GraphQL von React-Experten für andere React-Experten entwickelt. Nichtsdestotrotz gibt es einige Fehlerbehebungsanleitungen und einen WPGraphQL Slack, wo sowohl die Autoren des WPGraphQL- als auch des Gatsby Source WordPress-Plugins aktiv teilnehmen und Fragen beantworten.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung zur Verwendung des Gatsby Source WordPress Plugins. Dies ist bereits in der Gatsby-Dokumentation verfügbar. Umgekehrt, wenn Sie ein Experte in React, JavaScript, Node.js oder GraphQL sind, dann ist das, was wir hier behandeln, wahrscheinlich etwas, das Sie bereits wissen. Dieser Artikel ist ein Meinungsstück, das auf meiner persönlichen Erfahrung basiert und hoffentlich für den durchschnittlichen WordPress-Benutzer mit grundlegenden Arbeitskenntnissen zu dem Thema nützlich ist.

Und bevor wir beginnen, ist es erwähnenswert, dass das Gatsby Source WordPress Plugin in Version 4 komplett neu geschrieben wurde und WPGraphQL als seine Datenquelle verwendet. Die vorherige Version, Version 3, wurde mit der REST API als Datenquelle erstellt. Da die stabile Version des Plugins kürzlich veröffentlicht wurde, ist die Anzahl der Starter-Themes und Demos, die es unterstützen, begrenzt.

Zuerst brauchen wir WordPress

Für dieses Projekt habe ich eine neue WordPress-Site mit Local by Flywheel eingerichtet, die das Standard-Theme Twenty Twenty verwendet. Ich habe die Theme Unit Test Daten für Seiten und Beiträge importiert, wie im WordPress Codex beschrieben. Obwohl dies die Basis war, mit der ich gearbeitet habe, hätte es genauso gut eine bestehende WordPress-Site sein können, die entweder auf einem Remote-Server oder einer lokalen Installation läuft.

Nun, da wir eine etablierte Basis haben, können wir uns in den WordPress-Adminbereich einloggen und die benötigten Plugins WPGraphQL und WPGatsby installieren und aktivieren.

Wie wir im vorherigen Artikel behandelt haben, macht dies die GraphQL- und WPGraphiQL-API im WordPress-Adminbereich verfügbar und ermöglicht der GraphiQL-API die Erstellung eines „Spielplatzes“ zum Testen von GraphQL-Abfragen basierend auf WordPress-Daten.

Jetzt brauchen wir ein Gatsby-Frontend

Gatsby ist bekannt für seine gute Dokumentation und seine soliden Starter-Vorlagen. Um eine neue, von WordPress betriebene Website zu erstellen, empfehlen Gatsby-Tutorials, dass entweder die Verwendung eines Starters oder der Beginn von Grund auf für das, was wir tun, in Ordnung ist.

Gatsby bietet auch eine Bibliothek mit Beispiel-Websites für grundlegende Anwendungsfälle, die um eine bestimmte Technologie aufgebaut sind. Derzeit gibt es eine, die WordPress verwendet, und eine, die WordPress mit dem Advanced Custom Fields Plugin verwendet. Beachten Sie, dass die Beispiel-Websites in der Bibliothek immer noch das gatsby-source-wordpress Plugin 3 verwenden und zum Zeitpunkt der Erstellung dieses Artikels noch nicht auf Version 4 aktualisiert wurden.

Laut Gatsby-Tutorials gibt es drei Optionen zur Erstellung einer von WordPress betriebenen Gatsby-Website. Sehen wir uns jede davon an.

Option 1: Verwendung des Gatsby-Starters

Die Docs enthalten eine Schritt-für-Schritt-Anleitung zur Einrichtung einer WordPress-Gatsby-Website, aber hier ist die Essenz.

Führen Sie Folgendes auf der Kommandozeile aus, um den Starter aus dem GitHub-Repository abzurufen und ihn in einen Projektordner my-wpstarter zu klonen

#! clone starter repo
gatsby new my-wpstarter https://github.com/gatsbyjs/gatsby-starter-wordpress-blog 

Installieren Sie dann die npm-Pakete

#! npm
npm install

#! or yarn
yarn install 

Nachdem der Starter geklont wurde, öffnen wir die Datei gatsby-config.js in unserem Code-Editor und aktualisieren die URL-Option, um Daten von unserem WordPress-Endpunkt abzurufen (siehe oben).

// gatsby-config.js
{
  resolve: gatsby-source-wordpress,
    options: {
     // WordPress is the GraphQL url.
     url: process.env.WPGRAPHQL_URL || https://wpgatsbydemo.wpengine.com/graphql,
  },
},

Jetzt ersetzen wir die URL des Datenquellen-Endpunkts des Starters durch unsere eigene WordPress-Website-URL

// gatsby-config.js file
{
  resolve: `gatsby-source-wordpress`,
  options: {
    url: `http://gatsbywpv4.local/graphql`,
  },
},

Stellen wir sicher, dass wir uns im Projektverzeichnis my-wpstarter befinden. Vom Projektordner aus führen wir den Befehl gatsby develop aus, um unsere neue Gatsby-Website aus unserem WordPress-Datenquellen-Endpunkt zu erstellen. Im Terminal sollten wir sehen, wie das Plugin gatsby-source-wordpress Daten abruft, einschließlich Fehlern und erfolgreichen Website-Prozessen auf dem Weg.

Wenn wir am Ende die Meldung success Building development bundle sehen, bedeutet dies, dass der Gatsby-Website-Build-Prozess abgeschlossen ist und die Website unter https://:8000 aufgerufen werden kann.

Dies ist ein minimalistischer Starter-Blog mit grundlegenden Dateien und einigen Komponenten. Seine Dateistruktur ist der von gatsby-starter-blog sehr ähnlich, außer dass er einen Ordner mit Vorlagen enthält, der die Vorlagendateien blog-post.js und blog-post-achive.js enthält.

Wenn wir den GraphiQL API Explorer unter https://:8000/___graphql aufrufen, können wir alle von WPGraphQL bereitgestellten Daten aus WordPress sehen, sowie spezifische Daten direkt über die Benutzeroberfläche abfragen und abrufen.

Sie haben es verstanden! Gatsby überlässt uns den Rest für die Erstellung, indem wir Gatsby-Komponenten verwenden, die WordPress-Daten für die Präsentation abrufen.

Option 2: Von Grund auf neu aufbauen

Die Gatsby-Dokumentation bietet eine detaillierte Schritt-für-Schritt-Anleitung zur Erstellung einer neuen, von WordPress betriebenen Gatsby-Website von Grund auf mit dem Standard-Starter-Theme von Gatsby.

Wir starten ein neues Projekt über die Kommandozeile

#! create a new Gatsby site
gatsby new wpgatsby-from-scratch-demo

Dies gibt uns einen Ordner wpgatsby-from-scratch-demo, der das Starter-Theme enthält. Von hier aus wechseln wir in diesen Ordner und beginnen mit der Entwicklung

cd wpgatsby-from-scratch-demo
gatsby develop

Jetzt können wir https://:8000 im Browser öffnen und die Willkommensseite sehen.

Jetzt können wir damit beginnen, Daten von unserer WordPress-Website abzurufen. Lassen Sie uns das Gatsby Source Plugin installieren

#! install with rpm
npm install gatsby-source-wordpress

#! install with yarn
yarn add Gatsby-source-wordpress

Wenn wir jetzt unseren Browser überprüfen, werden wir feststellen, dass nichts passiert – wir sehen immer noch die gleiche Gatsby-Willkommensseite. Um unsere WordPress-Website-Daten abzurufen, müssen wir das Plugin zur Datei gatsby-config.js hinzufügen. Öffnen Sie die Datei und fügen Sie Folgendes ein

// gatsby-config.js
module.exports = {
  siteMetadata: {
    // ...
  },
  plugins: [
  // Add Gatsby-source-wordpress plugin
  {
      resolve: `gatsby-source-wordpress`,
      options: {
        /*
         * The full URL of the WordPress site's GraphQL API.
         * Example : 'https://www.example-site.com/graphql'
         */
        url: `http://gatsbywpv4.local/graphql`,
       },
     },
    // The following plugins are not required for gatsby-source-wordpress ....
  ],
}

Genau wie beim letzten Mal müssen wir die WordPress-Daten-Endpunkt-Quelle auf die URL unserer WordPress-Website ändern. Lassen Sie uns gatsby develop in unserem Terminal ausführen, um alles zu starten.

Wenn wir jedoch https://:8000 in unserem Browser öffnen, scheint nichts zu passieren. Wir sehen immer noch die gleiche Willkommensseite. Aber wenn wir GraphiQL in unserem Browser (unter https://:8000/___graphql) überprüfen, sehen wir alle WordPress-Daten, die für unsere Gatsby-Website verfügbar sind und die wir abfragen und anzeigen können, wie wir möchten.

Testen wir die folgende Abfrage, die ich direkt aus dem Gatsby-Tutorial im GraphiQL Explorer entnommen habe

query {
  allWpPost {
    nodes {
      id
      title
      excerpt
      slug
      date(formatString: "MMMM DD, YYYY")
    }
  }
}

Wenn wir die obige Abfrage ausführen, sehen wir den Wert der Eigenschaft allWpPost.nodes mit Untereigenschaften für id, title, excerpt und andere.

Öffnen wir nun unsere Komponente src/components/pages/index.js und ersetzen den Code durch diesen

// src/components/pages/index.js
import  React from "react"
import { graphql } from "gatsby"
import Layout from "../components/layout"
import SEO from "../components/seo"

export default function Home({ data }) {
  return (
    <Layout>
      <SEO title="home" />
      <h1>My WordPress Blog</h1>
      <h4>Posts</h4>
      {data.allWpPost.nodes.map(node => (
        <div>
          <p>{node.title}</p>
          <div dangerouslySetInnerHTML={{ __html: node.excerpt }} />
        </div>
      ))}
    </Layout>
  )
}

export const pageQuery = graphql`
  query {
    allWpPost(sort: { fields: [date] }) {
      nodes {
        title
        excerpt
        slug
      }
    }
  }
`

Speichern Sie sie, starten Sie den Server mit gatsby develop neu und aktualisieren Sie die Seite. Wenn der Build erfolgreich war, sollte die Homepage unserer Website eine Liste von sortierten Blogbeiträgen aus WordPress anzeigen!

Nach dem Tutorial erstellen wir Seiten für jeden Blogbeitrag und verknüpfen den Beitragstitel aus der Liste mit der Beitragsseite. Der Prozess der Seitenerstellung mit Markdown-Daten wird im Teil 7 des grundlegenden Gatsby-Tutorials detailliert beschrieben, dem wir auch hier folgen werden.

Wie im Tutorial beschrieben, verwendet Gatsby die createPages API, oder was es als seine „Arbeitspferd“-API bezeichnet, um Seiten programmatisch aus Daten (aus Markdown oder WordPress) zu erstellen. Im Gegensatz zu Markdown-Daten müssen wir hier keinen Slug erstellen, da jeder WordPress-Beitrag seinen eigenen eindeutigen Slug hat, der aus dem WordPress-Datenendpunkt abgerufen werden kann.

Erstellen von Seiten für jeden Beitrag

Gatsby verwendet die Datei gatsby-node.js, die sich im Stammverzeichnis unseres Projekts befindet, um Blogbeiträge programmatisch zu erstellen. Öffnen wir die Datei gatsby-node.js in unserem Texteditor und fügen den folgenden Code aus dem Tutorial hinzu.

// gatsby-node.js 
const path = require(`path`)

exports.createPages = ({ graphql, actions }) => {
  const { createPage } = actions
  return graphql(`
    {
      allWpPost(sort: { fields: [date] }) {
        nodes {
          title
          excerpt
          content
          slug
        }
      }
    }
  `).then(result => {
    console.log(JSON.stringify(result, null, 4))
    process.exit()
  })
}

Wie im Gatsby Teil 7 Tutorial beschrieben, ist der obige Code der erste Teil der Erstellung unserer Beitragsseiten aus der WordPress-Datenquelle. Dem Leitfaden folgend starten wir unseren Server neu und entwickeln unsere Website mit gatsby develop.

Wir sollten console.log-Ausgaben in unserem Terminal sehen, während Seiten erstellt werden. Unsere Homepage sieht jedoch immer noch gleich aus. Um einzelne Beiträge zu erstellen, benötigt Gatsby Vorlagen zur Seitenerstellung, die wir im nächsten Schritt erstellen werden. Das werden wir als Nächstes tun.

Erstellen von Blogbeitragsvorlagen

Lassen Sie uns einen Ordner src/components/templates im Verzeichnis src/ erstellen und eine Datei blog-post.js erstellen, indem wir die folgenden Code-Snippets aus dem Tutorial einfügen

// src/templates/blog-post.js
import React from "react"
import Layout from "../components/layout"
import { graphql } from "gatsby"

export default function BlogPost({ data }) {
  const post = data.allWpPost.nodes[0]
  console.log(post)
  return (
    <Layout>
      <div>
        <h1>{post.title}</h1>
        <div dangerouslySetInnerHTML={{ __html: post.content }} />
      </div>
    </Layout>
  )
}
export const query = graphql`
  query($slug: String!) {
    allWpPost(filter: { slug: { eq: $slug } }) {
      nodes {
        title
        content
      }
    }
  }
`

Wie im Tutorial erläutert, erstellen die obigen Code-Snippets einen einzelnen Beitrag mit React JSX und umschließen post.title und post.content (Zeilen 12-13) mit den Komponenten von src/components/layout.js. Im unteren Teil der Datei wird eine GraphQL-Abfrage hinzugefügt, die einen bestimmten Beitrag basierend auf der Beitrags-Slug-Variable $slug aufruft. Diese Variable wird an die Vorlage blog-post.js übergeben, wenn die Seite in gatsby-node.js erstellt wird.

Als Nächstes sollten wir auch die Zeilen 12-13 unserer Datei gatsby-node.js mit dem folgenden Code aus dem Tutorial aktualisieren.

// gatsby-node.js
const path = require(`path`)

 exports.createPages = ({ graphql, actions }) => {
   const { createPage } = actions
   return graphql(`
     {
       allWpPost(sort: { fields: [date], order:DEC }) {
         nodes {
           title
           excerpt
           content
           slug
         }
       }
     }
   `).then(result => {
    result.data.allWpPost.nodes.forEach(node => {
        createPage({
          path: node.slug,
          component: path.resolve(`./src/templates/blog-post.js`),
          context: {
            // This is the $slug variable passed to blog-post.js
            slug: node.slug,
          },
        })
      })
   })
 }

Lassen Sie uns unseren lokalen Server stoppen und neu starten mit gatsby develop und die Website anzeigen. Wir werden unsere Homepage mit einer Liste von Blogbeitragslinks nicht sehen. Wenn wir jedoch unter https://:8000/abcdf nachsehen, sollten wir die folgende 404-Seite mit einer Liste von Links zu einzelnen Seiten und Beiträgen sehen.

Wenn wir https://:8000/hello-gatsby-world besuchen, sollten wir unseren Beitrag „Hello Gatsby WordPress World“ in voller Pracht sehen.

Der nächste Schritt ist die Verknüpfung der Beitragstitel von der Homepage mit den tatsächlichen Beiträgen.

Verknüpfen von Beiträgen von der Homepage

Die Verknüpfung der Arbeit von der Homepage mit den Beitragsseiten erfolgt durch das Umschließen von Beitragstiteln in der Datei index.js mit dem Link-Komponenten von Gatsby. Öffnen wir die zuvor erstellte Datei index.js und fügen Sie die Komponente Link hinzu

// src/components/pages/index.js
import React from "react"
import { Link, graphql } from "gatsby"
import Layout from "../components/layout"
import SEO from "../components/seo"

export default function Home({ data }) {
  return (
    <Layout>
      <SEO title="home" />
     {/* <h1>My WordPress Blog</h1>
      <h4>Posts</h4> */}
      {data.allWpPost.nodes.map(node => (
        <div key={node.slug}>
          <Link to={node.slug}>
            <h2>{node.title}</h2>
          </Link>
          <div dangerouslySetInnerHTML={{ __html: node.excerpt }} />
        </div>
      ))}
    </Layout>
  )
}

export const pageQuery = graphql`
  query {
    allWpPost(sort: { fields: [date], order: DEC  }) {
      nodes {
        title
        excerpt
        slug
      }
    }
  }
`

Wir haben die Komponente Link von Gatsby importiert und dann den Beitragstitel mit der Komponente Link umschlossen und den Slug des Beitrags referenziert. Lassen Sie uns den Code bereinigen, indem wir den Seitentitel auskommentieren, das Titelsymbol in <h2> ändern und die Reihenfolge der sortierten Beiträge in unserer graphql-Abfrage sowie in der Datei gatsby-node.js auf DEC setzen.

Wie wir bereits getan haben, stoppen und starten wir den Entwicklungsserver mit gatsby develop und rufen unsere Homepage unter https://:8000 auf. Der Beitragstitel sollte zur einzelnen Beitragsseite verlinken.

Bis hierhin werden wir diese zweite Methode verfolgen. Der Rest dessen, was wir behandeln werden, beschreibt, wie man Menüeinträge abruft und andere Datentypen abfragt, wie z. B. benutzerdefinierte Beitragstypen, und inkrementelles Erstellen und Vorschauen usw. konfiguriert.

Sie können dasselbe Verfahren anwenden, um Seiten, benutzerdefinierte Beitragstypen, benutzerdefinierte Felder, Taxonomien und all den Spaß und die Flexibilität aufzurufen und zu erstellen, für die WordPress bekannt ist. Dies kann so einfach oder so komplex sein, wie Sie es wünschen, also erkunden Sie es und haben Sie Spaß damit!

— Gatsby-Tutorial-Dokumentation 

Option 3: Verwendung des Gatsby WordPress Twenty Twenty Starters

Die Starter-Vorlage von Gatsby für das Standard-WordPress-Theme Twenty Twenty wurde von Henrik Wirth erstellt und gepflegt, der auch eine äußerst detaillierte und umfassende Schritt-für-Schritt-Anleitung hat, an die Sie sich vielleicht aus meinem vorherigen Artikel erinnern. Dieser Starter ist im Gegensatz zu den anderen tatsächlich auf Version 4 des Gatsby Source Plugins aktualisiert und funktioniert nach der anfänglichen WordPress-Einrichtung wie in der Dokumentation beschrieben sofort. Er behält das gleiche Twenty Twenty-Styling im Gatsby-Frontend bei, hat aber wenige Einschränkungen – darunter Kommentare, monatliche Archivseiten und Tags –, die nicht unterstützt werden.

Klonen wir zunächst den Starter in unseren Ordner twenty-twenty-starter.

#! clone gatsby-starter-wordpress-twenty-twenty 
gatsby new twenty-twenty-starter https://github.com/henrikwirth/gatsby-starter-wordpress-twenty-twenty

Lassen Sie uns in diesen Ordner wechseln und dann gatsby develop ausführen, um die Website zu starten. Beim ersten Mal funktioniert sie nicht richtig, da wir unseren WPGRAPHQL_URL-Wert in der Datei env.example noch nicht geändert haben. Wir müssen die Datei von .env.example in einfach .env umbenennen, wie in der Dokumentation vorgeschlagen.

Danach starten Sie den Entwicklungsserver mit gatsby develop neu. Die Website sollte erfolgreich kompiliert werden.

Das Menü wird möglicherweise angezeigt oder auch nicht, je nachdem, wie das WordPress-Menü benannt ist. Der Menü-Slug des Starters zur Abfrage von Menüeinträgen ist primary in Menu.js (Zeile 8). Da ich meine WordPress-Website stattdessen mit main-menu eingerichtet hatte, musste ich die Datei Menu.js entsprechend anpassen.

Da der Starter mit älteren Versionen unserer Tools getestet wurde, habe ich beschlossen, die Plugins auf die neuesten Versionen zu aktualisieren – WPGraphQL 1.2.6, WPGatsby 1.0.6 und Gatsby Source WordPress 4.0.1 – und es funktionierte einwandfrei ohne Fehler.

Der Twenty Twenty-Starter folgt der Dateistruktur des Twenty Nineteen Gatsby Themes, sowie Gatsby Starter WordPress Advanced. Henrik Wirth beschreibt in seiner Schritt-für-Schritt-Anleitung, wie WordPress-Daten nach Gatsby übertragen werden, ebenso wie Muhammad Muhsin in einem Tutorial. Ansonsten ist die Erstellung von Seiten, Seitenvorlagen und die Übertragung von Menüeinträgen genau gleich.

Dieser Starter verwendet das gleiche CSS wie das Standard-WordPress-Theme Twenty Twenty und den gleichen Assets-Ordner, einschließlich Schriftarten, Bildern, SVG-Dateien und anderen Dateien, die im Standard-Theme enthalten sind.

Wenn Sie mit dem Styling von WordPress Twenty Twenty zufrieden sind, dann war's das. Genießen Sie Ihre neue, entkoppelte Gatsby-Website!

Aber sagen wir, wir möchten mit benutzerdefinierten Stilen arbeiten. Die CSS-Dateien werden aus dem assets-Ordner über die Datei gatsby-browser.js importiert.

Lassen Sie uns die Stile für Header, Footer, Beiträge und Seiten ändern. Gatsby bietet verschiedene Optionen zum Stylen seiner Komponenten, und in diesem Projekt bin ich dem CSS Module zum Stylen gefolgt und habe das CSS-Markup der Twenty Twenty Starter-Komponenten entsprechend angepasst.

Wir können damit beginnen, einen Stilordner unter src/components/styles und darin einen base-Ordner zu erstellen. Hier ist die allgemeine Dateistruktur, die wir anstreben

#! partial structure of /style folder
src
 |--/components
   |--/styles
     |--main.css          
     |--/base
       |--reset.css
       |--variables.css
     |--/scss
       |--header.module.css
       |--mainNav.module.css
       |--footer.module.css
       |--elements.module.css
       // and so on...

Wir möchten den Header und Footer der Website gestalten, also öffnen wir die Komponenten Header.js und Footer.js im Starter und ersetzen den Code durch Folgendes

// src/components/Header.js
import React from "react"
import { graphql, Link, useStaticQuery } from "gatsby"
import Menu from "./menu"
import style from "../styles/scss/header.module.css"
import logo from '../images/gatsby-icon.png'

const Header = ( ) => {
  const { wp } = useStaticQuery(graphql`
    {
      wp {
        generalSettings {
          title
          description
        }
      }
    }
  `)
  return (
    <header className={style.masthead}>
      <div className={style.masthead_info}>

      <Link to="/">
        <img src={logo} alt="logo" width="100" height="100" display="inline-block" marginBottom= "0"  className={style.site_logo} />
      </Link>
      <div className={style.site_header} >
        <div className={style.site_title}>
          <Link
            to="/"
            dangerouslySetInnerHTML={{ __html: wp.generalSettings.title }} />
        </div>
        <div className={style.site_description} dangerouslySetInnerHTML={{ __html: wp.generalSettings.description }} /></div>

      </div>
      <Menu />
    </header>
  )
}

export default Header

Ebenso wurde die Komponente Footer.js wie folgt modifiziert

// src/components/Footer.js
import React from "react"

import style from "../styles/scss/footer.module.css"

export default () => (
  <footer className={style.colophon}>
    <p>© {new Date().getFullYear()} | This site is Powered by {'   ' } <a href="https://www.gatsbyjs.org">GatsbyJS</a> {'   and  '} <a href="https://www.wordpress.org">WordPress</a></p>
  </footer>
)

Starten wir jetzt unseren Entwicklungsserver neu. Wir sollten Folgendes sehen, einschließlich eines neuen, angepassten Headers und Footers. Ich habe den gleichen Stil wie in Learning Gatsby verwendet, einem Online-Kurs von Morten Rand-Hendriksen (ich bin ein Fan!).

Sie können den gesamten Code, den ich verwendet habe, über GitHub beziehen.

Was das alles für WordPress-Enthusiasten bedeutet

Es gibt viele Beiträge, die die Vor- und Nachteile einer entkoppelten WordPress- und Jamstack-Website wie die von uns behandelten Gatsby-Beispiele vergleichen. In meiner Recherche habe ich festgestellt, dass keiner von ihnen so ausführlich ist wie das, was Chris bereits in „WordPress and Jamstack“ geschrieben hat, wo er alles vergleicht, von Leistung und Funktionen bis hin zur Entwicklererfahrung und Build-Prozessen und darüber hinaus.

Ich fand die folgenden Artikel ziehen einige hilfreiche Schlussfolgerungen zu einer Vielzahl von Themen, darunter

Was sind die Kosten?

Die allgemeine Annahme ist, dass Jamstack-Hosting günstig ist und günstiger als herkömmliches LAMP-Stack-Hosting. Aber es gibt einiges zu bedenken und Ihre tatsächlichen Kosten können variieren.

• „How to Run Your WordPress Site On Local, Gatsby and Netlify for FREE!“ (Nate Fitch): Nate meint, dass ein Headless-WordPress-Setup wie dieses eine gute Option sein könnte, wenn das Projekt ein statischer Blog oder eine Website ist, die keine Interaktionen erfordert. Zum Beispiel würde es nicht viel Arbeit erfordern, Bilder auf Cloudinary oder einem anderen CDN zu hosten, aber für große, interaktive Websites wäre es aufwendiger.
• „WordPress and Jamstack“ (Chris Coyier): Hier gibt es einen speziellen Abschnitt, in dem Chris die Preise für verschiedene Hosting-Typen für Jamstack-Websites aufschlüsselt und warum eine pauschale Aussage wie „Jamstack ist günstiger“ nicht zutrifft, da die tatsächlichen Kosten von der Website und ihrer Nutzung abhängen.
• „Choosing between Netlify, Vercel and Digital Ocean“ von (Zell Liew): Zell diskutiert seine Erfahrungen bei der Auswahl eines Hosting-Plans. Seine Meinung: Wenn Sie ein kleines Projekt haben, wählen Sie Netlify; wenn Sie ein größeres Projekt haben, verwenden Sie Digital Ocean.

Warum überhaupt statisch sein?

Angesichts all dessen, was Sie in WordPress für „kostenlos“ erhalten – denken Sie an Kommentare, Plugins, Integrationen usw. –, fragen Sie sich vielleicht, ob es sich überhaupt lohnt, ein serverseitiges Setup gegen eine clientseitige Lösung einzutauschen. In seinem Beitrag „Static or Not?“ erläutert Chris die Gründe, warum man das eine dem anderen vorziehen sollte.

Wie bekommen wir Kommentarfunktionalität?

Mit WordPress erhalten wir native Kommentare direkt von Haus aus. Dennoch ist die Unterstützung für Kommentare auf einer statischen Website ein ziemlicher Brocken. In „JAMstack Comments“ hier auf CSS-Tricks erklärt der Autor, wie dynamische Kommentare in einer statischen Website wie Gatsby mithilfe von Netlify-Diensten implementiert werden können. Ich habe dies in meinem vorherigen Artikel kurz angesprochen.

Was ist mit SEO?

• „Gatsby SEO For WpGraphQL and Yoast“ (Gatsby Community Plugin): Das weit verbreitete Plugin Yoast SEO für WordPress kann mit diesem Plugin in ein Gatsby-Frontend integriert werden.
• „A primer on JavaScript SEO for WordPress“ (Jono Alderson): Dieser umfassende Leitfaden enthält einen Abschnitt darüber, wie Yoast SEO in eine Headless-Architektur integriert wird und welche Auswirkungen es hat, sich für SEO auf JavaScript zu verlassen. Die Quintessenz ist, dass Theme- und Plugin-Entwickler sich keine großen Sorgen über die sich verändernde Landschaft von JavaScript und SEO machen sollten, solange sie weiterhin Best Practices befolgen. Gleichzeitig sollten sie sich bewusst sein, was sich ändert, und sich entsprechend anpassen.

Wie funktioniert das alles zusammen?

• „Gutenberg and Decoupled Applications“ (Jason Bahl): Jason ist der Ersteller und Maintainer von WPGraphQL und befasst sich eingehend mit der Verwendung des neueren WordPress Block Editors in einer entkoppelten Anwendung.
• „Jason Bahl of WPGraphQL’s role in the operating system for the web“ (YouTube): Hier ist Jason wieder, diesmal spricht er über Templating. Er behandelt die Rolle von WPGraphQL im WordPress-Ökosystem und in Headless-Gatsby-Sites und betont, dass es bei WPGraphQL wie bei der WordPress REST API um Datenexposition geht. Wie WPGraphQL WordPress-Daten in Gatsby exponiert und in React-Komponenten im Frontend anzeigt, liegt in der Verantwortung der Entwickler.

Derzeit gibt es keine Gatsby-React-Vorlagen, die sich an Nicht-Entwickler richten, aber einige Agenturen, wie Gatsby WP Themes und der Themeforest-Marktplatz, beginnen, diese Lücke zu füllen. Zum Beispiel deckt Gatsby WP Themes Plugins für dynamische Inhalte wie MailChimp-Integration ab, verwendet das Contact Form 7 Plugin für Formulare, Yoast SEO und mehr. Themeforest listet über 30 Gatsby-Vorlagen, darunter das Gatsby – WordPress + eCommerce Theme, das Ihnen eine Vorstellung davon gibt, wie weit wir mit dieser Art von Setup gehen können. Denken Sie daran: Dies sind kommerzielle Seiten, und vieles, was Sie finden werden, ist mit Kosten verbunden.

Meine sich entwickelnde persönliche Einschätzung

Wenn Sie sich erinnern, habe ich meinen letzten Artikel mit einer persönlichen Reflexion über meine Reise zum Erstellen einer Headless-WordPress-Site mit Gatsby als Frontend beendet. Meine anfängliche Einschätzung war nicht gerade ein glänzendes Zeugnis.

Basierend auf meiner sehr begrenzten Erfahrung denke ich, dass die derzeit verfügbaren Gatsby WordPress Themes für Benutzer wie mich noch nicht einsatzbereit sind. Ja, es ist aufregend, etwas am Puls der Zeit auszuprobieren, das vielen WordPress-Benutzern und Entwicklern am Herzen liegt. Gleichzeitig erschwert die ständig fortschreitende Arbeit am WordPress Block Editor, WPGraphQL und den Gatsby Source WordPress Plugins, die Vorhersage, wohin die Reise geht und wann ein sicherer Einsatz in anderen Kontexten möglich sein wird.

Also, nach all dieser langen Reise zu einer Headless-WordPress-Site, was ist meine Einschätzung jetzt? Als aufgeschlossener Lerner entwickeln sich meine Gedanken immer noch weiter. Aber ich stimme Chris in seinem Beitrag „Static or Not?“ voll und ganz zu.

Es ist eine absolut akzeptable und oft clevere Wahl, eine WordPress-Site zu betreiben. Ich denke dabei an Robustheit und Bereitschaft für neue Features. Benötigen Sie E-Commerce? Es ist da. Benötigen Sie Formulare? Es gibt großartige Plugins. Müssen Sie die Funktionsweise des CMS erweitern? Sie haben die Kontrolle über die Inhaltstypen und deren Inhalte. Benötigen Sie Authentifizierung? Das ist eine Kernfunktion. Wünschen Sie sich eine großartige Bearbeitungserfahrung? Gutenberg ist glorreich.

Ich bin ein WordPress-Enthusiast und liebe WordPress als CMS. Als technologische Lernherausforderung habe ich jedoch noch nicht aufgegeben, eine entkoppelte WordPress-Site als persönliches Projekt zu realisieren.

Ich muss zugeben, dass das Erlernen der Erstellung einer entkoppelten Gatsby-Site mit WordPress weiterhin frustrierend war. Ich erkenne an, dass jeder moderne Technologie-Stack für viele WordPress-Benutzer keine leichte Kost ist. Gatsby hat eine steile Lernkurve, da diese Stacks für erfahrene React- und JavaScript-Entwickler gedacht sind.

Das Selbststudium einer neuen Technologie kann frustrierend sein. Das Erlernen von Gatsby ist besonders frustrierend, wenn wir (einschließlich meiner selbst) keine Erfahrung mit Node, React, JavaScript und vor allem GraphQL haben. Meine Lernprojekt-Websites brachen wegen irgendeiner Abhängigkeit zusammen und die Behebung dauerte oft mehrere Tage Recherche. Manchmal frage ich mich, ob der Aufwand den Ertrag wert ist. Verstehen Sie mich nicht falsch; meine Frustration liegt an meiner eigenen mangelnden Erfahrung, nicht an den Frameworks selbst (denn sie sind erstaunlich).

Sogar erfahrene Entwickler wie David Cramer und Jared Palmer finden die Verwendung von Gatsby und GraphQL frustrierend und teilen einige der gleichen Gefühle, mit denen wir Anfänger bei der Verwendung von GraphQL konfrontiert sind. Ich stimme David vollkommen zu, der schreibt:

Es ist ein statischer Website-Generator. Er braucht buchstäblich nicht überall GraphQL. Während es nur wenige Instanzen in der realen Welt gibt, in denen dies wertvoll ist, sollte es keine GraphQL-API erfordern, um Objekte zu lesen, die bereits im Speicher vorhanden sind.

GraphQL ist eine meinungsstarke Abfragesprache-API und ihre Spezifikationen ändern sich häufig. Tatsächlich beziehen sich die meisten Diskussionen im WPGraphQL Slack auf Abfragen.

Während der Arbeit an diesem Projekt stieß ich auf das Frontity React Framework, als ich einen Artikel auf CSS-Tricks las. Es ruft alle WordPress-Daten mit der REST API ab, ohne eine einzige Abfrage schreiben zu müssen. Das scheint eine bessere Option zu sein, zumindest für meinen Anwendungsfall. Außerdem scheint es eine deutlich einfachere Alternative zu sein. In meiner kurzen Erfahrung damit hatte ich überhaupt keine Probleme mit Abhängigkeiten oder Bibliotheken. Das Themes-Konzept von Frontity ist sehr WordPress-artig und bietet ausgezeichnete Tutorials.

Ich untersuche derzeit, ob das Frontity Framework eine bessere Option für meine entkoppelte Projekt-Website wäre, und werde meine Erfahrungen in einem zukünftigen Artikel teilen.

Ressourcen

Gatsby scheint sich an erfahrene React- und JavaScript-Entwickler zu richten, nicht an Anfänger wie mich! Die Plugins gatsby-source-wordpress und gatsby-source-wpgraphql leisten hervorragende Arbeit, um WordPress-Daten in Gatsby-Sites verfügbar zu machen, aber der Rest liegt bei den Benutzern, die Daten im Frontend mit ihrem gewählten Framework darzustellen: React, Vue, Next, etc.

Ein Mangel an fundiertem Wissen in React und JavaScript ist das Haupthindernis für Anfänger. Die Gatsby-Community schließt viele dieser Lücken, und es gibt viele Ressourcen, um weiter zu lernen und zu erkunden.

Gatsby Conference 2021 Vorträge

Zwei Workshop-Vorträge von der kürzlich stattgefundenen 2021 Gatsby Conference bezogen sich auf Gatsby WordPress-Websites. In einem veranstaltet Jason Bahl einen Workshop, der erklärt, wie man einen Gatsby-Blog mit WordPress-Daten erstellt, einschließlich Unterstützung für das Yoast SEO-Plugin, und wie man die Website auf Gatsby Cloud bereitstellt.

Es gibt einen weiteren Workshop, der von Matt Landers von WP Engine veranstaltet wird, bei dem er zeigt, wie man die Einrichtung mithilfe des Advanced Custom Fields Plugin vornimmt, um eine Teammitgliedseite zu erstellen.

Beide Vorträge sind gut, besonders wenn Sie besser durch praktische Erfahrung lernen. Ich habe auch diese Matt Report Podcast-Episode mit Jason Bahl gefunden, in der Jason grundlegende Fragen für Anfänger beantwortet.

Tutorial-Kurse

Morten Rand-Hendriksen hat einen ausgezeichneten Kurs auf LinkedIn Learning, der das Gatsby Source WordPress Plugin verwendet. Wenn Sie mehr praktische Erfahrung mit der Erstellung einer benutzerdefinierten Website sammeln möchten, die auf den beiden zuvor erwähnten Gatsby-Startern aufbaut, ist dieser Kurs großartig, da er lehrt, wie man eine vollständige, funktionierende Website erstellt, komplett mit einer Dropdown-Header-Navigation, Footer-Menüs, Beiträgen, Seiten, Kategorien, Tags und Seiten-Navigation.

Die Übungsdateien für den Kurs sind im GitHub LinkedIn Learning Repository verfügbar.

Gatsby-Starter

Zum Zeitpunkt des Schreibens gibt es zehn Gatsby-Starter für WordPress. Wie bereits erwähnt, basiert nur Gatsby Starter WordPress Twenty Twenty auf der neuesten Version des Gatsby Source WordPress Plugins; die restlichen sind Version 3.

---

Danke fürs Lesen. Ich bin immer daran interessiert zu erfahren, wie andere WordPress-Benutzer, denen es wie mir an starker technischer Erfahrung mangelt, dieses Plugin verwenden. Wenn Sie Feedback haben, können Sie es gerne in den Kommentaren hinterlassen.