One of the things that we’ve been discussing more and more here on WP Daily – and in the rest of the WordPress community, for that matter – is viewing WordPress and a framework or platform for developing web applications.
Heck, we’ve even begun to share a few web applications that are built specifically using WordPress.
The thing is, we’ve not actually spent time talking about why WordPress is a viable application platform, how it compares to other frameworks that are already available, and how to actually being using WordPress for Application Development.
Admittedly, articles about WordPress as a framework have a tendency to get a bit, ahem, wordy so if you’re not interested in reading the entire article, I’ll go ahead and share the bottom line here.
WordPress is a viable option for developing web applications because:
- It provides a lot of boilerplate functionality out-of-the-box
- It has a rich set of API’s that make modifying and/or extending functionality relatively easy
- It provides a logical way of separating presentation from functionality, if done correctly
- It’s under constant development with an active community
- It has significant familiarity and adoption among web property owners and end-users
Of course, we’ll be discussing this in more detail, and though I think that developers and designers will tend to resonante with this article more than anyone, hopefully it’ll spark the interest of those of you who are on the fence.
But before talking about why it is viable platform, we need to talk about why it’s not viewed as such.
“WordPress isn’t an Application Framework”
This is relatively common to hear from people who are skeptical about building applications using WordPress. I don’t think we can blame them, though, and there’s a couple of reasons why.
- The branding of WordPress sounds like a publishing platform – not a development platform.
- For many, WordPress is used as a way to blog, not to build software
Compare this to frameworks such as, say, Ruby on Rails, ASP.NET MVC, or CakePHP, the branding is vastly different. On top of that, WordPress itself is an application where the aforementioned frameworks are just that – they are foundations for building software and nothing else.
As such, it’s very easy to dismiss WordPress as an application and nothing more. But I’d argue that if an application has an API, then it’s clearly supporting development – it’s asking for others to build things on top of it.
The WordPress Application Framework
As mentioned, WordPress is a viable option for developing web applications. This is not only evident by some of the sites that we’ve shared, some of the things that those of us in the community have built, but based on a lot of the boilerplate functionality that WordPress provides.
Out of the box, we’re given:
- Authentication. That is, session management for users logging in and out of the system.
- User Levels which make it easy to grant new and existing users varying degrees of access throughout the system.
- Presentation functionality via themes and templates.
- Extensibility through the Widget API and the Plugin API.
- …and more
On top of that, we have the ability to customize almost anything in the dashboard. Not only can we add new menu options, but we have the ability to completely remove (or limit, based on user roles) options for users.
Of course, building web applications consists of far more then being able to simply manage users and sessions (assuming your app even offers those features).
It also includes being able to easily introduce new functionality for certain situations. This can be anything associated with saving custom information related to any model-type aspect of WordPress (think User, Post, Page, etc), or introducing new ways to associate data and models with one another (think categories, tags, or taxonomies).
But part of being able to think creatively using the available API’s is to shift your thinking from WordPress’ native features to more general abstractions.
For example, Pages, Posts, and Custom Post Types are all native to WordPress. In the database, they are all stored in the `wp_posts` table, but from a development standpoint, it’s much easier to think about them as models.
Or, more simply, a way to represent your data.
For example: A model for a post would include the attributes of a title, content, and a date of publication. Similarly, custom post types essentially afford us the ability to create our own models. Couple that with custom post meta and the ability to create absolutely unique representations of data is easily doable.
Separation of Concerns
For a while, MVC was all the rage. Then it was MVVM. I don’t know what’s next, but I do know that as much as I’m a fan of MVC, it’s not the holy grail of application development. Instead, it just happens to be a popular design pattern that works well for web applications.
But WordPress follows its own model through hooks – specifically actions and filters – that not allow us to hook into the page lifecycle and manage data prior to being send to the user.
Secondly, I believe that WordPress does a relatively good job of making it easy to separate design from functionality. Specifically, themes should be responsible for rendering and styling the data and plugins should be responsible for adding functionality.
The thing is, developers often mix the two – that is, they implement both functionality and presentation into themes ultimately blurring the lines between what a theme really is.
But if you’re looking to build web applications with WordPress, then it’s completely possible to have manageable code base permitting that you make sure to properly take advantage of actions and filters and logically separate your design from your functionality.
Finally, WordPress is not stagnant. In fact, it’s far from it. Where as certain development frameworks will undergo years of silence before the next version is released, WordPress is released and updated several times a year (and people still complain!).
Although I’d argue that frameworks such as Ruby on Rails are more opinionated in the various dependencies they include (and I’m not saying that’s bad), WordPress does good job of making the changes and discussion apparent on Trac and allow other developers to discuss it, implement, commit changes, and more.
Granted, this requires that developers stay on top of the changes and the API’s to make sure future versions don’t break compatibility with their existing software, but this isn’t something isolated to WordPress.
Above all else, WordPress is growing, maturing, and continually offering better API’s and functionality that not only enhance the lives of digital publishers, but increase the possibilities of what developers are able to build using the system.
Build It With WordPress
By trade, I’m a developer and for the past couple of years I’ve built applications and projects almost exclusively in WordPress so this particular topic is near and dear to me, so I clearly love discussing it – heck, I’d consider myself someone who evangelizes it.
On top of that, Matt mentioned that WordPress is headed in this direction in this latest State of the Word.
But I don’t want the discussion to stop with this post – I’d dig hearing you guys’ thoughts and opinions, praises and criticisms, and struggles and wins with building things with WordPress.
So have at it – the comments are all yours.