Over the past few months, we've been taking a look at all of the features and aspects that make WordPress a potential foundation for application development.

In fact, we've spent roughly 15 articles talking about all that WordPress offers.

And though we'll be reviewing each of the points in this email, perhaps the biggest thing to take away that building web applications using WordPress is different than using many of the popular frameworks that are currently available namely because WordPress isn't a framework.

It's a foundation on which we can build; not a framework with which we build.

This means that we have to shift our model of thinking about how various components of our application are built so that they perform optimally in the context and environment in which they're running.

1. Frameworks and Foundations

In the first post in the series, we look briefly at exactly what it means to be a framework:

In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software platform to develop applications, products and solutions. Software frameworks include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or solution.

And what it means to be a foundation:

In short, software can be built on frameworks, software can extend foundations.

These two definitions set the stage for how we'd then begin looking at WordPress, how it's built, the design patterns it implements, and how we need to adjust our conceptual model such that we're properly thinking about the underlying code base so that we're leveraging it as best we can for the work that we have to do.

2. Rethinking Architecture

As with most web applications, WordPress is structured in a similar fashion:

1. The Database Layer
2. The Application Layer
3. The Presentation Layer

But when it comes to building applications on top of WordPress, we're changing things up a little bit. That is to say that although WordPress maintains the same structure, and we can build our own solutions using our own strategies, design patterns, and what not, we will be hooking into the WordPress application a bit in order for our own business logic to fire, and in order to display things in our own presentation layer.

In order to do this, it's important to understand the design pattern that drives WordPress. And although MVC and its variants are all the rage these days, WordPress follows a different convention.

3. The Conceptual Model (Events, Actions, and Filters)

In a follow-up article about WordPress' architecture, we discussed how WordPress utilizes event-driven programming.

Instead, event-driven programming works off of the premise that "something as happened." Hence the name for actions in the WordPress lingo (of course, we also have filters, but I'll cover those momentarily).

Specifically, we talked about how this leads us to the idea of how, in programming, something happens and then we're able to take advantage of those key points.

In WordPress, these particular features are called hooks and can defined in two particular ways:

1. Actions indicate that certain things such as the loading of certain data or the preparation of certain features are available.
2. Filters are points in the WordPress application lifecycle that intercept, manage, and return data before it its the browser or the database.

We then when on to discuss each of these in more detail. Through the use of longer definitions, code examples, and some of the most common hooks that are available, we reviewed how to put each of them to good use, and how they can benefit us when working with our own web applications.

5. User Management, Sessions, and Email

Then we began talking about several features that are at the heart of web application development:

• the creation and management of user accounts
• sessions for persistent data
• email services

We covered these items in sequence not only because they are core to many modern web applications, but because they are many times used in conjunction with one another.

For example, when a new user registers an account, s/he will receive an email about how to activate it or how to login, and then once the user logs into the system, they are likely going establish a session such that data is carried with them around the site until their session is terminated.

The reason this tends to be a bit of a problem for building applications in WordPress, is because there isn't really a sessions API. Instead, we have to fall back to the facilities that are offered by PHP. This isn't difficult, but if you've never taken the time to properly introduce a native PHP feature into an existing application that doesn't already incorporate it in some way, there are several points that should be understood.

And finally, email is obviously key in communicating with users; however, many developers who work with WordPress (regardless of their level of experience) aren't always aware of the ability to fully customize emails that are sent not only throughout the usual course of events, but also when certain events happen that may warrant an email in the context of your application that's not standard to WordPress.

6. Saving and Retrieving Data

Once the user is logged into the application, they'll likely be saving and and retrieving data, but if they're not, there's still a chance that we may be recording some of their information of for no other than to know how they're using the site, or to render information back to them.

Luckily, WordPress has an API that makes this really easy, but it also comes at the expense at needing to validate and sanitize data both when saving and retrieving information.

This is key as we want to make sure that malicious information isn't being inserted into the database, and we ant to make sure that we're retrieving information in a safe way such that it's readable and user-friendly for the users to see.

7. URL Rewriting

As we began to wrap up the series, we talked a bit about modern URL rewriting schemes and how WordPress offers a variety of ways to do this out of the box.

But we took a deeper look and compared what many modern frameworks offer in the way of customizing routes. Specifically, we looked at how RESTful routes can be implemented in WordPress using the Rewrite API to give a cleaner URL scheme, why this is beneficial for the users, and how to manage it in WordPress.

Additionally, we talked about some of the pitfalls in doing this and how to avoid them when incorporating custom rules into our application.

8. Caching

Because speed is a feature, we then moved on to talking a bit about the WordPress Transient API in order how to learn to cache information in our application.

Although there are many plugins and other software packages that can introduce caching into our web sites and applications, there are additional things that we can do as programmers to help take advantage of the native features of WordPress and its underlying database that will play well with said caching applications.

The thing is, even if you're not going to rely on third-party applications for caching, you can still take advantage of how WordPress organizes information in its database such that you can still increase performance of your work by leveraging this API.

9. Querying The Database

Finally, we ended our exploration and discussion of the features of using WordPress as a foundation for application development by talking about the best ways to query data.

Specifically, we discussed:

• WP_Query which is used to perform more advanced queries on post types, taxonomies, meta data, and more.
• WP_User_Query which is used to write advanced queries against the user's table.
• $wpdb for writing custom database queries.

We then looked at use cases for each of the available APIs, how to leverage them in our project, and under what conditions which one should be used.

Because WordPress is a database driven application, then the applications that we build on top of it will be, as well so its important to know exactly how to interact with the available APIs so that we're not only retrieving correct information, but doing so in a performant, easy-to-read, maintainable, and scalable way.

Where Do We Go From Here?

The ultimate goal of this series of articles was to provide as comprehensive look at what WordPress offers in the way of web application development.

Of course, as developers, we have to remember that there is no silver bullet as it relates to providing solutions for ourselves, our clients, and our customers - it's about finding the right tool for the job. In some cases, that will be WordPress, in other cases, it won't. All that to say, just because WordPress can be used doesn't mean that it should be used, and we shouldn't work to force our problem set into WordPress when it isn't the right.

That said, when WordPress does offer the right functionality, APIs, and structure to solve the given problem, then keep this series of articles readily available for reference as it's aimed to provide you exactly with what you need to build solid web applications on top of the existing WordPress foundation.