Building a Headless CMS with Next.js and WordPress

Say what? Why would I want to use Next.js for the front end for a WordPress website? I’ve already covered a couple of ways to do a single site WordPress – using React or Vue that work just fine. Why “headless”? Why complicate things?

nextjs logo

Believe it or not, there are plenty of reasons to use a framework such as Next.js to power the front end of your WordPress site. I’m working on my brother-in-law’s blog using this exact combo. My reasons? 1) Server side rendering 2) Security 3) and it’s React.

Server-Side Rendering

So we have an WordPress blog, with years worth of data in search engines. We don’t want to get rid of this by making it a pure client side solution. SEO for client side content is still not worth the gamble.

Like I mentioned, I do have previous solutions using React and Vue for WordPress, but these are all client side. Meaning, the data on the page is fetched (through AJAX) – after the page is loaded. They’re single page applications which, from last I heard is not optimal for SEO.

We want all the data on the page loaded loaded right from the get go – without any client side fetching. And that’s what Next offers.

Security

This one might be a little trivial and tricky. See – the existing WordPress site is already running. Naturally, we want the front end to use the current domain, and the API backend (which is the current WordPress site) will have a new “endpoint”.

For a more secure site using the “Headless CMS” architecture, we will have to hide where the back end is really living. Since there are no client side calls, the requests to the REST API is all done behind the scenes. This way, a user that visits the site, cannot really tell where the data lives. They cannot see how to get to the admin area – or if its even a WordPress site at all! The front end seems like its just a collection of static HTML pages. And that’s what I like about the Next approach.

Now I say tricky because that means I have to replace all references to the images and static resources. I cannot use relative paths – because it won’t resolve – the new domain doesn’t have the “wp-content” directory!

So I still have to see how this can be achieved.

It’s React

For some weird reason, I’ve grown to like writing React applications. And trust me – I’ve had my fair share of playing with JavaScript frameworks. There is a pretty good satisfaction writing JSX. As well as pushing myself to learn the more advanced features of JavaScript.

React by far is the most popular choice for developers at the time of writing. And I can see why. I pick Next.js framework to be the front end for my new project for this same reason as well.

So far, So good?

I can’t really tell just yet.

I am enjoying all the Next.js features – such as routing. This is already built in the framework so all you need to do is add JavaScript files in the “pages” directory and voila. Dynamic routes? Not a problem – simply name the file [slug].js – and you can access the slug parameter from the URL easily.

Props and State? Well, state is not really used – but props? Easy. For each component there is a function called getServerSideProps which sets up all of the data that can be accessed through props. Reminds me of componentDidMount in regular React.

How about presentational JavaScript – like click handlers and DOM manipulation? Well, you might think that you can also use React for that. But it looks like because of the build process – this might be difficult to achieve. At least I haven’t found good documentation on it. So for this reason, I just use plain vanilla JavaScript.

Well is it a good choice?

Stay tuned.

Leave a Comment.