Why you should do conditional loading of your plugins

One of the strengths that WordPress has are the plugins, one of the easiest ways to expand or extend the functionality that WordPress itself has to adapt it to our project and make it more powerful and competitive, as there are thousands of them available(most of them free), only in the official repository more than 54,000, and with multiple features. Long live the plugins!

But plugins are not only joys, as long as they fulfill their function for which they were designed, they also have a major problem, and is that they are always active, ie, our WordPress system always performs a load of all active plugins in the installation in each call to it, which can generate a performance problem on our server if in that particular call, a plugin is not needed. Do not live plugins! It is not that either, let them live, but when we decide. This is the concept of conditional loading: manage which plugins to load.

What is conditional loading of plugins

By way of basic definition, conditional plugin loading is another WPO strategy by which we decide whether a plugin needs to be loaded or not, based on certain factors that we decide:

• Which URL is being called.
• Who is making the call.
• At what time.
• In what environment.
• …..and even combinations of several factors.

In short, have total control over the load of active plugins at all times.

Example: Conditional loading of forms

A simple and common example is found in the plugins for creating forms, which we normally use in our contact pages, that is, on a single page of our entire site, but which is loaded in each and every one of the URLs even if the form is not needed.

Normally it can be seen in the front-end because it includes a call to a JS file and a CSS file of the plugin itself, although it also consumes load on the server, in the back-end, which is where we want to impact even more with this strategy, not loading unnecessary plugins.

In this case, we would have an appreciable improvement even in the front-end, although we will also see even simpler examples, not to load plugins that are only necessary in the WordPress administrator.

This strategy is complementary to all your current WPO strategies that you are already using in your WordPress projects.

All this is very good and now surely you are wondering what is the name of the wonderful plugin that does all this or where is the code.

I am sorry to tell you that this is not the case. As this is a technique “tailored” to each project, it is necessary to understand it and develop it to measure, we must create the programmatic conditions for each specific case that we want to control, although you will observe very soon that the patterns are repeated in almost all projects and you can reuse much of the code that you have generated. Remember, no two projects are the same but there are many recurring parts.

But don’t worry, I’m going to give you a few simple examples of use to wake up your head of “project optimizer” and that you will surely be able to implement by similarity in all your sites.

The first thing to explain is how to apply this technique, which is a very simple concept based on these two pillars:

• The option_active_plugins filter, which allows us to control which plugins will be loaded from among all the active ones. The idea is to tell WordPress which plugins will be loaded, as if we were to enter each request in the administrator and momentarily deactivate one or more plugins.
• A MU-Plugin, which is where we will place our code, since these are executed before the active plugins, allowing us total control over them.

And two notes before we start with the examples:

• This is a VERY dangerous technique, it is necessary to know in detail the site and how the plugins work.
• Normally use it only for the front-end, since in the back-end the plugins would appear deactivated or may cause errors.

Let’s get down to business. We start with the basic structure of our MU-Plugin, which will be of this style, very simple, with the call of the filter option_active_plugins to our function wphelp_option_active_plugins where we will modify the array of active plugins ($plugin_list), looking like this:

<?php
// Execute filter front-end
if(!is_admin())
    add_filter( 'option_active_plugins', 'wphelp_option_active_plugins', 1);
function wphelp_option_active_plugins ( $plugin_list ){
   //Conditions here
   //List of plugins
   return $plugin_list;
}
?>Code language: HTML, XML (xml)

Now let’s go with an example to understand how WordPress has referenced the plugins internally, which is the way we will use to remove them from the array.

As you can see by the result of the execution, the plugins are referenced by the name of the directory and the name of the PHP file that executes it:

<?php
if(!is_admin())
    add_filter( 'option_active_plugins', 'wphelp_option_active_plugins', 1);
function wphelp_option_active_plugins ( $plugin_list ){
   //Show plugins list
    print_r($plugin_list);
   exit; //Stop proccess
}
?>Code language: HTML, XML (xml)

Note: do not use the above example in a production environment, as it only executes that function and will generate an error to the user.

Based on the same concept and the first example we put, how would we do the conditional loading of the Contact Form 7 plugin only on the page where we have our contact form:

<?php
if(!is_admin())
    add_filter( 'option_active_plugins', 'wphelp_option_active_plugins', 1);
function wphelp_option_active_plugins ( $plugin_list ){
    $request_uri = parse_url($<em>SERVER['REQUEST</em>URI'], PHP_URL_PATH);
    //We check when it's necessary by the URL
    $is_cf7_needed = ($request_uri === '/contacto/' || strpos( $request_uri, '/wp-json/contact-form-7/v1/contact-forms/') !== false);
    //Remove when it's not
    if (!$is_cf7_needed)
        unset( $plugin_list[array_search( 'contact-form-7/wp-contact-form-7.php', $plugin_list)]);
    return $plugin_list;
}
?>Code language: HTML, XML (xml)

Note: the only complexity is to manage the two URLs that the plugin needs, the one of the page where we have embedded it, normally by means of a shortcode, and the one that the plugin needs internally to collect the data.

I hope this technique has awakened your desire to further optimize your projects.