For years I’ve developed WordPress sites by creating themes and plugins coupled to the WordPress platform. This is a great approach when you’re looking to use features that WordPress have built-in to its codebase. When it came to building my own website however… I wanted to experiment.

In this article I’m going to talk about how I developed using GatsbyJS, WordPress, and Netlify.

Website Architecture

I had a few initial requirements for the site, some based on personal preference;

  • I wanted to use the WordPress admin panel to manage my content. I find the user interface quite nice, and I’m so familiar with WordPress that it would make content population easy.
  • I wanted to keep the CMS and frontend decoupled. This idea of separation of concerns is quite common, and it helps to keep things interchangeable. In the future if I wanted to switch out WordPress for a different CMS I could with minimal effort, and same goes for the frontend.
  • I wanted the frontend to be fast…really fast…blazing fast! One thing in particular I wanted to have was client-side routing, as I find it improves perceived performance.

Welcome GatsbyJS

Blazing-fast static site generator for React

GatsbyJS is one of the most popular static site generators for React. It takes your React code, and GraphQL data, and builds static HTML files that can be hosted anywhere. A few cool features of Gatsby include;

  • Tons of community-built plugins and site starters to help during development.
  • Server-side rendering (thanks to the whole static site generating part).
  • Client-side routing with the help of the gatsby-link package.
  • Optimised images with the gatsby-image package (this one really blew my mind).

I highly recommend you check out their tutorial to get a glimpse of the awesomeness.

It’s worth noting that Gatsby is also an open source project, so not only is it free to use, but you can also contribute towards the project. Open source FTW!

For the purposes of my site, I setup Gatsby to pull data from my WordPress CMS by configuring the gatsby-source-wordpress plugin. This plugin uses the WordPress REST API to retrieve data, and out of the box has support for; custom post types, ACF fields, media files, and much more.

So that’s the frontend sorted, now I needed to get WordPress up and running.

WordPress Setup

This part was relatively straight forward. From my initial research I knew I was going to be using Netlify to host the site’s frontend, so I needed somewhere to put my WordPress instance.

I spun up a droplet using DigitalOcean and used their WordPress One-Click Install to get me a WordPress instance running in about 5 minutes. The WordPress side of things didn’t need to be fast at all, in fact I used the cheapest $5 droplet that DigitalOcean offers. This is because Gatsby pulls the data from WordPress during a gatsby build, so the only potential impact would be on build time.

When it comes to building WordPress sites, I’m a huge fan of ACF. In particular, I like using flexible content fields and creating a sort of page builder experience. To get flexible content fields working with Gatsby, I ended up installing the ACF to REST API WordPress plugin. This exposes a bunch of ACF data to the WordPress REST API, which Gatsby was then able to query. I also installed WP API Menus to be able to query WordPress menus from Gatsby.

Along with menus and custom fields, I also wanted the ability to query settings within WordPress. This feature wasn’t available in the gatsby-source-wordpress plugin, but thanks to the power of open source I was able to create a GitHub pull request and implement this feature myself. Within 24 hours the code was merged and I could query the settings fields.

At this stage I was pretty pleased with the tech stack, but I needed a way to get the site online. That’s where Netlify came in.

Netlify – Build, deploy, and manage

Now before I dive into how amazing Netlify is, I want to briefly explain my old normal way of working. I’ll use Git on every project, even when it’s just me on the dev team. I’ll either run Git flow, or for simple projects just commit straight into master. Either way, I’d be storing my code in a version controlled system. From there, I’d do one of two things to get the code online;

  1. Good old fashioned FTP, using something like FileZilla to manually upload the files to production.
  2. Setup a bare git repo on a server, and then configure an alternative git remote to push to. Something like git push live master.

Both of these options work, but they have their downfalls. Option 1 is way too much manual work. Sure these FTP clients have nice user interfaces and easy drag-n-drop functionality, but we’re developers, we want to automate this kind of stuff.

