In programming, initialization of data is important as it's where we setup the prerequisites for the application such as its attributes, its required files and data, its connection to the database, and so on.

WordPress itself has a well-defined initialization procedure. Through the page life cycle, WordPress fires a number of actions many of which we've covered in previous articles. To that end, it provides a set of initialization hooks which are naturally used to initialize the application before executing its primary functionality.

As plugin and theme developers, it's important to understand the use cases and common mistakes of these initialization hooks, in order to build quality applications.

In this article, we are going to take a look at the importance of WordPress initialization hooks and how they are used in various scenarios.

Introduction To Initialization Hooks

WordPress provides a wide range of  hooks that can be used in plugin and theme development.

In a typical page request, all the action hooks are executed in a certain order. Specifically, all the  hooks are executed after the core WordPress application completes its loading process.

So initialization hooks are mainly used to, you guessed it, initialize the process in plugins and themes. Let's take a look at the available init hooks in WordPress, in the order of their execution:

• init runs after WordPress has finished loading but before any headers are sent. Generally, this used by plugins to initialize their process.
• widgets_init is used to register sidebar widgets of the application. The register_widgetfunction is executed within this hook.
• admin_init is executed as the first action, when user access the admin section of WordPress. Generally, it's used to initialize settings specific to the admin area.

You can also review the entire WordPress action hook execution process in the Codex.

WordPress executes each hook in a certain order (which you can see in the Codex). As such, it's important to consider the order of occurrence in using each action hook. Consider the following scenarios for identify the differences.

Defining admin_init Inside The init Hook

If necessary, we can define WordPress hooks within other hooks. In a typical request, init hook runs before the admin_init hook. So let's try to output something by placing admin_init inside the init hook:

add_action( 'init', 'test_init');
function test_init(){
    add_action( 'admin_init', 'test_admin_init');
}

function test_admin_init() {
    echo "Admin Init Inside Init";
}

After executing this code, we will get the desired output using the echo statement.

Defining init Inside The admin_init Hook

Let's see the code and output of this scenario where an earlier hook is defined inside a hook that comes later in the order of execution.

add_action( 'admin_init', 'test_admin_init');
function test_admin_init() {
    add_action( 'init', 'test_init');
}

function test_init() {
    echo "Init Inside Admin Init";
}

Here, we won't get any output - this is expected - because the init hook executes before admin_init hook, and thus it's not available after defining the admin_init hook.

As you can see, it's vital to understand the execution procedure of hooks for building successful plugins. Order of occurrence is important for all the hooks in WordPress.

Exploring The init and admin_init Hooks

Among the init hooks, init and admin_init is worth exploring as these two hooks are used widely in many plugins. Use of other initialization hooks are straightforward compared to these two hooks.

As such, we are going to look at the functionality of init and admin_init hooks.

The init hook is executed in each request for both the frontend of the WordPress site as well as the backend.

The admin_init hook is executed after the admin section completes its loading process. So this hook also executes on each and every admin page request. Users need to be logged in to take advantage of this hook.

Since both of these hooks are executed on each and every request, we have to plan the functionalities inside the implementation of these hooks accordingly as it can greatly impact the performance of the site.

How To Use init Hooks

Generally, initialization hooks are available in most of the existing WordPress plugins, and they are essential for managing their processing.

WordPress doesn't define what we should and what we shouldn't include; therefore, developers can make minor mistakes which, in turn, can result in a huge performance decrease. In this section, we are going to look at how we can effectively use both init and admin_init hooks.

Let's take a look at the best practices in using init hooks.

The init hook

• Registering custom post types - WordPress recommends the use of the init hook for registering new custom post types.
• Initializing your plugin configurations and settings - Plugin configurations and settings need to be defined in each and every request and hence its a good practice to include them inside this hook.
• Accessing user submitted data (Using $_GET and $_POST) - We can intercept user submitted data without any actions, but it's recommended to use the init hook as it guarantees the execution in each request.
• Adding new rewrite rules - We can define new rewrite rules using the init hook, but keep in mind that these new rules will only take effect once we flush the rewrite rules.
• Add or remove custom actions - Plugins contains many custom actions for extending the functionality. There will be scenarios where we need to add new custom actions as well as remove existing ones. In such occasions, it's essential to implement those activities within init hook.
• Load plugin text domain - WordPress offers multi-language support and thus we are allowed to load the file containing the translated strings. This should also be placed inside the init hook.

The admin_init hook

• Access control - It's essential to check the permissions of logged in users before allowing each user access to a specific set of features or functionality. admin_init is the first action to run in the admin area so we can use it for managing access control.
• Adding new settings - We can use this hook to add new setting pages or settings into the existing WordPress settings panel.

There are many other possible implementations with these hooks, but those features have their own hooks and it's not necessary to use the initialization hooks.

Common Mistakes of Using Initialization Hooks

Often, we find scenarios where developers misunderstand the use of the initialization hooks. Improper usage of said hooks can lead to serious performance issues (as well as low quality plugins).

Let's identify the common mistakes and how to avoid them:

• Flushing rewrite rules - This is a resource-intensive operation where all the rewrite rules are flushed and rearranged to add new and to remove unnecessary rules. Many developers flush the rewrites rules inside init actions and end up creating unnecessary performance overhead in each request. We should setup a way to manually flush the rewrite rules using a button or flush the rules on infrequent activities such as saving plugin settings.
• Accessing the database - It's a must to access the database for providing various functionality, but it's important to prevent unnecessary database calls inside initialization hooks as it gets executed on each request. To that end, it's ideal to assign database hooks in functionality-specific hooks to avoid major performance overhead.
• Executing upgrade routines - Plugins need to have an upgrade routine to upgrade its features for new versions. Generally, developers use init hooks to check plugin versions and settings before executing the upgrade process. We can let the users upgrade the plugin by providing a custom screen instead of automatically checking on each and every request.
• Using init hooks instead of functionality specific hooks - This is the most common mistake done by many developers. There are a wide range of hooks in WordPress targeting different, unique functionality. It's important to use functionality-specific hooks in order to avoid conflicts and make the code extensible. Hooks such as init and admin_init can be used instead of specific hooks so developers tend to use them without having the knowledge of their full effect. Some of the common scenarios where developers use init and admin_init hooks instead of the recommended hooks are as follows:
  • admin_menu - We can add menu pages using add_menu_page function. It's recommended to use admin_menu hook for creating admin pages. But many developers use admin_init hook as it's executed after admin_menu hook.
  • wp_enqueue_scripts - Recommended way of adding styles and scripts is to use wp_enqueue_scripts hook. But many developers use wp_enqueue_script inside the init hook to load scripts and styles.

There are number of similar situations where developers use common init hook instead of functionality specific hook and it should be prevented whenever possible.

Moving Forward with Initialization Hooks

WordPress initialization hooks play a vital part in plugin and theme development. Many developers misuse the hooks creating unnecessary performance overhead. In this article, we discussed the proper use of these hooks as well as common mistakes and how to avoid them.

Now we can apply the same technique to plugin specific custom hooks. Many advanced plugins uses their own action hooks to make them extensible. For such plugins, we can define plugin specific init hooks to let developers focus on the initialization tasks on predefined hooks instead using them all over the place.

Feel free to share your experiences of proper usage of init hooks as well as mistakes in using initialization hooks. Looking forward to seeing what you have to share in the comments!