It’s really an exciting time to be a WordPress practitioner right now, particularly as WordPress enters into a big transitional period with the introduction of the WordPress REST API!
As a practitioner, you’re used to approaching a need, whether for your own business or that of a clients, and then thinking of ways to use WordPress to meet the need through the use of themes, plugins, or other tools to make it happen. And the same goes with into mind when thinking of WordPress as an application as well.
Rarely does a client say in the first client meeting, “I want this exact plugin installed and for you to use these specific post types!” Haha no, instead they say, “I want to see who’s visiting my site”, or “Help! My website’s running slow!” And you geniuses go to work thinking of techniques to make it happen using existing tools, plugins, etc.
Transition
So what’s all this talk about a “transition”? The best way to begin describing the significance of this transition is to look back at where WordPress has been. Most of you have heard this, so I won’t go into all the old details, but in summary WordPress started as a blogging tool. At the time, it was still a crazy concept you could have your own personal stream of information you could control and post freely to.
Then came the introduction of post types and multisite, which was really at the core of transitioning WordPress from solely a blogging tool, to a full fledged CMS capable of storing and using vast amounts of content. For most of us in the room, this is what attracted us to WordPress in the beginning. Same with the introduction of a easy-to-use blogging platform, now it’s crazy to even imagine sites without a CMS at this point!
But now the next big transition is already under way into an application, and it’s equally exciting in the way it’ll increase capacity for WordPress and unlock new use cases to use the open source, community driven program we’ve all grown to love.
Application
First things first, if you’re like me when I first heard application, I immediate thought of iPhone or Android apps. But when I refer to applications, I’m referring to the system and data that runs a variety of mobile apps or websites.
See when opening up an app on your phone, the app itself isn’t actually where all the data lies. And when we think about it, it’s pretty obvious. All the tweets in the world aren’t stored in my phone…same with all the Airbnb listings, or Netflix shows. The mobile app as we call it, are merely the “skin”, or the front facing client we use to access, edit, add, or delete data.
Take Twitter for example. This is what Twitter looks like to us. (favorite, user profile picture, reply and compose buttons, follow users, etc)
But in reality, the screenshot below is what a tweet’s data actually looks like.
Even their front-end site, twitter.com, doesn’t actually store all the data, it’s just a skin designed and developed for us to interact with the application as well.
So now that we’ve unlearned and relearned what an application is within the context of APIs and the future of WordPress, let’s add another relearned word to our new vocabulary. (for some of us at least)
Clients
No, not talking about the people who hold to power to make or break our day, clients in reference to systems and APIs refers to the front facing website, mobile application, TV application, etc, that translates data from an application into an interact-able interface for the end users.
There are whole front-end roles dedicated to designing and building these interfaces. Whether it’s product or UX/UI design, to your standard HTML/CSS, JS languages for the web, and application specific languages as well for iOS, Android, Windows, and others.
For those who dabble or full on code WordPress themes, you’re probably already familiar with what’s stored in WordPress as an application vs. the code that organizes and displays the information properly. (front-end)
Take the_title() function…you should see this within every post or page template within WordPress, and it goes and gets the title of the individual page, post, or post type of the current or requested page. Notice the positioning, styling, and headers all fall outside of the imported data from the function. Also, what would show up if we used the tag outside of the loop or outside of WordPress? Nothing! Outside of our WordPress installation, it doesn’t know where to get the title, for what particular page or post, or how to format the title we receive.
APIs
When dealing with applications, this is where APIs come in real handy. When we have a client interface, we use an API to choose where to go get the data, what particular data we want, and how we want it formatted and imported.
Even going back to our theme example, we don’t ever see it, but when we use the the_title() function, it’s automatically picking the source, content, and format for the page/post title.
Or let’s say for Twitter, reading the latest tweet. Using Twitter’s API, we’d define the source: the Twitter application, what: the latest tweet from a specific user, and how we want the data included: syntax, meta information, etc. For some APIs, this works with posting too. So instead of just reading data, we’re going to send a call to write data once we’re in with the right authentication.
APIs are super useful and are widely used in almost any site or web application, whether you recognize it or not! APIs unlock potential for all kinds of data analysis, manipulation, remixing, and visualizations to name a few!
Weather API
Another quick example is weather data. Our client interface could be a website, or mobile app, and then using an API we can identify the source, specify where we want the weather reading, and how we want that information displayed.
WordPress as an Application
Now what could this possibly mean for my WordPress site? I was in the same boat about a year or so ago with all the technical talk surrounding the REST API and it’s integration into WordPress. One of the biggest breakthroughs is the introduction of the Headless CMS.
Headless CMS
Scary name, but it’s actually a really cool idea with lots of potential use cases. Currently to update WordPress, (unless using WP-CLI) you had to login to the WordPress Dashboard. (love it or hate it, it’s really the only option you got) Same way the the_title() function only works on your site within your WordPress loop, same went for editing, adding, or removing data within your installation.
But with this transition to WordPress as an application, WordPress itself is becoming independent from the dashboard and even your front facing website.
No, there’s no need to fear, your WordPress installation won’t break or get cut in half after automatically updating to the latest release. In fact, you probably won’t notice a difference at all, but within WordPress core, new outlets and possibilities to access and update data come with a lot of new functions.
So what?
No longer will we have to rely on XML or RSS to retrieve data from a WordPress site. (which is worth the update in of itself) But with the REST API, you can also update, add, and delete data as well…all outside of the native dashboard included. This presents the opportunities for custom dashboards! I’m sure many of us have found ways to hide settings or certain fields in the admin area for fear of a client accidentally nuking their whole site! With the Headless CMS possibility, you could even design and build a completely new front facing interface with only the fields the client absolutely needs to update! Even styling and tailoring it exactly to your company or client’s brand.
Two camps
I believe the transition to WordPress as an application will start to sort future opportunities into two camps. Which the two were outlined in a super good white paper from Human Made, and agency with many of the lead developers working on the WordPress REST API.
On one end, will be the developers. This includes both API developers, backend developers, and the frontend developers building the front facing interfaces we talked about earlier. Whether it be a website, mobile app, or even for other devices like TVs and sensors.
But before you start crying for those who are deathly afraid to touch code, the second camp might be much more interesting and exciting for the WordPress practitioner! While the new REST API integrations with WordPress are super exciting and unlock a whole ton of new capabilities for developers, the transitions going to attract brand new users to WordPress who don’t have a clue the difference between posts and custom posts, or what custom taxonomies bring to the table. And from a developer perspective, we’re honestly more focused on the code and API than the actual content itself.
So using WordPress as an application is going to require someone with a background in using WordPress to take a bunch of new data from a variety of sources, and organize and structure it within the contents of WordPress. (think custom post types, users, media library, etc)
And many of you are already doing that! At the meetup, we broke up into groups and brainstormed some really cool use cases to make it happen. From creating online invoicing platforms, warehouse training platforms, auto body shop app for customers…the possibilities and implementations are endless!
The best way to prepare for the full implementation of the WordPress REST API is to start viewing WordPress as an application. Anticipate where potential endpoints and data sources could be, and how you’d then organize it all within the open-source platform we love.