?
     

  )
}
export default PostEntry
Step 4: Create an (optional) image component
The Gatsby default starter comes with an Image component and that works just fine in most case. In this example, we’re fetching the image file used as the post’s featured image in WordPress and assign it a fallback image in case there is no featured image as described in Henrik’s guide.
// src/components/Image.js
import React from react
import { useStaticQuery, graphql } from gatsby
?
const Image = ({ image, withFallback = false, …props }) => {
  const data = useStaticQuery(graphql`
    query {
      fallBackImage: file(relativePath: { eq: fallback.svg }) {
        publicURL
      }
    }
  `)
?
  /* Fallback image */
  if (!image) {
    return withFallback ? : null
  }
?
  return
}
?
export default Image
If withFallback is set to false (like it is in the default Gatsby component file), then it will simply not render a DOM element.
Step 5: Create a Pagination component
The Pagination component allows us to display specified number of posts per page in the post index. WordPress has two types of pagination one that returns Next and Previous links to navigate between pages one at a time, and one that provides linked page numbers. We’re working with the former in this component:
// src/components/Pagination.js
import React from react
import { Link } from gatsby
import { blogURI } from ../../globals
?
const Pagination = ({ pageNumber, hasNextPage }) => {
  if (pageNumber === 1 && !hasNextPage) return null
?
  return (
   

  )
}
?
export default Pagination
There is a conditional statement on Line 7 that returns null if pageNumber === 1 && !hasNextPage. In other words, if the current page’s hasPageNumber is greater than 1, the Previous button (Lines 13-24) will display. Similarly, when the current page’s hasNextPage is at least 1, then the Next button (Lines 30-42) will display.
Step 6: Refactoring createPages
We need to clean up the createPages.js file to reflect all the work we’ve done since creating the file. The file simply becomes too big with everything it’s tracking. To keep our code organized and structured, we can use GraphQL fragments, which allow us “to split up complex queries into smaller, easier to understand components,” according to the documentation.
GraphQL fragments are reusable units which allows to construct sets of fields, and then include them in queries wherever needed.
If we follow Henrik’s guide, the GraphQL query fields for the post template and post preview are stored in the data.js file:
// src/templates/posts/data.js
const PostTemplateFragment = `
  fragment PostTemplateFragment on WPGraphQL_Post {
    id
    postId
    title
    content
    link
    featuredImage {
      sourceUrl
    }
    categories {
      nodes {
        name
        slug
        id
      }
    }
    tags {
      nodes {
        slug
        name
        id
      }
    }
    author {
      name
      slug
    }
  }
`
?
const BlogPreviewFragment = `
  fragment BlogPreviewFragment on WPGraphQL_Post {
    id
    postId
    title
    uri
    date
    slug
    excerpt
    content
    featuredImage {
      sourceUrl
    }
    author {
      name
      slug
    }
  }
`
?
module.exports.PostTemplateFragment = PostTemplateFragment
module.exports.BlogPreviewFragment = BlogPreviewFragment
Next, refactoring the create/createPosts.js file as described in the guide requires adding the following code at the top section of createPosts.js (Lines 2-10), just above the const = GET_POSTS=` query statement on Line 4.
// create/createPosts.js
const {
  PostTemplateFragment,
  BlogPreviewFragment,
} = require(../src/templates/posts/data.js)
?
const { blogURI } = require(../globals)
?
const postTemplate = require.resolve(../src/templates/posts/index.js)
const blogTemplate = require.resolve(../src/templates/posts/blog.js)
?
const GET_POSTS = `
  # Here we make use of the imported fragments which are referenced above
  ${PostTemplateFragment}
  ${BlogPreviewFragment}
  query GET_POSTS($first:Int $after:String) {
    wpgraphql {
      posts(
       first: $first
       after: $after
       # This will make sure to only get the parent nodes and no children
       where: {
         parent: null
       }
      ) {
         pageInfo {
           hasNextPage
           endCursor
         }
         nodes {
           uri
?
           # This is the fragment used for the Post Template
           …PostTemplateFragment
?
           #This is the fragment used for the blog preview on archive pages
          …BlogPreviewFragment
        }
      }
    }
 }
