Three major changes in WordPress 4.7 jump out as having the power to significantly transform how I do my work every day.

Happy December 6, 2016! Christmas comes early today with the release of WordPress 4.7, “Vaughan.”

This feels like the biggest WordPress release in ages, and the absolutely mammoth Field Guide accompanying the release seems to reinforce that feeling.

We’ve tried to keep educated on the major changes in WordPress 4.7, and there are a lot of them. But as I’ve read about and played around with the new features, three major changes jumped out as having the power to significantly transform how I do my work every day. They are:

1. REST API content endpoints
2. Custom CSS changes, with live previewing, in the WordPress Customizer
3. WordPress PHP templates for all post types

In this article, I’ll walk you through each feature, and how I expect it to significantly impact our everyday work in WordPress. Let’s dive in!

1. REST API Content Endpoints

Let’s do the world-shattering one first: WordPress REST API content endpoints are now in core.

It can be hard to get your mind around what this means, so I’ll recommend you to two resources:

1. Our interview with WordPress developer and educator Josh Pollock, who is one of the clearest and most consistent teaching voices on the REST API
2. A React.js app we just wrote using the REST API endpoints that are being added in WordPress 4.7.

The rest of this section will try to explain just how cool the REST API content endpoints are by defining, first, what they are in general, and then explaining how our app uses them and the possible benefits of such an app.

What WordPress REST API Content Endpoints Are

The REST API content endpoints are a set of predictable URLs that expose a WordPress site’s public data in an easy-to-work-with format called JSON.

The REST API Content Endpoints are a set of predictable URLs on every WordPress site running 4.7 or later. These URLs expose a WordPress site’s public data—things like its recent posts and comments—in a format called JSON, which computers can easily understand and work with.

You can see a few of WPShout’s existing content endpoints at:

• https://wpshout.com/wp-json/wp/v2/posts: Our recent posts
• https://wpshout.com/wp-json/wp/v2/comments: Recent comments on the site
• https://wpshout.com/wp-json/wp/v2/users: WPShout’s users

Now that you can view these things in a predictable fashion from outside WPShout’s programming environment itself, you can write software that does things with them. We cover that next.

Why REST API Content Endpoints are Cool

To dig into this, let’s talk about the app demo. (Ignore the lack of design and let’s talk about functionality.) Here are some of its key features:

A WordPress Site’s Data Without WordPress Processing

If you look at our app’s page source, you’ll notice none of the hallmarks of WordPress’s PHP processing—things like a style.css file, a very lengthy and complicated head section, and so on.

Instead, you’ll find a few calls out to external JavaScript files, some odd-looking JavaScript, and that’s it.

What’s going on here? This is a JavaScript application that sits totally outside of WordPress, and doesn’t engage its (often heavy) PHP processing, which loops through hundreds of PHP core, theme, and plugin files on the server for every page load.

So how, then, did this JavaScript application get its hands on the 10 most recent WPShout posts? That’s what the REST API does! Our app got these posts from https://wpshout.com/wp-json/wp/v2/posts. You can go there and see them yourself, in JSON format.

So our JavaScript application is fetching information from the WordPress database, as exposed in the form of content endpoints by the WordPress REST API—and can then bundle that information into an app that sits totally outside of WordPress’s processing.

If you scroll up and read our definition of the REST API content endpoints again, it should now make quite a bit more sense. And if you use your imagination a bit, you can see why this feature is causing a lot of people to think about using WordPress as the data store for their highly custom web and mobile apps—something which was barely possible before.

A Single-Page Experience

You may notice that the site’s a bit slow to load initially (in large part because we’re fetching all our JavaScript files from external servers).

However, once you click “Previous Post” and “Next Post,” you’ll notice that the next post loads basically instantly, with no loading flicker like you’ll see on WPShout itself.

Why is this? It’s because this is a single-page JavaScript app, into which all the post data is already loaded. Paging “Next” or “Previous” simply tells that app to refresh which already-loaded data it displays.

Single-page apps offer a faster and better user experience than even the most performant PHP applications, and, as we’ve seen, the REST API content endpoints are the key tool that makes WordPress data available to these apps.

JavaScript Itself!

JavaScript is a very frothy—but very promising and very fun—programming language. The REST API exposes WordPress data to the world of JavaScript application development, and encourages us to learn that world ourselves.

If we take that encouragement, over time the average WordPress developer’s skill set will much more closely resemble that of other web software engineers. That should make us more able to deliver amazing stuff for clients, to talk to other folks outside WordPress, and to offer our services in the broader ecosystem.

In sum, if you haven’t got into JavaScript development yet, today is literally the perfect day to start. I’ll personally advocate that you learn React, which seems to be at the top of JavaScript’s churny heap, and which has the benefit of being developed and supported by the 800-pound tech gorilla that is Facebook.

2. Custom CSS Changes, with Live Previewing, in the WordPress Customizer

This one is enormous for me. Let’s watch a video of it in action and you’ll see why.

Did you see that?! You can now make CSS changes with live previewing, thanks to a feature that’s available by default in WordPress Core!

Why Custom CSS in the Customizer is Cool

Here are just a few of the ways I expect this to make my life easier and better:

No More Trivial Child Themes

Sometimes the only change I need to make for a client whose site is running on an original (parent) theme is like ten lines of CSS.

Until now, this has presented a dilemma. Do I:

