Load plugin selectively for pages or posts, etc

It´s possible select which plugin load by page or post […]?

Short answer: Not with a plugin (nor with code in a theme).

Normally, in WordPress, you use conditional tags to undestand in which post or page you are, e.g. you can use is_page('my-page') or is_post(12) and so on.

The problem is these conditional tags are available after the query for the current url is parsed, and when that happen all the plugins and the theme are already loaded, so there is no chance (a time-machine API is not available in WordPress, at the moment).

Even if you directly look at request url (instead of at query via conditional tags) there is no way to be sure your plugin runs before the plugins it is intended to disable.

The only possible solution is to use a MU plugin, that looks into request url and selectively disable plugins. That is possible because MU plugins are loaded before regular plugins.

To do that you can filter 'option_active_plugins'. An changing the result of get_option(), as explained in this @toscho answer.

So, create a MU plugin and in it put something like (code is just example):

<?php
add_filter( 'option_active_plugins', 'enable_plugins_selectively' );

function enable_plugins_selectively( $plugins ) {
  $current_page = add_query_arg( array() );

  switch ($current_page) {
      case "https://wordpress.stackexchange.com/" : // enable specific plugins for home page
        $plugins = array(
          'plugin_dir/plugin_file.php',
          'third_plugin_dir/third_plugin_file.php',
        );
        break;

      case '/a-page/' : // enable specific plugins for this page
        $plugins = array(
          'plugin_dir/plugin_file.php',
          'third_plugin_dir/third_plugin_file.php',
        );
        break;

      case '/2013/09/hello-world/' : // disable specific plugin for this post
        if (array_key_exists('plugin_dir/plugin_file.php', $plugins) ) {
           unset( $plugins[ array_search('plugin_dir/plugin_file.php', $plugins) ] );
        }
        break;
  }
  return $plugins;
}

Even if you can use regular expressions to check some urls, you should ask yourself if it worth the trouble: all these hardcoded urls are a pain to maintain.

Understanding the problem

Instead of making assumption that a plugin slow down page loading, best thing to do is to make some test, and effectively see the performance impact.
There are genericc PHP tools for the scope and even WordPress plugins, like Query Monitor or Laps.

A different approach

Normally plugins do their work using hooks: by calling a series of add_action / add_filter to attach some behaviour to hooks.

By using specular remove_action / remove_filter you can stop plugins to do some expensive actions when you do not need them. This will not stop the plugin file to be actually required by WordPress, but in the order of 30 plugins that should not be a problem (and with modern versions of PHP the performance impact of that will be very small).

Leave a Comment