`
Here, the fragment strings created in the previous steps (Lines 9-10) are imported and registered outside the GET_POSTS query (Line 12) and used as fragments (Lines 34 and 37 ) inside the GET_POSTS($first:Int $after:String) query.
At the bottom of the createPosts.js file, the blogPage path is defined with global blogURI variable (Lines 36-41) and we’ve added the code to create paginated blog pages (Lines 99-111).
// create/createPosts.js
// Previous code excluded
?
const allPosts = []
const blogPages = [];
let pageNumber = 0;
const itemsPerPage = 10;
?
/** This is the export which Gatbsy will use to process.
 * @param { actions, graphql }
 * @returns {Promise} */
module.exports = async ({ actions, graphql, reporter }, options) => {
?
  /** This is the method from Gatsby that were going
   * to use to create posts in our static site */
  const { createPage } = actions
?
  /** Fetch posts method. This accepts variables to alter
   * the query. The variable `first` controls how many items to
   * request per fetch and the `after` controls where to start in
   * the dataset.
   * @param variables
   * @returns {Promise<*>} */
  const fetchPosts = async (variables) =>
    /** Fetch posts using the GET_POSTS query and the variables passed in */
    await graphql(GET_POSTS, variables).then(({ data }) => {
      /** Extract the data from the GraphQL query results */
      const {
        wpgraphql: {
          posts: {
            nodes,
            pageInfo: { hasNextPage, endCursor },
          },
        },
      } = data
?
      /** Define the path for the paginated blog page.
       * This is the url the page will live at
       * @type {string} */
      const blogPagePath = !variables.after
        ? `${blogURI}/`
        : `${blogURI}/page/${pageNumber + 1}`
?
      /** Add config for the blogPage to the blogPage array for creating later
       * @type {{
       *   path: string,
       *   component: string,
       *   context: {nodes: *, pageNumber: number, hasNextPage: *} }} */
      blogPages[pageNumber] = {
        path: blogPagePath,
        component: blogTemplate,
        context: {
          nodes,
          pageNumber: pageNumber + 1,
          hasNextPage,
          itemsPerPage,
          allPosts,
        },
      }
?
      /** Map over the posts for later creation */
      nodes
      && nodes.map((posts) => {
        allPosts.push(posts)
      })
?
     /** If theres another post, fetch more so we can have all the data we need */
      if (hasNextPage) {
        pageNumber++
        reporter.info(`fetch post ${pageNumber} of posts…`)
        return fetchPosts({ first: itemsPerPage, after: endCursor })
      }
?
      /** Once were done, return all the posts so we can
       * create the necessary posts with all the data on hand */
      return allPosts
    })
?
  /** Kick off our `fetchPosts` method which will get us all
   * the posts we need to create individual posts */
  await fetchPosts({ first: itemsPerPage, after: null }).then((wpPosts) => {
?
    wpPosts && wpPosts.map((post) => {
      /** Build post path based of theme blogURI setting */
      const path = `${blogURI}${post.uri}`
?
      createPage({
        path: path,
        component: postTemplate,
        context: {
          post: post,
        },
      })
?
      reporter.info(`post created:  ${path}`)
    })
?
    reporter.info(`# —–> POSTS TOTAL: ${wpPosts.length}`)
?
    /** Map over the `blogPages` array to create the
     * paginated blog pages */
    blogPages
    && blogPages.map((blogPage) => {
      if (blogPage.context.pageNumber === 1) {
        blogPage.context.publisher = true;
        blogPage.context.label = blogPage.path.replace(/, );
      }
      createPage(blogPage);
      reporter.info(`created blog archive page ${blogPage.context.pageNumber}`);
    });
  })
}
The final updated create/createPosts.js and create/createPage.js files are available in this GitHub repository.
In his Twenty Nineteen porting tutorial post, Muhammad describes in great detail how static pages created with Gatsby’s createPage use nearly the same code and file structure used in this example. Nice to see some consistency forming between our references.
After re-starting local server with gatsby develop, we should display a screen in our browser now showing a loop of our published posts, containing the post title and excerpt.