Option 2 is the nicer of the two. There’s a bit of upfront work involved to create the empty repo on the server, and then configure a post-receive git hook by writing a shell script, and yadda yadda yadda. But don’t get me wrong, once it’s setup it works really well.

I heard about Netlify back in March when one of their employees (Phil Hawksworth) spoke about it on a ShopTalk Show podcast. Bit of a side note, but ShopTalk Show is an awesome podcast where Chris Coyier and Dave Rupert just talk all things frontend web related, definitely worth checking out. Anyway, Phil and the guys spoke about how easy it is to build and deploy static sites using Netlify, so I decided to give it a go.

Once I created an account, I was able to authenticate Netlify with my Git repositories (in this scenario it was Bitbucket, but Github works the same) and configure a couple build and deploy options, then I was ready to rock. Netlify took care of continuous deployments by building the production code, and deploying the site to their free to use global CDN.

I was pretty taken aback by just how impressive Netlify is. I’ve built, and hosted, dozens of websites over the years but never had a piece of software that takes all the hassle out of building, deploying, and managing a website! I can’t recommend enough that you try out Netlify. Seriously, just setup a basic site and link the Git repository to Netlify and check out how easy it is. SSL certificate in one click, the ability to preview deployments before pushing changes, and a super sleek app dashboard. All of this is available on their free tier pricing as well.

Challenges I faced with this stack

As with most projects, there were a few challenges I had to overcome. Let’s take a look at the main ones.

Netlify wasn’t triggering builds when WordPress content changes

I didn’t really notice this until I started doing content population, but it made complete sense. Netlify knew about the code in the git repository, but WordPress wasn’t in there. After a little digging I came across another feature of Netlify that turned out to be the solution – Webhooks. Setting up an incoming webhook will give you a unique URL that will trigger a build. So all I had to do was hit this endpoint whenever content was changed in WordPress. This action in the WordPress functions.php did the trick;

// Trigger Netlify Build on content change
add_action( 'save_post', 'fireFunctionOnSave' );
function fireFunctionOnSave($post_id) {
  if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
  $response = Requests::post( 'NETLIFY_BUILD_HOOK' );

Getting ACF Flexible Content in Gatsby using GraphQL

After setting up the flexible content fields in WordPress, and installing the ACF to REST API WordPress plugin, I was still struggling to query the fields using GraphQL. I could see that the WordPress API was exposing the data, so the issue looked to be in Gatsby. Fortunately Gatsby comes with GraphiQL. GraphiQL is the GraphQL integrated development environment, that makes it super easy to query data and see the output instantly. After a while I figured out that you can query data from flexible content by creating GraphQL fragments.

In the screenshot above I created a page query for flexible content fields content_page and outputted the field __typename. GraphQL allows you to request __typename, a meta field, at any point in a query to get the name of the object type at that point. From there, I created a Hero fragment for the object type, which allowed me to query fields in the object type.

Handling Form Data with Gatsby and WordPress

Almost every website has some form of data capturing. For most WordPress sites I like to setup Contact Form 7 to handle form submissions, as it does a great job of sending out confirmation emails, and also storing the data with extensions like Flamingo.

The WordPress REST API isn’t just for querying, you can also post data to endpoints. Contact Form 7 has its own API endpoints, and you can post form data to wp-json/contact-form-7/v1/contact-forms/{ID}/feedback to send form submissions. I did exactly that from within Gatsby, and form submissions continued to be stored and handled within WordPress along with the content. Perfect!


I really feel like this tech stack has given me the best of both worlds; I get to keep using WordPress to manage my content, and write the frontend of my website using React. Netlify was really the icing on the cake, and I’m not sure I’ll ever be able to go back to the old manual FTP way of working.

The amount of time and effort involved was greater than normal theme development in WordPress, which may have been partly due to my lack of experience with this type of stack. It was a great learning experience however, and I’m incredibly pleased with the end result (this website).