There may be times in WordPress where you would like to load the WordPress environment manually, and prevent plugins from loading.
Two instances where this is ideal are:
- When loading an inline frame with Thickbox or Colorbox.
- When parsing AJAX requests in an external PHP file.
To further give justification for this technique, I had a major plugin conflict with another plugin. My Ajax Edit Comments plugin had failed to work for one of my clients.
After doing some troubleshooting, I determined it was a plugin conflict with “xyz” plugin. When I looked at the conflicting plugin’s code, I was able to pinpoint the problem to one patch of code, but failed to determine a fix.
The conflicting plugin was causing my nonces to fail, as well as my AJAX processor to fail (since that uses nonces as well).
Since my plugin’s editing options are all in a Colorbox inline frame (where I manually load the WordPress environment), I figured I would only load the plugins I needed (mine in this case).
Okay, enough chat! Let’s get started.
To call this technique a “hack” is a huge compliment. I wouldn’t recommend this for widespread use.
The Technique
If you look at your wp-settings.php file, there is a conditional right before it loads your active plugins.
It checks to see if the constant WP_INSTALLING is defined. If it is, WordPress doesn’t load any plugins.
So the trick to “trick” WordPress is to define the constant, and then manually load the WordPress environment.
After that, we can load any plugins desired.
Here’s some code:
<?php header('Content-Type: text/html'); define('WP_INSTALLING', true); //Adjust the dirnames to match the path to your wp-load file. $root = dirname(dirname(dirname(dirname(dirname(__FILE__))))); if (file_exists($root.'/wp-load.php')) { // WP 2.6 require_once($root.'/wp-load.php'); } else { // Before 2.6 require_once($root.'/wp-config.php'); } $plugin = 'your-plugin-directory/your-plugin-file.php'; // Validate plugin filename if ( !validate_file($plugin) && '.php' == substr($plugin, -4) && file_exists(WP_PLUGIN_DIR . '/' . $plugin)) { include_once(WP_PLUGIN_DIR . '/' . $plugin); } unset($plugin); ?>
You’ll see from the snippet above that we define the constant WP_INSTALLING, and then load the WordPress environment.
After WordPress has loaded, we load the plugin file we need.
If you need more than one plugin loaded, you can use a simple foreach statement.
$current_plugins = get_option( 'active_plugins' ); if ( is_array($current_plugins)) { foreach ( $current_plugins as $plugin ) { // $plugin looks like: your-plugin-dir/your-plugin-file.php switch($plugin) { case: 'yourplugin': case: 'anotherplugin': break; default: continue; } if ( !validate_file($plugin) && '.php' == substr($plugin, -4) && file_exists(WP_PLUGIN_DIR . '/' . $plugin)) { include_once(WP_PLUGIN_DIR . '/' . $plugin); } } unset($plugin); } unset($current_plugins);
I would advise that you use this technique only in standalone files where needed, as I’m not sure of the long-term side-effects that might occur if the WP_INSTALLING constant is always defined.
Yuck! Bad, bad hack. Have you posted your issue to the forum or mailing list? There should be better, proper solution than this.
Why bother? Check the wp-settings.php file yourself.
Sure, there’s an apply_filter in there, but it’s useless because the plugins have already been loaded before you can add a filter in a plugin or a theme’s functions.php file.
Only way I can think of working around using the hack is to load plugins.php in your wp-config file and add the filter there.
Well, at least submit a bug report and/or propose a patch to core one for handling conflicting nonces, and another for a method not to load plugins.
Um, no.
This method has a very specific use for standalone pages.
If you don’t like it, don’t use it.
Additionally, the nonces problem wasn’t with WordPress, is was with the plugin in question (which the client couldn’t afford to uninstall as it was a proprietary e-commerce solution).
Nice tips, thanks for sharing. I have experienced from this and it takes time to load too.
I just wish all the plugins would be tested by WordPress or they could be certified for $5. I would save so much time to not have to “debug” them.
Indeed, I can’t think of another way to do this. It *is* a bit of a scary hack and I agree with your emphasis when saying that you don’t recommend it for wide use.
This said, I can’t think of any situation I would use this except on a test install: there are so many plugins that can do so many stuff at a very low level (redefine the way WP sends emails, enforce SSL for login, modify the auth system, etc…) that preventing all plugins to load could well break everything instead of fixing one thing.
The fact is, WP doesn’t provide an API (like filters) to easily select which plugin to load (or at least none that I know of). I’m not sure whether it’s needed or not, or whether it would even be a good thing (for instance, it could get a bit too easy for a plugin dev to simply deactivate other plugins known to conflict with their own, instead of improving their code and make things compatible) but that may be worth a proposal on wp-hackers to see if the idea gets a bit of traction.
Anyway, that’s still the kind of dirty hack I’m glad to know about. Even if I won’t implement it in a plugin or something, I like to know how details work under the hood and eventually how to modify them.
First time i came to this blog an now is on my favorite list. Thank for the tip.
Another way:
Turn on the hack_file option, then add code to a my-hacks.php file. In there, add a filter to active_plugins based on whatever criteria you like (URL, perhaps).
Another (horrifying) way:
Look at the loader in wp-settings.php again. $current_plugins is defined in the global context. If your plugin is smart enough to move itself to the beginning of the active_plugins array and decides to modify the global $current_plugins, it can prevent any plugin you like from loading.
Awesome! The latter approach seems less horrifying to me, wonder why you called it horrifying :/
Perhaps I don’t understand the purpose or distinction, but I edit the SQL database to disable plugins.
I thought there ought to be a simple way to hook in after the plugins had been loaded an unload them, but then I suppose at that point they would have registered all their hooks and you would have to go and unregister those as well, which would mean knowing which hooks had been registered internally.
When Otto’s second solution sounds pretty nice, it’s impossible. The plugins are called inside a foreach(), which works with a COPY of $current_plugins instead of the array itself. So in the end, the whole active plugin list will gets executed anyway. I learned this the hard way (sigh).
thank you for the post and the insightful comments (@andrew and @phoenixheart) … we’ve had alot of problems with the wordpress implementation for the blog on our site, and its plug-in’s causing things to load slowly and occasionally breaking. i’m excited to have a “hack” to try out, as a potential way to fix it. Generally I find WordPress great for the price (free?!!) but you’re right when you say its easy to “break”. Actually just had to recode our entire blog as we messed up the templates trying to fix one thing, which then broke several other things : )
I saw my collegue Nathan posted, and wanted to chime in, that we’ve had all kinds of issues with our wordpress implementation. I’m totally going to try and get us to “trick” wordpress into not loading some of the default plug-in that it has. We buy the Elegant Themes, which sometimes even have crap plug-ins to secretly set cookies or spam (found when they broke a few other functions). So i think this might come in handy for that part too … thanks!
it’s been couple of years, did anybody figure out a better way to do this than using WP_INSTALLING?
Hi
I use two themes on WP site, one regular for desktop/laptop visitors, and another simple theme for mobile devices. There is one plugin that is loaded in that mobile theme and I would like to disable it just when that theme is loaded. Is it possible and if it is can you give me some tips?
Thanks