Where’s Your Head At?

I started using Gatsby around a year ago, partly because I wanted to practice developing with React. After a little tinkering, I began to realise just how effective GatsbyJS is and the enormous amount of advantages its ecosystem provides. If you’re unaware, then this link provides a thorough overview.

http://www.gatsbyjs.com

For those that don’t know, the Gatsby ecosystem provides many different types of “source” plugins. These are easy to configure, and they convert a particular data source, whether it’s local files or an endpoint URL, such as WordPress, Drupal or Contentful into a GraphQL Schema that Gatsby can then query. 

Gatsby & Headless WordPress

Disclaimer: This post explains some of the problems I had using gatsby-wordpress-source@version3. However, I recently updated to what will become gatsby-wordpress-source-version4, and there are massive upgrades. I recently attended the talk “WordPress without the Worry: Going Headless with Gatsby”. Register here to view the recording.

I figured perhaps it would be worth making some notes of the problems I had with the old version of the Plugin and where the “worry” in the title of that talk came from. If you want to go straight to the new stuff go here

At the beginning of the year, I decided I wanted to build a personal blog with Gatsby and WordPress. Why WordPress? I hear you ask. From my perspective, it’s a CMS that I know well. I’m no WP Sage, but I have built themes and plugins. I have an understanding of the WP/Core, action and filter hooks as well as the Theme and plugin ecosystem. From a more technical perspective, it’s very well supported, commonly used and going through some evolutionary changes of its own as the Gutenberg Block Editor, also built with React, is coming up to its second birthday this December.

I created some prototypes at the beginning of the year with mixed results. Sure, a lot of this was partly down to my inexperience with GatsbyJS. But some of the problems were difficult to predict. For example, using the same media as a featured image of multiple posts could change the parent_id of the media, causing a GraphQL query that relied on that data to fail and consequently, a failed Gatsby Build. Sneaky errors seemed to pop up a little too often. These issues were partly down to how the WordPress-REST API works behind the scenes.

These problems had various solutions. EG, Fixing the WordPress Rest endpoint or using the gatsby-node.js API to manage nullable node types, which would could then come back and trip up the Frontend. It’s then you begin to realise how closely coupled your WordPress and Gatsby are. And that it would require careful planning to allow a content manager to maintain the site on their own. Images and internal links within the editor would further complicate and constrain projects. For example, if you wanted to integrate the gatsby-image-sharp plugin to optimise images.

While enjoying the process, I wasn’t sure it was something I would feel comfortable leaving in the hands of a client. There were too many things in the WordPress backend that could cause a build to fail. Not only that, but there are things WordPress content creators should be aware of regarding the cost, when and what causes site rebuilds. It’s not that I was too disappointed, I had great fun setting it up. However, I was beginning to wonder how useful WordPress would be as a Gatsby source and what alternatives were available. After all, claiming to create fast, efficient and amazing websites doesn’t sound so great if it has extra difficulties and takes a long time.

Then WPGraphQL and gatsby-source-wordpress-experimental came along and completely changed the game for the better. If you want to find out more, and if you’ve read this far, you really should! Then read part two here.