Now available through Jetpack, Content Options let users make small visual changes, like showing or hiding the author, date, featured images, and more.
A minimalist theme crafted by Automattic’s Tammie Lister, Sapor is geared to showcase your passions. Designed with food blogging in mind but well suited to anything from gardening to healthy living, it features a left sidebar for menu and widgets, and offers a Site Logo option with Jetpack active. We’re pleased that Sapor is now available in the WordPress.org directory — visit the demo or take it for a spin.
Watch the video presentation or read the transcript below.
You’ll find accompanying material for this screencast available in a public GitHub repo — each screencast has a corresponding folder with a very simple theme that can be activated.
But if you look closely, you might notice something has changed. Our
changePost function has disappeared, and instead we are requiring the
changePost function. If we go back to the containing directory, you can see that we also have a changepost.js file. This file now contains the
changePost function. Note that at the bottom, we have a line that says
module.exports = changePost. This is the CommonJS convention for defining what the module actually is. So when we require it, this ensures that what we require is the
changePost function itself.
Let’s get concatenating. I’ve mentioned that we’re using Webpack, so let’s get that set up. First, you need to install Node.js. Fortunately, this is a lot easier than it used to be — simply go to nodejs.org and download the automatic installer for your system. Once node.js is installed, we can run a command to install Webpack:
npm install webpack -g
This gives us global command-line access to Webpack. With this done, we can now run the most basic Webpack command, which is to take a source file, and smoosh it into a compiled file. The command for this is:
webpack ./theme.js compiled.js
We can now view the compiled file and see that it contains the contents of both changepost.js and theme.js. An extra little bonus with Webpack is the
-p flag, which simply means that you want to minify the file – remove whitespace and remove all comments etc. You can see that even this simple example our compiled file is almost a third of the size it was unminified.
We can also add the
-w flag which means we want Webpack to watch the files and automatically recompile whenever we change anything.
With the file compiled, we can see everything in action working together.
The Route of All Evil
With everything we’ve looked at so far, you can probably imagine stringing together a theme that allows a user to browse through different chunks of content from their website. However, a major missing piece is routing, something that you may not have heard of. Routing broadly encompasses the way that we deal with URLs changing. Let’s say a user visits our site, clicks to a different post and wants to share the link. With the examples we’ve looked at so far, this isn’t possible. Routing also ties into our user’s history. If we have no routes, the user can’t press the back button. No routing also means we have little chance of anything meaningful being indexed by search engines. I’m sure you can now appreciate that routing is very important.
In PHP, WordPress deals with this for us. There is a rather large class called
Let’s look at something basic we can implement.
If you look closely at changepost.js, you’ll notice that I’ve added a new line since the last tutorial. As well as editing the document on success, I’ve added a line that redefines
window.location.hash. This is the most basic way of changing our user’s route. You’ve probably seen this used on other websites and it amounts to the same thing as using an anchor link to take the user to certain heading on a page.
Let’s look at this in action. Our eventListener has been added to the first link in the menu. If we click it, note that the route now changes.
So with some very basic routing, we now want to change what happens if the user clicks back.
If we go back to theme.js, the eagle-eyed among you may have noticed another line beneath my link listener:
window.onhashchange = changeRoute
We’re hooking a new function,
changeRoute function. Here, we say if the hash equals nothing — as in, we’re on the homepage — show the original post that we fetched in the first place. The code here is almost identical to
changePost, but it just gets the original post.
What About no-js?
Will Somebody Please Think About the Search Engines?!
This ties back into the search engine point, since we know that Google does take page-load times into account when ranking sites in search results. We really don’t want our load times to be three to four times longer than they need to be.
In the next part of this tutorial, we’ll look at how to move from our basic theme to something more advanced, building from an altogether more stable foundation.
Watch the video presentation or read the written transcript below.
You’ll find accompanying material for this screencast available in a public GitHub repo — each screencast has a corresponding folder with very simple theme that can be activated.
Time for a REST
With traditional WordPress themes, we’ve been able to use all manner of loops and custom queries to get data. In shifting our approach to be less PHP-centric, where will our data come from?
The missing piece of our puzzle is a REST API, essentially an HTTP interface for getting data from a source. The REST part stands for REpresentational State Transfer. Think of it as a way of accessing WordPress queries directly through a URL. We can type a URL into our browser and include parameters just like we would with a custom loop, and in the browser we can see pure data from our website.
A REST API also allows you to post data, so the WordPress REST API allows you to add and update content directly without using the admin interface. Certain types of requests do need authentication, the REST API only publicly exposes content which is already revealed by WordPress through other avenues, like RSS feeds.
This all means that you don’t have to worry about connecting to a database, you just use a series of URLs to access different types of content on your site — these are known as endpoints.
The WordPress REST API is due to be fully incorporated in WordPress 4.5, due in the spring of next year. In fact, the infrastructure of the WordPress REST API will be included with WordPress 4.4 and has already been merged into trunk.
Exploring the WordPress REST API
Next, let’s look at some of the basic things we can do with the WordPress REST API.
I have a WordPress environment set up locally where I have installed WP API. Ahead of its inclusion in core, WP API is available as a plugin on the WordPress plugin repository. With the plugin activated, I can navigate to the URL
/wp-json/. At this URL I can see an overview of everything that the REST API makes available to me.
As the URL suggests, WP API uses JSON formatted data. This is not compulsory for REST APIs, but most REST APIs will use either JSON or XML formatted data. More recently JSON is the preferred format as it’s less verbose and generally easier to work with. I’m also using a Chrome extension called JSON View, which adds sane line breaks and some colours to make it easier to read the JSON. Without JSON View, the JSON data is quite hard for a human to read!
The REST API adds namespaces to its endpoints. This is to ensure that extensions and future versions of the API don’t break functionality for sites and software that use it. The primary namespace at the moment is
wp/v2. This means that we can build our website against version 2 of the REST API. If, in the future, it’s decided that the REST API should be structured differently, this restructure would happen under the namespace of
wp/v3. Therefore the REST API could completely change, but what we built for v2 would be safe with the inherent backwards compatibility of the v2 namespace.
So, if we navigate to
/wp-json/wp/v2/ we can see all of the information about this namespace. As newcomers, we don’t have to worry about this at the moment, but it’s worth understanding the path we take to what we’re really trying to get from the REST API.
If we add
posts/ to the end of the above URL, we finally start seeing the data from our website. By default,
posts/ will show us the same content that a generic loop on our homepage would. On a clean install of WordPress, this is usually the 10 most recent posts.
We can further narrow down our request to the REST API by adding a post’s ID to the URL. So in this instance,
/wp-json/wp/v2/posts/1241/ will show us just the one post with ID 1241.
The REST API provides typical things that we might want in relation to a post. We can see the date, modified date, permalink, title, content, excerpt, format, whether or not it’s sticky, and more.
I’ve set up a basic HTML document set up in my text editor, including a
div with the
anchor link with text “Hello world,” and an empty
div element. The
div has an
innerHTML methods to change the data in the HTML on this page. At the moment we aren’t dealing with errors, we would want to deal with these if we were doing this in production.
Let’s see how this works. If I activate the session 2 theme on my test site, we can see what this does. There we go, the data from the REST API is being rendered in my theme demo.
One last thing before we end this tutorial. We still have that link that I added at the top — let’s look at how this is connected.
Well, if we go back to the index of our little theme and scroll down, you can see we also have a function,
There we have it.
You can now see how a very basic WordPress REST API-based theme can work. In the next screencast we will consider more advanced approaches to theming and the challenges we face when taking this approach.
WordPress theming hasn’t changed very much over the past few years. It’s certainly become more refined, and projects such as Underscores (_s) have helped promote best practices and robust standards. That said, we can still go as far back as Kubrick and find plenty of common ground with the most recent WordPress themes.
- Storing and pre-fetching content using the browser’s Web Storage API to allow server-less, seamless transitions — using the browser’s History API — between posts and pages.
- Animations within themes, for more natural and intuitive interactions.
- The ability to create entirely offline experiences using all new Service Workers.
In this five-part tutorial, we’ll expose you to the brave new world that WordPress theme development might inhabit in the coming years. While the best practices for building a theme in this way are still to be established, we’ll do our very best to guide you into the secret garden of the future.
Stay tuned for:
Putting the Jetpack portfolio custom post type to good use, Blask showcases all types of creative work – like photography, graphic design, illustration, or painting – in an elegant, minimalist way. Blask was developed by Automattic’s Ola Laczek, based on a design by Mel Choyce.
Colinear is Thomas Guillot’s revamp of the classic Coraline. With six layout options accessible via the Customizer, Colinear offers tremendous flexibility in displaying large amounts of content, perfect for news or magazine-style sites.
Both Colinear and Blask support a Site Logo with Jetpack active, and are fully responsive, looking spiffy at any screen size. We hope you enjoy this handsome theme duo.
Check out the video presentation or the written transcript below.
Getting Our Hands Dirty
First, we want to select something in the DOM. The two most common methods for doing this are
querySelector. They’re similar, except with
querySelector we can select elements by their class. As its name suggests
getElementById only allows us to select elements by their ID.
With something selected, we could now change pretty much anything about it. This is basically what jQuery does behind the scenes.
A Whole New Node
We’re pleased to launch two new themes on WordPress.org.
Featuring big, bold drop caps and oversized images, Libretto is ideal for showcasing longform writing or stunning imagery. Its classic design and typographic details will give your blog a sophisticated, elegant look. Libretto is a fork of Readly, originally designed by WPShower.
Designed by Automattic’s Caroline Moore, Libre brings a stylish, classic look to your personal blog or longform writing site and is now available for download at WordPress.org. Libre’s main menu stays fixed to the top while visitors read your posts, and three footer widget areas let you tuck extra content away at the bottom of the page. Two custom page templates, including a full-width layout, add visual variety. Make Libre your own by adding a header image or — with Jetpack — a site logo. Libre sports a clean, responsive design that lets your site shine on screens of any size.
When Automattic’s Thomas Guillot was designing Publication, he aimed to incorporate two sidebars in an original way, while putting emphasis on large, full-screen featured images. Now available in the WordPress.org theme directory, Publication is well suited to magazines or blogs about fashion, food, travel, or design — or any topic where visuals are an important focus.
A classic magazine-style theme, Apostrophe is now available for self-hosted sites. An update of Konstantin Kovshenin‘s Semicolon, crafted by Automattic’s Sarah Semark, Apostrophe supports a site logo and featured posts once Jetpack is active. With its traditional horizontal menu and right sidebar, Apostrophe also lets you “star” posts on the front end to set them as featured. Check out the demo or give it a go on your site.