WordPress Lifecycle explains how the core system prepares itself by performing a number of tasks one after the other. During the lifecycle process, WordPress offers a number of points called Hooks. This Hook system sits at the heart of the WordPress lifecycle that adds great flexibility and extensibility for WordPress theme and plugin developers.
WordPress Lifecycle
What is WordPress lifecycle? Before going deeper into the core, let me simplify the term “lifecycle”. In a nutshell, the process explains the steps a software has to perform in order to make it ready for the user. These steps are linked to each other and follow a chronological order from the start to the ready state.
WordPress also performs a similar logic to complete this lifecycle by following a pre-defined order of preferences. Once the lifecycle completes WordPress becomes usable for the users.
What is a Hook in WordPress?
Instead of a purely technical explanation, I would take an example of a very common and real-world situation for this. Let’s imagine you are traveling on a train from Station-A to Station-B, with Station-B as the terminating station. The train stops at five in-between stations during its journey. Each of these stoppages is a point where some dedicated tasks are assigned to the train manager and the station masters. However, you can also do something specific when the train arrives at these stoppages. This is pretty common, right?
Great. Now let’s try to build a relationship between the train and WordPress to explain the lifecycle and hooks. In order to establish the connection, I will replace the train with WordPress, the jounrney between Station-A and Station-F as the lifecycle, and finally, the in-between stoppages as the Hooks in the lifecycle where WordPress has pre-defined tasks. In addition to that it gives you the power to do something for yourself.
The Relationship Table
| Train | Action | WordPress | Action |
| Station A | Train starts running | Requests the server | Starts loading |
| Station B | Default: Ticket examiner boards the train and checks passengers’ tickets. You: Get down of the train to have some coffee | Loads Must Use Plugins. Hook: muplugins_loaded | Fires all functions that are hooked to muplugins_loaded At this stage, you can trigger your function by hooking it to muplugins_loaded hook. |
| Station C | Default: Train manager collects orders for food from the passengers. You: no action | Loads active plugins in your WordPress application. Hook: plugins_loaded | You can check for version compatibility or instantiate your main plugin class or loader. |
| Station D | Default: The categring service boards the train with foods ordered by the passesngers. You: buy a travel magazine and a bottle of water | WordPress is ready for starting the Initialization process. Action Hook: init | You can write your own function to hook to ‘init’ as well. For example you can write functions to register your own Custom Post Type or Custom Taxnomy and hook them to ‘init’. |
| Station E | Default: Crew changes. You: Go to the pantry for another cup of coffee. | WordPress fires the hook wp_enqueue_scripts to register default JavaScript and CSS libraries | You can write function to include your custon JavaScript and CSS code at this time by hooking the functions to wp_enqueue_scripts hook. |
| Station F | Default: Train arrives at the destination. The journey completes. | At the end of the lifecyle WordPress fires the “shutdown” hook. | You can write your own function and hook into “shutdown”, for example cleaning up temporary data, flusing buffers, etc. |
Important to note that there are more hooks fire during a complete WordPress lifecycle. I have referred only a few hooks to show the relationship and keep the lifecycle simple to understand.
From Platform to WordPress: Translating the Train Analogy
Before diggng deeper into the code, we build a transformation table to understand it better.
| The Train Concept | The WordPress Technicality | The Code Term |
| The Station | The Hook name | hook_name |
| The passenger’s plan | The custom function | callback_function |
| The reservation | Linking the two together | add_action |
The Handshaking in WordPress Lifecycle
Imagine the train stops at a station, but you have no plan of action yet. What happens? The train heads to its next stoppage after completing its scheduled tasks at that station. Meaning, although you had the chance to do something of your own, you did not. In short, to execute an event at a certain point in the WordPress lifecycle, your must register your action. By doing this you are instructing WordPress execute your function whenever it reaches a certain point in the lifecyle. Let us take an example of the two popular WordPress action hooks: init and wp_enqueue_scripts.
Let’s build a real-world simple callback function to hook to init. When WordPress lifecycle reaches this point, it automatically encounters your custom method and fires.
The Train Example:
add_action( 'station_name', 'thing_to_do_here', 10 );
function thing_to_do_here() {
echo 'Get a cup of hot coffee and a bottole of water';
}
If there are 20 passengers asking for coffee at the same time, the third parameter (10) decides the priority, i.e. whom to serve first. The lower number gets the advantage.The WordPress Example:
The hook name station_name becomes init and thing_to_do_here becomes register_book_post_type
add_action( 'init', 'register_book_post_type', 10 );
function register_book_post_type() {
$labels = array(
'name' => _x( 'Books', 'Post type general name', 'textdomain' ),
'singular_name' => _x( 'Book', 'Post type singular name', 'textdomain' ),
'menu_name' => _x( 'Books', 'Admin Menu text', 'textdomain' ),
.....
);
$args = array(
'labels' => $labels,
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
...
);
register_post_type( 'book', $args );
}Stay in touch for the Part 2 of Mastering the WordPress 6.x Lifecycle!