Section 5: Styling and deployment
While styling, typography and deployment are all beyond the scope of what we’re covering here, we can touch on them a bit. The Gatsby’s documentation provides excellent resources on both styling and deployment/hosting options.
Basic site styling
Gatsby’s documentation is grouped by global CSS files, modular stylesheets and CSS-in-JS. There are other styling options available, including Typograpgy.js, Sass, JSS, Stylus and PostCSS.
While porting the Twenty Nineteen WordPress theme to Gatsby, Muhammad includes the theme’s styles so they can be used over on the Gatsby site. He cautions that some adjustments are needed since some units and values are incompatible with Gatsby. For example, he had to adjust vw units in CSS to use them with flexbox for some components. Similarly, porting Twenty Twenty theme to Gatsby, Henrik followed a similar process in his Gatsby starter -Twenty Twenty by porting over the Twenty Twenty stylesheet as well as fonts.
I decided to use Sass in my project. That requires installing gatsby-plugin-sass and its required node-sass dependency:
#! install node-sass & gatsby-sass
yarn add node-sass gatsby-plugin-sass
#! or with npm
npm install –save node-sass gatsby-plugin-sass
Then the plugin can be added to gatsby-config.js and configured as shown here.
// gatsby-config.js
module.exports = {
  siteMetadata: {
    plugins: [
      `gatsby-plugin-sass`
    ],
  }
}
Now we can write styles in .scss files and import them as we normally would in any other Sass project.
// using import in a component file
import(./src/styles/global.scss)
?
// using require in the gatsby-browser.js file
require(./src/styles/global.scss)
The .scss stylesheet can be imported by the global component or added in gatsby-browser.js with a require statement. For this demo project, I’m using Gatsby’s default styling for the main page and I simply left post content as is. I refactored the Header.js file a bit with some very basic styling.
//src/components/Header.js
import { Link } from gatsby
import PropTypes from prop-types
import React from react
import useSiteMetadata from ../components/siteMetadata;
import Menu from ./Menu
import ../styles/header.css
?
const Header = () =>{
  const { title } = useSiteMetadata();
?
  return (
   

)
}
?
Header.propTypes = {
  siteTitle: PropTypes.string,
  description: PropTypes.string,
}
?
Header.defaultProps = {
  siteTitle: “,
  description: “,
}
?
export default Header
This should give us the site header when we restart the server with gatsby develop.

Supporting WordPress block styles
I’m assuming you’re well familiar with the WordPress block editor if you’ve made it this far and know how blocks generally work. Since releasing the block editor, WordPress has maintained a separate set of styles specifically for block content.
That means we need an extra step to port those over to Gatsby with the theme styles. Jason Lengstorf demonstrates in his tutorial guide. First, the WordPress blocks package is installed:
# install wordpress/block-library
npm install @wordpress/block-library
# with yarn add
yarn add @wordpress/block-library
Then we can import those styles into a Gatsby component. Let’s go with the component:
// src/components/layout.js
import React from react
  import { Link } from gatsby
?
import @wordpress/block-library/build-style/style.css
  import ../styles/layout.css
?
const Layout = ({ children }) => {
  return (
   

  )
}
?
export default Layout
The block editor is still very much in active development, which means things are prone to change, perhaps unexpectedly. So, definitely proceed with caution if you’re planning to use them.
Site deployment
We’ve talked a bit about deployment when I explained why I chose Netlify, I chose it because it hooks into the project’s GitHub repo and deploys automatically when pushing to a specific branch, thanks to Netlify Functions.
Netlify has a nice steop-by-step guide that covers how to connect a Gatsby site to Netlify. The Gatsby Doc also describes deploying to Netlify.
Finally, link to my own Netlify deployed demo site.
Again, this gives us continuous deployment where the site rebuilds automatically when changes are pushed to the repo. If we want a similar process whenever changes are made in WordPress — like publishing a post or editing a page — then the JAMstack Deployments plugin can be used as described in Jason’s guide.
This is still a work in progress!
While what I’ve learned in the process of porting a WordPress theme to Gatsby is great for constructing the basic building blocks of a blog, I’ve realized that there is still a lot of work to cover. I mean, WordPress stores so much data, including authors, categories, tags, post statuses, custom post types, and so much more, that all take extra consideration.
But there’s a growing list of decoupled Gatsby WordPress site examples, some of which I’ll list below for reference. Henrik’s an awesome list of WordPress-Gatsby resources is super helpful to learn more about the WordPress-Gatsby decoupling.
twentynineteen-gatsby-theme (demo site)gatsby-starter (demo site)Gatsby WordPress theme blog (demo site)gatsby-theme-wp-source-oneAn awesome list of WordPress-Gatsby resources by Henrik Wirth (view on GitHub)GitHub – Discussion on future of WordPress with Gatsby by Tyler Barnes
Credits 
I know I mentioned it throughout this post, but a big shout out to Henrick Wirth, Jason Lengstorf and Muhammad Muhsin for all the work they’ve done to document and share what it takes to port WordPress to Gatsby. Everything I’ve covered here is merely the accumulation of their fine work and I appreciate each of them for creating such helpful guides suitable even for beginners like myself. I owe a special thank you to our own Geoff Graham from CSS-Tricks for editing this article.