Back when Gatsby first launched we produced all of our content — including blog, landing pages, and documentation — in a public GitHub repo. That approach just made sense for an open-source software company where most of the team were web developers. And it worked fine…For a while.
As the team grew and added staff from different disciplines (marketing, events, HR, etc), however, this workflow became less ideal. Not everyone was equally comfortable with the command line or writing their content in MDX markdown files. Additionally, as the number of content contributors and collaborators grew, publishing a blog via pull request began to require too many handoffs between an ever-increasing number of stakeholders. It was clear that we needed to adopt a CMS to manage content for our blog.
We settled on headless WordPress and the results have been fantastic. In the past, our GitHub publishing workflow could take up to a full day start to finish. Today many people at Gatsby collaborate on blog content creation, and the entire publishing process now takes less than 30 minutes!
Why headless WordPress?
We had a lively debate within Gatsby about which CMS to adopt. Because of our ecosystem of 2,600+ Gatsby plugins, we were spoiled with the riches of choice. We could use an open-source CMS like Ghost, Drupal, or Strapi. Or we could stick with MDX files and use Forestry or Netlify CMS. We could go for a fully featured headless CMS like Contentful (which we actually do use to manage our site landing pages). Or we could use an upstart like Sanity, Dato, or Cosmic. Heck – we could even source content from Airtable and MongoDB! Believe me, we talked about all of them.
For our engineers, every CMS was the same thanks to Gatsby’s GraphQL data layer. This also meant that Marketing’s choice for a CMS wouldn’t impact other teams: The docs team could keep using markdown, and the Gatsby Cloud team could still use Contentful for landing pages. Thanks to GraphQL, our engineers could pull data from all of those sources into a unified front-end, using the same design system, same analytics, same everything. And thanks to Incremental Builds when one CMS updates, only those affected pages will change. So publishing a new article from the blog doesn’t slow down Gatsby Cloud users receiving a new feature or trigger a full rebuild of the entire monorepo. Ultimately, Gatsby’s marketing team was free to choose what best suited us.
So, what was the deciding factor for WordPress? The Gatsby blog has content from 133 authors. We’ve published articles from our community, technology partners, and staff members. WordPress enables us to have unlimited users (without paying a subscription per seat). WordPress also comes with powerful role-based permissions and has free plugins from services like Auth0 to unlock flexible security and authentication options. Those features made WordPress a perfect fit for our particular use case.
Unlocking a faster workflow
Switching to WordPress dramatically sped up our content production time. We went from sometimes spending a full work day publishing content to just a few minutes.
Our old process required building the entire Gatsby site locally, formatting Word docs to Markdown, updating different files for the content and author profile, then submitting a Pull Request and massaging the updates to pass a series of automated tests. I can tell you war stories of spending hours to fix a single typo, because even a small change retriggered that full process.
It’s different today. This article you are reading was copy/pasted from Google Docs to a rich text editor in WordPress. I spent a minute or two adjusting the formatting, then sent it to my colleague for review. From there she edited, then published it, and Gatsby Cloud built the new pages in seconds.
If there’s a typo we didn’t catch, it’s a simple and fast fix. Our headless WordPress and Gatsby architecture is just as fast, easy, and seamless as any all-in-one CMS.
Page builder bonus
We also lucked into a benefit that I didn’t expect. When our colleague Kyle Gill set up the content model in WordPress using the Advanced Custom Fields (ACF) plugin, he gifted us with a mini-page builder that makes laying out content really easy. He activated the Flexible Content Field for ACF and tied the fields in the editor to Gatsby front-end components. Now, our content editors can embed a video, style a pullquote, or even publish a form using simple fields. We can even drag-and-drop the fields to reorder our layout!
This is a powerful pattern that I hope other front end developers emulate for their content teams. You can learn more about this in Josh Comeau’s “Empowered Workflows with Gatsby” talk at Gatsby Days.
Inviting the community
We’re still in phase one of our migration to WordPress. Beyond the blog, we are also working on using WordPress to collect and manage community submissions to our site showcase. Once that is ready to ship, you will be able to submit your Gatsby site through a form. Then, through the power of GraphQL mutations, and WPGraphQL, the submission will be automatically captured in WordPress, then edited and published.
After that I imagine we can open up other community participation use cases, like commenting on blog posts!
Thinking about future features is great but our migration to WordPress has already been a massive success. We spend less time working through the publishing process, which gives us more time to actually create excellent content. If you want to try the WordPress integration for WordPress, download our new source plugin (beta) and spin up a site for yourself!
(Coming soon: Part 2 of Why Gatsby Chose Headless WordPress, where we look at the technical details of migrating from our original MDX blog publishing process to a headless CMS).
Interested in learning more about headless WordPress + Gatsby? Watch our free webinar!
Hear Robin Zimmer (Full-stack Web Developer, Jambaree), Blaine Yamakawa (Project Manager, Jambaree), and Jason Bahl (Software Engineer, Gatsby) talk about how they re-architected a content-heavy WordPress site to run headlessly on Gatsby. The result? Blazing fast page load times (up to 4X faster), security vulnerabilities obliterated, and the content team got to keep their chosen CMS.