With people beginning to realize WordPress' potential as an application foundation rather than just a content management system or a blogging platform, this series is focusing on just how WordPress can be used for such projects.

One of the most important things to note is that WordPress isn't meant to be the definitive solution for building web applications. In fact, I don't think any foundation or framework is meant to be the definitive solution.

Instead, we have a number of different choices, all of which lend themselves to better situations than others, and WordPress is no different. Throughout this series, we're going to continue taking a look at how web applications can be built with WordPress, and what situations lend themselves best to the foundation. However, we need to continue our discussion on how WordPress works so that we can then begin to talk about how to build applications on top of it.

In the previous article, we discussed how many frameworks offer an MVC approach to development, but we also looked at WordPress' event-driven model. In this post, we're going to take a deeper look at the event-driven paradigm that WordPress employs, and why this matters.

The truth is, many people are familiar with this paradigm, they just aren't familiar with the naming conventions. By the end of this article, we should have a clear understanding as to what event-driven programming is, how it works, how it's implemented in WordPress, and how we need to think about this when coming from other patterns such as Model-View-Controller.

Event-Driven Programming

In the last post, we summarized event-driven programming with the following idea:

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).

And that's fine for a working definition of events, especially at a high-level. However, if you want to take a more in-depth look at what this looks like from a practical stand point—that is, from how WordPress implements it—then arguably the best thing that you can do is understand events.

But even more than that, it's important to understand the WordPress page lifecycle, where events happen, and how we - as developers - can hook into them to perform a certain task.

Understanding Events

As we've already mentioned, in event-driven programming, the idea of events is simply that something has happened. We keep re-iterating that, but what does that really mean?

In the context of a single page load, there are a number of things that occur:

• JavaScript and stylesheets are retrieved
• Queries are run against the database to retrieve data
• The information from the database is rendered within the context of the markup
• The page is presented to the user
• ...and so on

All of these can be considered events, but each of these is made up of their own set of smaller events - that is, you can get really detailed as to when something happens.

Take, for example, the idea of rendering a typical, public-facing request for a WordPress-powered page. If you look at the associated Codex document, you'll notice that there are approximately 50 actions that occur, and this does not include post or page specific actions, either.

Each of these actions can be considered an event, and in the world of event-driven programming, events are usually exposed in such a way that they allow us to hook into them and manipulate information before it's rendered to the client.

Hence the name for hooks.

Of course, in WordPress, hooks come in two varieties: Actions and Filters. Although this series isn't about a solid tutorial on each of these, it is important to recognize the difference in them as they relate to working with WordPress.

Actions

Actions are a type of hook that signify that something has happened, and when that something occurs, we have the ability to register our own functionality such that we can inject our own code (or even prevent certain things from happening).

As I summarized in my series on Actions and Filters:

Actions are events in the WordPress page lifecycle when certain things have occurred – certain resources are loaded, certain facilities are available, and, depending on how early the action has occurred, some things have yet to load.

It's important to understand the available actions so that you know when the best time to hook into a given event is so that you're not impeding the performance of the page, potentially mangling other data that's coming downstream, or so that you're properly handling the information at the right time and place.

Filters

Filters, on the other hand, a type of hook that allow us to receive a certain piece of data, manipulate it, and then return it back to WordPress before rendering it to the browser.

For the example, if you take a look at the_content filter, then you'll notice that if you hook a function into this particular action, your function will be given the content. This means that you'll be able to manipulate the content by inserting information into it, removing information from it, or something similar, prior to handing it back to WordPress to render to the browser.

Similarly, I summarized filters in my series on Actions and Filters as the following:

Filters are functions that WordPress passes data through during certain points of the page lifecycle. They are primarily responsible for intercepting, managing, and returning data before rendering it to the browser or saving data from the browser to the database.

So, with all of that said, actions and filters are both types of events that occur within the WordPress lifecycle that allow us to hook into them and insert our own code for execution prior to having it rendered to the browser.

In short, the term "hooks" is a general term that refers to both actions and filters each of which serve a different purpose.

Analogus to MVC?

Now, one of the most common things that I've seen from people who are coming from a different background such as Rails, CakePHP, ASP.NET, or other MVC frameworks, is how to map their conceptual model of MVC to the event-driven model of WordPress.

By that, I mean they try to find analogies to models, views, and controllers in the event-driven paradigm. For example, some may try to do the following:

• "If views are meant for showcasing data, then surely that's what templates are for in WordPress." Well, yes, to some degree, but templates are also affected by various hooks and they call down into certain functions.
• "If hooks are used to orchestrate data between the database and the views, then they are like controllers." Sort of, but they also can represent data-specific logic similar to a model, and they can also be used simply as helpers to format information which is more akin to helpers than actual controllers.
• "But if the templates, or the views, can call into the controllers, or the hooks, then where does that leave the model?" Exactly, you can rationalize similarities all you want, and you can rationalize some good ones, but the truth is that WordPress is not MVC.

To that end, I highly recommend trying to avoid thinking about WordPress in the context of another pattern. It has it's own pattern. Think of it in those terms.

It's Not About Retrofitting!

In short, coming to WordPress from another framework that uses another design pattern or another paradigm is fine, but it's not about making WordPress fit your previous experience.

You can't retrofit one design pattern into another and expect to have high quality results.

Software doesn't work like that.

Instead, just as you do with other frameworks, you must think in terms of how WordPress works in order to properly build things on - and for - WordPress. Later in the series, we'll be taking a look at why WordPress makes a solid option for web applications, but before that I think it's important to understand the pattern that WordPress implements and how to best take advantage of it.

Practical Examples of Events

In the next post, we'll look at a few examples as to how we can hook into events provided by WordPress. These will be very introductory and most experienced WordPress developers will likely already know many of them; however, it will provide a solid set of examples as to how actions and filters - and thus events - work in WordPress.

After that, we'll then continue our discussion as to the features and facilities that WordPress offers for building web applications.