1. Install a plugin like “Simple Custom CSS,” adding to the site’s plugin, processing, and update load, or
2. Go to the trouble of installing and activating a child theme just to add ten lines of CSS the “right” way?

This problem gets even hairier for clients who struggle to share FTP access, in situations where activating a child theme resets parent theme configurations, and so on. (There are also some users who suffer under restrictive server permissions that make it impossible even to install a plugin like Simple Custom CSS.)

Custom CSS in the Customizer feels like the permanent solution to these problems. For small code changes, it’s right there, stably in Core, with a beautiful and live-updating editing interface. It’s the perfect place to make small styling changes without roping in additional infrastructure.

Less Reliance on Browser Developer Tools

I’ve been very clear about my consuming love for Chrome Developer Tools. A big reason why is that it does just what we’re getting introduced to here: makes the browser into a development environment with live-updating CSS changes.

With this new feature, I’ll be in Dev Tools less often for simple CSS changes. That has a couple of obvious advantages:

1. A much easier update flow: click “Save and Update” for each rule I want to keep, rather than selecting each rule and copy-and-pasting into an external stylesheet running in my text editor (let alone FTP uploading and clearing both server and browser caches to “cowboy-code” CSS changes on live sites).
2. A lower barrier to entry for people not fully comfortable with developer tools. If you know a bit of CSS but are otherwise unfamiliar with both Dev Tools and the broader WordPress technical environment, this new feature gives you a lot more freedom to change CSS in a way you can see.

To sum up: I’ll never use a custom CSS plugin again (which is a bit sad, as some of those plugins are excellent!), and I’ll be cutting back somewhat on my use of child themes and Developer Tools. I love child themes and Developer Tools, so that should really tell you how major a feature improvement this is.

3. PHP Templates for All Post Types

We’ll let the developer notes speak here:

WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages. While this feature is very helpful, it has always been limited to the ‘page’ post type and not was not available to other post types. With WordPress 4.7, it will be.

I can’t believe it never occurred to me to ask why WordPress didn’t have this feature. Now that it’s here, it feels like an invisible shackle has fallen off my use of the software.

Poetic language aside, here’s what this adds to a Post’s editing window:

The “Article with No Distractions” entry in the dropdown is a function of me creating a file, which I chose to call single-no-distractions.php, which starts with the following code:

/*
Template Name: Article with No Distractions
Template Post Type: post
*/

Unlike the regular single.php, this template has no call to get_sidebar(), and I’ve also created a CSS rule that applies only to posts with this template:

.post-template-single-no-distractions .content-area {
	width: 100%;
}

(The .content-area element is normally 75% wide, to accommodate the sidebar.)

Put together, the simple changes above give us:

Why WordPress Post Templates are Cool

Here are just a few sketches of my excitement about this feature:

A Better Successor to Post Formats

This could be an actually-robust replacement for WordPress’s post formats feature, which is a generally good idea—different layouts for different media types within posts—but which has been dying basically since its introduction.

Post formats suffered from two architecture decisions:

1. The variety of post formats are restricted to ten arbitrarily specified ones
2. Post formats come with no stardardized layout framework of any kind; implementing different layouts for different formats is up to the theme developer

So out of the box, post formats were basically a restriction that also offered no additional clarity or usability—a bit like declaring that people’s personalities can only be “Red,” “Blue,” or “Orange,” and then leaving it up to them to figure out what that means.

Post templates may be the flexible, it-can-do-anything solution that post formats perhaps should have been. Theme developers who want to let users declare that “this is a video lightbox post” and “that is a Tumblr-style blog post” can now just do that—without having to use custom, non-standard theme options pages (or nightmarish page builder integrations).

Post templates might become the way that thoughtful theme designers carry the idea of multiple post layouts forward.

Cleaner Themes with Fewer Template Hierarchy and Theme Options Hacks

Related to the point above: posts of all post types (Post, Page, and any arbitrary custom post type) often do need to look different. Without a one-to-one method of specifying per-post layouts, you’re going to be writing general rules that “catch” only the specific posts you’re trying to talk to. That could look like:

1. Dire WordPress conditional hacks like if( is_single( 1147 ) {}
2. Complicated theme options panels that impose a bunch of back-end processing to give users options
3. Page builders that take the law into their own hands, creating severe lock-in and drowning post content in shortcodes

So I’m simply excited to see a direct route to declaring precisely how you want a specific post (or Product, or Book Review, or Team Member) to look on a one-to-one basis. It’s just better this way.

Posts of Any Post Type that Look Like Your Existing Page Templates

1. If you have a favorite page template, like template-page-with-header-video.php, that you also want to apply to certain of your posts of other types, I don’t even want to know what you’re doing (in the WordPress template hierarchy or otherwise) to make that happen.

Starting in 4.7, it’s very simple. For an existing page template that you now want to apply to the post and book-review post types, just add a single line to the comment at the top:

Template Post Type: page, post, book-review

And you’re done! You can now apply that exact formatting to any post of those three post types across your site.

To be honest, I’m not really sure what possibilities this feature will unlock for the average developer. It’s a straight line to a formerly convoluted problem, and I’m not clear on all the benefits of that. I’m just glad it’s here.

Whew!

WordPress 4.7 is an absolute giant, and I’ve just started to scratch the most glittery (to me) parts of the surface. I highly recommend you read the Field Guide in full: if there’s one WordPress major version release worth understanding, it’s this one.