Monthly Archive: December 2013


How to Set Up a Simple WordPress Contact Form in 30 Seconds

There are few websites these days that don’t have a “Contact” page containing a neatly laid out contact form. Adding a contact form to your site is a great way to help visitors get in touch with you without having to give out your email address. There are dozens of contact form plugins out there for WordPress sites with all kinds of features, but often all you need is something simple. In this quick tutorial I’ll show you how to set up a basic contact form.



Using WordPress for Web Application Development

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 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, 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, y’know, 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.



Sites of the Week for December 26th 2013

Line25 Sites of the Week is a weekly roundup of the most outstanding website designs that I stumble across during my every day browsing. In this week’s collection, we have designs from HARBR, Portfoliobox, DWP, Conjure and HelloHired. HARBR View the website Portfoliobox View the website DWP View the website Conjure View the website HelloHired […]



Freebie: Exo 2.0, A Contemporary Geometric Sans Serif Font

Back in the days when he was a student, Portuguese graphic and type designer Natanael Gama started to play with glyphs — as a way to discover typography. Doodling around, he created Exo, a font which he released for free in a Kickstarter project. The project turned out to be […]



Effective Use of Blurred Images in Web Design

Large background images have been in use for some time now in website design, however, using sharp, in-focus images can bring complications, and doesn’t always have the desired effect. The use of blurred images has a few advantages. A major advantage is that the image resolution does not have to be as high as an […]