As is the case with any PHP based website, the load process begins with index.php. And WordPress is no different. As explained in Part I: Behind the Scenes Peek at How WordPress is Loaded, the process continues from index.php, and through various steps reaches wp-settings.php.
In this post we’ll take a look at how wp-settings.php actually loads WordPress core. The process as such is quite elaborate. I’ll try and make it as simple as possible, by explaining the key points.
The process (as you would notice in wp-settings.php) is divided into two parts by a constant SHORTINIT. If the SHORTINIT constant is set to true, the bare minimum WordPress files are loaded. This maybe needed when using WordPress database or in order to integrate it into a different framework.
Let’s take a bit more detailed look at this.
Load Minimal WordPress Functions
wp-settings.php starts by setting a constant WPINC, which is the wp-includes folder. As you would notice, most of the files loaded are from the wp-includes folder. Because the wp-includes folder is where the core resides.
The process continues by loading initial files, setting constants, checking PHP and mySQL versions, the maintenance mode and so on.
Next, the core files such as the Plugin API, the Main class file, Error API, language files are loaded. If you’re a plugin developer, you need to know the ins-and-outs of the Plugin API file- plugin.php.
It then sets the database connection, registers default actions and filters (once again, a must know file for plugin and theme developers- default-filters.php), loads object cache, and checks for multisite.
Once this is done, minimal WordPress files are loaded, and it is at this point that SHORTINIT constant is checked.
Load Most of WordPress
Next most of WordPress is loaded. This includes- well, everything– the WordPress translation API, WordPress classes (walker, capabilities, query, meta, navigation menu, cron, taxonomy, update and so on), plugin directory constants are initialized.
Load Must Use Plugins
Here must use and network activated plugins are loaded, and the first action hook in WordPress is fired- ‘muplugins_loaded’.
The process continues by registering taxonomies and post types, and loading active plugins. The ‘plugins_loaded’ hook is then fired.
Next core classes are created, such as the WordPress object, WordPress Query object, WordPress rewrite object, WordPress Widget Factory object and WordPress User Roles object.
This is followed by the theme load process. By now most of WordPress is loaded. During the theme load process two hooks are fired:
- setup_theme is fired before the themes are loaded. Use this hook in your plugins to perform an action before themes are loaded.
- after_setup_theme is fired after defining template constants, loading the text localization domain, loading the functions file of the active theme (child theme followed by parent theme). Hook on to this if you want to perform some action immediately upon the theme being loaded, but before the current user is set up.
WordPress fires a hook ‘init’ as soon as most of WordPress is loaded, and the current user is authenticated, but before the headers are sent. As a WordPress developer, you’ll have be familiar with the init hook. This hook is used to instantiate plugins.
And finally! There is one last check for multisite and WordPress is finally completely loaded and the wp_loaded hook is fired.
But there are two more steps before your webpage is finally displayed.
WordPress Template Hierarchy
The process which began with index.php, has still not ended. :D. There are two more steps. So by now WordPress is loaded. But if you trace back the process to where it started, you’ll notice that we had reached wp-settings.php from wp-blog-header.php.
Now, going back to wp-blog-header.php, we’ll notice there are two steps which remain. These steps will finally render the page requested.
Get the Posts to be Displayed
First WordPress query is set up by the wp() function. This function parses the request made and queries for the posts. So now you have the content which has to be displayed.
The display part is handled by a template, and that’s just what happens next.
Get the Template
In WordPress, templates are files which contain the HTML to display data on a page. So, you could say templates structure the content queried. These templates are fed by the theme. Your theme contains several template files which are linked to certain type of content. For example, there is a archive page template, home page template, blog page template, page not found template, and so on.
Get the Page Type Requested
WordPress resolves the query string to fetch the requested template. There is a hierarchy in which templates are searched, and the first matching template is returned. The basic required template file that every theme must have is index.php.
In WordPress Codex, the Template Hierarchy section provides in detail the template hierarchy followed, and it’s explained very well, so I won’t be repeating any of that here.
So, (finally), by now you’re web page should be displayed (phew!).
I bet you didn’t know all this goes on behind the scenes when you make a simple page request. But you know, I’ve probably just scraped the tip of the iceberg. There’s a lot more going on. But for now, this peek at the process is good enough!
Over to you.
If you have any questions or comments, or have valuable information to add, do feel free to leave your thoughts in the comment section below!