The content of this post is essentially the text version of the talk that I recently gave at WordCamp Atlanta 2019. Sure, some parts are left out, and some parts are modified but I do that since this is a different medium and certain statements or examples don’t translate as well. 🙃
The purpose of the talk, as you can tell from the title, is presenting a case for building web applications with WordPress.
I believe it can be done – because I’ve seen it done and worked with teams who do it – but before actually looking into the reasons why I think it’s a good foundation for certain applications, I also want to clarify terminology that we toss around a bit.
Ultimately, I want to define my terms so there isn’t any confusion, and then I want to use said terms to move forward.
But enough of the setup, right? Here’s the content of the talk.
Building Web Applications with WordPress
This talk is different than those I’ve previously done at WordCamp Atlanta (or other WordCamps for that matter). This is not going to be a programming-focused talk in the sense that it’s not going to include anything about writing code.
Building software, sure; but not writing code.
Specifically, I’m going to talk about software development, how it relates to WordPress, and I’m going to share examples of what an application built on WordPress looks like.
The purpose of this article is to help you start thinking about using WordPress as a foundation for web applications. To do this, we need to approach thinking about WordPress-based development differently, and we need to apply classical software principles in our day-to-day work.
It’s a Foundation; Not a Framework
- Out of the box, frameworks offer no functionality. They provide scaffolding for an application, a way to communicate with the database, and a way to send information to and from the front-end, but they don’t do anything. We have to create the functionality.
- Conversely, WordPress is an application. Upon installation, you can immediately begin using it to build a website, a blog, a storefront, or something similar through the use of themes and plugins.
Here’s the thing, though: WordPress provides APIs that allow us to build functionality on top of it. We can build custom features that run right along-side of or on top of the core application. And that’s the difference: Frameworks offer no functionality upon installation. WordPress does.
Thus, it’s not a framework. Instead, a foundation.
Web Development: An Abbreviated History
This raises a question, though: How do you delineate between web sites and web applications?
What Are Sites?
At one point, it was easy – it was pure presentation of information.
Further, our browsers began to get more mature, and we began to see what we could do with them. In a sense, rather than having applications installed on a local machine and run on their windows, they could run on a server to which we’d connect, and we’d interact with it within the context of a page rendered in a browser.
I believe this was when we began to see a differentiation between sites and applications.
But before we talk about applications, it’s important to note that in the colloquial sense, sites and applications are synonymous.
- Think about Twitter. Often, we’ll say go to “a site like Twitter or Facebook,” when both of these are, in fact, web applications.
- Similarly, a library may say something like “you can go to our site to browse information, pay a bill, or check out a book.” Yet, this is more than just presentation, isn’t it? It’s a feature-rich application.
So, sure, in the colloquial sense, the phrase “website” or “a site” is used synonymously with application.
But there is a difference.
What Are Applications?
Whenever you think about an application or an app, I’m sure something comes to mind.
Because of how ubiquitous our phones have become, it’s likely that you think of apps as something that runs on your phone or your tablet. But the term has also spread to our computers and even devices like Apple TV.
Regardless, an app, or an application, and its terminology for a solution that we apply to a problem. And an application usually features something like the following (at least some or all):
- The ability to process user input,
- The saving of data,
- The retrieval of data,
- Session management,
- Association of some type of information to another type of information
- For example, association of information to a specific user or users,
- The security of information,
- And so on.
And then we can take this a step further than what we already have by introducing features that, say, include location-based services, notifications, date and/or time-specific features, and so on.
In short, anything that involves more than simply presenting information to the user and that requires some type of data transmission from a data store, regardless of how basic, is an application.
Defining The Difference
In other words,
- Anything that presents data – no matter how fancy it might look – is a site.
- And anything that transmits information saves it and retrieves it is an application.
If we take this a step further, sites and applications are also built differently. And to understand how applications can be built with WordPress, it’s important first to understand how a generic software application is built.
I don’t want to belabor the point of how sites are built. I think the majority of people who work with WordPress already understand this to some level.
They are then linked together through common facilities provided by the browser like anchors.
And that’s sufficient for this discussion.
When it comes to writing applications, there’s a variety of architectures that we can follow. But before we talk about architectures, there are several popular paradigms:
- Functional programming,
- Procedural programming,
- And object-oriented programming.
And the latter two are most commonly seen in WordPress. But regardless of the paradigm that’s used, an application can be broken apart into several major components:
- The Back-End. This is usually made up of data-storage. It may consist of flat files, databases, or some other way to store the information. Furthermore, it also includes code that runs on the machine for making sure the data is safe to write to the data storage component and also retrieve the data storage component.
- The Application Layer. This layer is an intermediary level that sits between the front-end and the back-end.
- From one perspective, you can think of this as waiting for information to be provided by the user – be it a click of the mouse or the tap of a screen to the submission of information in a form.
- On the other hand, this is also responsible for responding to the user interaction, retrieving the information, securing it, and sending it back. So it works by interacting with both the front-end and the back-end, and the communication is two way.
So what would an application look like when it’s built on WordPress? We will talk about concrete examples momentarily but let’s try to break this down into what we know about WordPress and how it plays into software development architectures.
WordPress is built using:
- A database in which all of the information is stored,
- A directory in which all assets, like images and documents, are uploaded,
- An application layer that reads and writes information from the front-end to the back-end,
- And a front-end made up of templates that are composed of information directly in the file, pulled from the database, and described and presented using markup and styles.
Given all of the above, we also have APIs provided by WordPress that allows us to write information to the database, read information from the database, inject that information into templates, and so on.
On top of that, we have APIs available that allow us to do this asynchronously via Ajax or without using the WordPress interface at all via the REST API.
And in the final part of this talk, that’s exactly what we’re going to cover.
Of course, it’s easy to talk about all of this without actually giving some concrete examples as to how this can be done. So now that we’ve looked at where we’ve come from and where we are, I think it’s worth looking at how to do exactly what we’re talking about.
And that is, building a web application with WordPress.
But there’s something I want to make clear:
The notion of building “a web application” can sometimes imply that the solution we’re talking about, the application, is a large piece of software.
But that’s not necessarily the case. Sometimes it can be something as simple as a plugin, no matter how small or how advanced. In other cases, it can be something that interfaces with our mobile devices and WordPress.
And that’s what I’d like to show before we close today.
A Small Plugin
Personally, I hesitate to call small plugins WordPress-based applications. I see them more as enhancements to WordPress itself. This doesn’t mean that small plugins can’t be applications, but I’ve found this to be rare.
Take, for example, Easier Excerpts. This is a plugin that I write some time ago that dynamically changes the size of the excerpt field based on the amount of content within it.
Because of how the frequency of blogging and the desire to see all of the content included in the excerpt, I wanted to be able to do so without scrolling. So I write this plugin.
I don’t consider it an application, though. Instead, it’s small enough that it enhances the core application of WordPress itself. It doesn’t interact with a data store, and it doesn’t take any input from the user. It simply responds to the amount of text and dynamically updates a field.
A Larger Plugin
On the flip side, I’ve built larger plugins that are far more like pieces of software that run on top of WordPress than something like I’ve mentioned above.
Because of the nature of the project, I can’t use specific names but assume the following before we get started:
- The plugin I was writing needed to interact with a third-party API,
- It would read data from it, parse it, and insert it into the WordPress database.
- To do that, it could create custom post types, custom taxonomies, and it would provide custom templates for the information it was importing.
Furthermore, the size of data that it was importing was large enough that I would need to create a batch processor so, next, I would:
- Take the total number of records to be imported,
- Divide it into chunks of data that could be processed in a reasonable amount of time,
- Begin the process of reading each record, updating the user interface with the progress, and then notify the user when it was complete.
- That’s a lot happening at once, and the plugin had a variety of moving pieces.
- There’s the API client responsible for communicating with the third-party API,
- There’s the functionality for reading the data into the database,
- The batch processor for segmenting the data to parse into manageable chunks,
- The functionality for scheduling when a job would start, detect if it was running or not, and then starting the next job.
- There’s a notification system for letting the user know the progress,
- And there’s the importer that was taking each record to create a data structure that would map to the WordPress database.
As you can see, this is a significantly more involved and larger plugin. It didn’t do much with WordPress until it was ready to render the information to the user. This is when it was important to have information set into custom post types and stamped with the proper taxonomies.
An iOS Application
But can we take this a step further where an application is segmented between two devices – namely, an iOS-based device and WordPress? Naturally, I wouldn’t bring this up were it not possible.
I’m going to talk about this particular application at a high-level, likely higher than we did in the previous example, but the most important thing to note is that this application leverages WordPress through the use of its REST API.
That is, I’m building a plugin that runs within the context of WordPress, but all functionality is handled within the code. There are no elements on the user interface. It’s a matter of custom endpoints exposed with the REST API and code that fires whenever those endpoints are hit.
And I can give some concrete examples of that in a bit.
Just as with the last example, it’s not worth sharing the names and in-depth details of the application; however, I can share this application is one that interfaces between a patient and his or her physician.
Note that the iOS application is designed for the patient, and the web application is designed for the physician.
From the outset, assume that this application works like most other mobile applications:
- A user will need an account (which will be created using a username and password),
- And then will need to authenticate once the account has created and they can sign in.
Further, once they are signed in, there’s a variety of data that they can access. And with that data, they can retrieve it, read it, change it, and continue about their business while on the go.
On top of that, there are certain settings for reminders and notifications based on certain values that are being set in the mobile app.
The WordPress REST API
For the mobile application to work in such a way the information is not just being managed on the phone, it has to be able to communicate with a server-side application, too.
And that’s where WordPress and the REST API comes into the picture.
So let’s take some of the features of the mobile application and map them to WordPress.
- Creating an account
- Check to see if an account exists.
- If so, respond with one code,
- If not, then create the account and respond with another code.
- Create the user account and respond with the proper status code and send any necessary email.
- Allow the user to log in to the application by authenticating their username and password against the database.
- If the username fails, respond with a certain status code,
- If it succeeds respond with another status code.
Once the user is logged into the system:
- The information associated with the user can be retrieved on demand.
- Similarly, whenever the user saves information, it can be sent to WordPress on demand and viewed within the WordPress administration area if a dashboard is built for it.
- Just as the user can set up reminders and notifications for himself or herself, the physician can as well. This allows them to keep tabs on their patient (which, if of course, part of the agreement between the two parties upon using this application).
From there, a complete record of data can be kept, and the richer the API, the richer the information between the mobile device and WordPress can become.
Granted, this is but a high-level overview of how powerful applications can become when powered via WordPress.
But goes to show just how WordPress can be used as a foundation for web applications – even those that have a mobile component.
As I mentioned at the start of the talk, the overall purpose of this discussion was to start thinking about using WordPress as a foundation for a web application.
To do this, though, you can see it’s important to distinguish the differences between a web site and a web application even though we use the terms synonymously.
So to help demonstrate this, it was important to cover how sites are built and how software is built and how this applies within the context of WordPress.
- a short history of web development,
- the differences in sites an applications,
- and how some plugins can just enhance WordPress, some can be applications,
- and how we can build fully distributed applications through many of WordPress’ features,
I hope to have effectively, yet succinctly given you a high-level overview of how it’s completely possible to web applications with WordPress.
Before opening the floor for questions and comments, I want to thank you for taking the time out of your morning and your weekend to come to this session, to listen, and to participate.