3

It's possible select which plugin load by page or post, because i have 35 plugins and many of these no necessary in many pages or posts and only for some pages, how can do this?

I've tested beta plugin for this but it doesn't work right and I want to know if exists code in wordpress to deactivate plugin in some pages or posts that I can use to create my plugin.

  • 1
    Plugin Organizer is is a well-supported plugin that enables the selective loading of other plugins based on URL. It works great on my site. – lflier Feb 20 '15 at 18:40
5

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 '/' : // 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).

  • These may be hard to maintain but it's a golden solution for special edge cases like mine. I have a commercial plugin to showcase, and the fact that it's made compatible with certain other plugins. But also it's big portal with hundreds of other pages where I don't want xyz plugin to have any trace. Only one 1 demo page per plugin where I demonstrate the connection between 2 different products. – Firsh - LetsWP.io Mar 19 '15 at 12:28
  • What about it.wordpress.org/plugins/plugin-organizer – Revious Sep 22 '16 at 8:32
  • @Revious that plugin uses the first approach I described. It checks the URL to understand which post is shown. Instead of putting pages / posts URL directly in code (like in my proof of concept code), it provides a metabox to store the URLs in database, then read the stored values and enable/disable plugins accordingly. And as I described, it uses a MU plugin to do that, because that's the only possible way. – gmazzap Sep 23 '16 at 14:25
  • Im not shure if (array_key_exists('plugin_dir/plugin_file.php', $plugins) ) is correct (?) when $plugins has int() keys, not associative keys. maybe if(in_array('plugin_dir/plugin_file.php', $plugins)) is the way to go? My $plugins array looks like this: array(33) { [0]=> string(31) "add-admin-css/add-admin-css.php" [1]=> string(45) "admin-menu-post-list/admin-menu-post-list.php" [2]=> and so on... – Jonas Lundman Oct 24 '17 at 23:09
  • I've always found it silly that this is an opt-out situation. Why should it be assumed by default that all resources should be loaded across the website? For example, install Contact Form 7 and use it on one single page (e.g. a contact form) but all the JS/CSS gets loaded on every post and page. How is this considered more ideal? Well, I suppose after years of this, it's too late to change. – MarsAndBack Nov 14 '18 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.