WordPress under the hood: the request lifecycle

#wordpress #php #opensource

When a developer starts to work with WordPress (or any other CMS or web framework by the way), one of the most important things to learn is how it works under the hood. In the case of WordPress, we have to understand the WordPress page lifecycle.
For those who built web applications in general with other frameworks, the concept of a page request lifecycle is already familiar. But when it comes to WordPress there are some differences. WordPress actions and filters model may end up confusing some people coming from other backgrounds

The purpose of this article is to get your attention to this really important topic, as the understanding of this will help to know when to properly include the various WordPress hooks and filters, how the different files involved in a typical WordPress request interact with each other, and how data is queried and rendered to the browser.

WordPress Under the Hood

Below there's an image that illustrates easily how the "WordPress Core thinks" happens.

Image credits: Tom MC Farlin

A simplified resume of this "WordPress thinking" would be the following:

index.php: entry point of WordPress front-end requests, it will run whenever a request is made to anything, not under the wp-admin directory;
WP_USE_THEMES constant is set up;
wp-blog-header.php: is the first additional file required and sets up the WordPress environment by requiring the wp-load.php file. It also calls the wp() function (save this information);
wp-load.php: the ABSPATH constant is defined, sets some error_reporting levels and finds and loads the wp-config.php file OR attempts to redirect the user to create the wp-config.php file if it doesn't exist;
wp-config.php: defines the DB constants, debugging constants, and other constants that your WordPress installation might need, also requires the wp-settings.php file;
wp-settings.php file which sets up the WordPress environment. It does a lot of work, so there's a special list for this item:
- Sets up version information and requires all files needed for initialization;
- Set up most default constants;
- Check for maintenance mode and checks for debug mode;
- Requires the core WordPress files needed for the core WordPress functionality;
- Sets up the database layer and any global database variables;
- Initializes multisite if multisite is enabled; Loads the localization libraries and runs the installer if WordPress is not installed
- Loads the rest of any WordPress files needed;
- Loads any must-use plugins;
- Loads any network-activated plugins (if they are installed on a multisite);
- Sets up any specific cookie constants or SSL constants and then includes a vars.php file which creates any common global variables;
- Calls the functions that create the initial taxonomies and custom post types: page and post types;
- Registers the theme directory root;
- Loads all the active plugins;
- Loads pluggable functions;
- Defines any additional constants which may be required;
- Calls a function to add magic quotes to any GET or POST request variables and sets up the request array;
- Creates an instance of the WordPress query object, the WordPress rewrite object, the main WordPress object, the widget factory object, and the user roles object;
- Creates any template-related constants and any default text localization domains, creates a locale object, and a locale switch object;
- Loads the functions.php file for the active theme;
- Creates an instance of the WP Site Health object;
- Sets up the current user;
- Checks the site status;
- Runs the wp_loaded action hook;
wp(); function: After the wp-settings.php finishes its work, the wp-blog-header.php calls the wp() function. This function determines what needs to be rendered and fetches the relevant data from the database;
template-loader.php: After all the query data is set up the template loader is required. It finds and loads the correct template based on the visitor’s URL.

I linked the WordPress core files that I mentioned, which are all available on the official WordPress Core GitHub repository, so you can "read" directly those files and understand by yourself what I tried to resume.

On time, for more information I would recommend checking the information provided by WordPress Codex and also this amazing article written by Jonathan Bossenger.

Feel free to comment or include some important information I may have forgotten!