Behind the Scenes Peek at How WordPress is Loaded: Part II

Listen to this article

install-wordpress-ubuntuAs 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.

[su_note note_color=”#fffdb0″ text_color=”#000000″]Quick tip: You’ll notice that WordPress loads a timer using the timer_start() function. The timer_stop() function is not called anywhere. You can use the timer_stop() function anywhere in your code to calculate the time elapsed from when a page request is made- to the point in your code.[/su_note]

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

[su_note note_color=”#fffdb0″ text_color=”#000000″]Quick tip: As a WordPress developer, if you want to hook into WordPress before other plugins are loaded, use the muplugins_loaded hook.[/su_note]

Load Plugins

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.

Load Theme

This is followed by the theme load process. By now most of WordPress is loaded. During the theme load process two hooks are fired:

    1. setup_theme is fired before the themes are loaded. Use this hook in your plugins to perform an action before themes are loaded.
    2. 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.

[su_note note_color=”#fffdb0″ text_color=”#000000″]Quick tip: If you want to hook into WordPress after WordPress is completely loaded, and once the plugins and theme are initialized, use the wp_loaded hook.[/su_note]

But there are two more steps before your webpage is finally displayed.

Hang on!


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.

[su_note note_color=”#fffdb0″ text_color=”#000000″]Quick tip: Use the template_redirect hook to perform some action before a template is loaded. You can use it to define additional templates as well.[/su_note]

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.

[su_note note_color=”#fffdb0″ text_color=”#000000″]Quick tip: The ‘What The File’ plugin can be used to display the files and template parts used to display the page currently being viewed.[/su_note]


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!



Leave a Reply

Your email address will not be published. Required fields are marked *

Get The Latest Updates

Subscribe to our Newsletter

A key to unlock the world of open-source. We promise not to spam your inbox.

Suggested Reads

Join our 55,000+ Subscribers

    The Wisdm Digest delivers all the latest news, and resources from the world of open-source businesses to your inbox.

    Suggested Reads