As of WordPress 4.7 (December 2016), WordPress has shipped with a JSON API built right in. Wanna see? Hit up this URL right here on CSS-Tricks. There is loads of docs for it.
That JSON API can be used for all sorts of things. I think APIs are often thought about in terms of using externally, like making the data available to some other website. But it’s equally interesting to think about digesting that API right on the site itself. That’s how so many websites are built these days away, with “Moden JavaScript” and all.
So it’s possible to build a WordPress theme that uses it’s own API for all the data, making an entirely client-rendered site.
I would have thought there would be a bunch of themes like this available, but it seems it’s still new enough of a concept there isn’t that many. That I found, anyway. I did find Foxhound though, by Kelly Dwan. It’s simple and quite nice looking:

It’s React-based, so the whole thing is logically busted up into components:

I popped it up onto a test site and it works pretty good! So that I could click around and do various stuff, I imported the “theme test unit” data, which is a nice and quick way of populating a fresh WordPress install with a bunch of typical stuff (posts, authors, comments, etc) for testing purposes.
Only a shell of a page is server-rendered, it looks like. So without JavaScript at all, you get nothing. Certainly, you could make all this work the regular server-rendred WordPress way, you’d just be duplicating a heck of a lot of work, so it’s not surprising that isn’t done here. I would think it’s more likely you’d try to server-render the React than keep the PHP stuff and React stuff in sync.
About 50% of the URL’s you click load instantly, like you’d expect in an SPA type of site. Looks like any of the links generated in that shell page that PHP renders do a refresh, and links that are rendered in React components load SPA style.
I would think this would be a really strong base to start with if you were interested in building a React-powered WordPress site. That’s certainly a thing these days. I just happened to be looking at the Human Made site, and they say they did just that for ustwo:
ustwo wanted to build a decoupled website with a WordPress backend and a React frontend. Human Made joined the development team to build the WordPress component, including custom post types and a custom REST API to deliver structured data for frontend display.
So ya know, people are paying for this kind of work these days.
“But it’s equally interesting to think about digesting that API right on the site itself.”
I’ve done this before. In my case the server got the data from it’s own API and passed that data straight to the view, so it wasn’t JavaScript rendered views, but most people would be interacting with the site through the API instead of the front end, so it was perfect for ensuring my API was easy to use and bug free.
This is cool and all but doesn’t this just expose all of my posts to anyone who wants them in a neat little package? I went to my company WP site and appended /wp-json/wp/v2/posts and it dumped every post out into JSON without any authentication or anything. This might be okay for a blog but it could be a problem for businesses with competitors.
Hey Brian, a lot of that information is actually exposed already via RSS on any given WordPress site (unless you’ve specifically disabled it)
For a RSS Example check out CSS Tricks itself:
https://css-tricks.com/feed/?post_type=posts
Here’s the WP REST API equivalent:
https://css-tricks.com/wp-json/wp/v2/posts
They are both available out of the box, but can be locked down with a little customizing via some hooks and filters (or a plugin that might do it for you).
I though the same thing and made little research. Out of the box, WordPress expose all articles, but you can add Authentication easily : https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
I just feel sad they didn’t include oAuth authentication natively, but only Cookie Authentication. But plugins can help for this.
I have been using the WordPress API a lot lately for adding suggested search results as users are typing in a search box. It’s as simple as adding a
?s=
parameter to your API request if you are searching in a single post type. If you need to search across several post types, you can create a custom endpoint. It’s pretty fun!I’d be a bit worried about accessing things from plugins like ACF or WPML… I heavily rely on those (and on a lot of googling around for solutions).
At least to ACF I know a solution: https://br.wordpress.org/plugins/acf-to-rest-api/
Hey Wolfr, generally there should be no reason to worry. Using plugins like the ones you mentioned won’t expose anything sensitive to the REST API by default (depending on your definition of what is sensitive).
You have to intentionally expose extra information using a function like
register_rest_field
Docs: https://developer.wordpress.org/reference/functions/register_rest_field/
On occasion I’ve exposed all my acf fields intentionally using something like https://wordpress.org/plugins/acf-to-rest-api/
All that to say, as far as I can tell the REST API doesn’t generally expose anything that RSS didn’t already expose.
There’s plugins you can disable it entirely with or use
Technically, can’t you decouple front from back and still do the front in PHP? There’s nothing in the API that requires that requests come from JS in the browser, correct?
I mention this simply as a way to ease the learning curve.
The API doesnt require you to do requests via JS, for PHP you’d use something like CURL.