Computer programmers love to think about systems. In doing that, they generalize how they work and how we can classify them. So you’ll find lots of people talking about “design patterns” — both loved and hated ones — that are common across the architecture of many different software systems.
One of my favorite patterns — having faced down more than a few legacy PHP apps that would have been much easier to change if they’d used it initially — is the Front Controller pattern. And WordPress uses it to powerful effect. Understanding the front controller pattern, how WordPress uses it, and what effect that has is really useful and helps you wrap your head around some other things about WordPress, so we’ll dive in.
What is the Front Controller Pattern?
Like a house with only one door, the front controller is the only way that people are allowed to talk to and get data from an application.
Put simply, the front controller pattern is observed in a system that only has one entry point. Like a house with only one door, the front controller is the only way that people are allowed to talk to and get data from an application. This pattern is popular on the web because it makes it easier to make good URLs (in the WordPress world we like to call that “pretty permalinks”) and saves us from repeating ourselves in many different scripts building up the same structure we need to use to respond to a web request (a request for data from our website).
Just for clarity, the “opposite” pattern to the front controller is the “page controller” which is actually how the administration section of WordPress is handled. In a page controller system, each thing that person might want is handled by a separate script or web page.
I’m not gonna dive too deep into the specifics of each as concepts here. But there are a number of good resources on the net about these patterns generally, I recommend this comparison of the two from Uchitha Ranashinghe (though the images are broken the text table is a great comparison), and the definitions from Microsoft of the front and page controller patterns.
WordPress URLs and the Front Controller
If you’ve spent much time in WordPress you’ve probably realized that the theme doesn’t have a file in it for every page on your site, and that your theme isn’t just responding with raw pages to the front of your site. I remember when I was just getting started with it, I wanted to put a raw HTML page into my theme and have it accessible on my site. And it didn’t work. Now I know that’s because of the front controller that WordPress uses.
We all know that there are many different ways the URLs of our WordPress site can look. You’ve probably seen the “ugly” structure at least once before, which looks something like:
Some of your will likely know, but some of you may not, that this is identical to:
The server software — Apache of Nginx — massages those two so they work the same. It’s also possible for them to massage less obvious things into this format. Perhaps, something like this:
In Apache, this is done through the mod_rewrite module, which you usually interact with in a .htaccess file. For Nginx, the term of art is less obscure: it’s the configuration. But in either case, all three of these URLs will get from our WordPress installation here the exact same thing — this article. They’re all hitting the WordPress front controller and finding this article — the first two through the ID, the last through a bit more complex a procedure — and rendering the page through our theme. Pretty cool, right?
What the WordPress Front Controller Does
As you may be thinking after that the WordPress front controller is your index.php file. The root index.php file to be exact (since WordPress like many other PHP apps also has a ton of others). The root index.php file of your theme is your front controller. All requests on the front side of your site — whether for search results, a tag archive, a static page, or a blog index page — gets rooted through the index.php file.
So what’s in there? Well, not much really:
<?php
/**
* Front to the WordPress application. This file doesn't do anything, but loads
* wp-blog-header.php which does and tells WordPress to load the theme.
*
* @package WordPress
*/
/**
* Tells WordPress to load the WordPress theme and output it.
* @var bool
*/
define('WP_USE_THEMES', true);
/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wp-blog-header.php' );
If you’re at all familiar with PHP — or almost any other — programming syntax, you’ll notice that much of this file is comments. Only two lines of actual code exist in it.
A constant — WP_USE_THEME is defined, and then another file is required (which is to say included in the execution of this file). That’s it.
We could follow the chain of requires and definitions along the chain of WordPress’s functioning all the way until your page is rendered and returned, but that’s far past the sane scope of one single internet article. And well past what you need to understand to know the front controller pattern.
Things to know about the WordPress front controller
So what have we learned?
- All WordPress pages on the front in go through a “front controller”, located at
index.php. .htaccessfiles are used to route Apache requests for URL’s that don’t map to the underlying file system to the front controller. This is how your articles get “pretty permalinks”, and how WordPress catches all the “Page not found” or 404 requests on your site.- The front controller is how files from all around the WordPress file system are included in the response to a single request. The front controller starts a chain that rounds up files located far away from the root URLs of your site, typically in
wp-content/themes/theme-name/, and uses them to show your pages using the specific look you define.
There is more depths to design patterns, the front controller, and how all these things work with WordPress. Comments are open and as always I’d love to hear what you’re wondering or what I missed. Thanks for reading!
[…] this would only require one line of code. I knew it had to be pretty simple because WordPress uses the front controller design pattern, and so had to be “bootstrapping” — loading up — its functionality somewhere. I […]