There comes a time in the life of a WordPress developer, no matter what his/her experience is, when he/she needs to run some plugins only in a local environment. Such cases could be related to plugins meant for testing, importing, deleting data, etc. I think you get the idea: I’m talking about any plugins that are not meant for a live site. The problem here is, given the fact that you need those plugins for your development cycle, how can you keep them from being active when you deploy your site to a production stage? And there’s another important question about this: Do you even need those plugins to be uploaded to your live site?

Yeah, sure you can manually deactivate those plugins once the site goes to production, but what if you need to do some maintenance? Let’s say you pull the remote database to your local stage in order to continue your local work after a deploy. Then you need to manually activate your development plugins again. And let’s suppose you finish your work by now and update your live site with your local changes, including a possibly modified database. Then your development plugins get activated again, so you need to manually deactivate them once more. And now let’s say you do all of this at least once a week, and that you also have a testing server. That’s a whole bunch of time that you’re losing in repetitive tasks. You could use that time to read some XKCD, or learning to dance Gangnam Style.

Well, there’s a couple of things you can do to solve this issue.

Filter by IP

This is the simplest way to have some plugins working  while you develop. Just by knowing your IP you can automatically activate the plugins you want. You could add something like this to a MU plugin:

You can even add your own functions and filters for testing and production stages too. Keep in mind that you could also remove plugins from the list just by unsetting them from the $plugins array. Also, if you’re dealing with a multisite installation, you need to hook into site_option_active_sitewide_plugins instead of option_active_plugins. That could solve our problem by now, but this method has a downside: If some IP address changes, you’re gonna need to modify the plugin, so maybe we need to do a little more. ## Use Different Configuration Files for Different Stages By using different config files for each one of your stages, you can perform different actions based on the stage you’re in. Take the following model of a wp-config.php file as an example:

With something like this, you need to take care of not deploying local-config.php to production or staging, or staging-config.php to production. If you deploy using Git, or use a deployment script such as WP-Stack or Stage WP, this should be easy for you. In case you’re still attached to FTP/SFTP, you may need to exclude the files manually. In any case, our former code can be improved to this:

Of course you can go one step further and use Mark Jaquith’s Gist, which offers a much more advanced approach to enabling and disabling plugins using this method.

Now the not-so-great thing: You need to code to add or remove items from your list. If you just do it once in a while, that would be no problem. But if you do it often, then you’ve got a problem. That means that you have a piece of code that is not as much stable as it should be. And unstable code means more work.

Use WP Stage Plugin Manager

There’s this plugin that I built myself to deal with this problem. You can use it to select which plugins you want to be active in which stages, and it helps you to set up those stages and even add your own ones. It provides a lot of hooks, so you can add or modify it’s functionality in any way you want. I think it’s a very useful plugin, and that it can help to win a lot of precious time. You can download it from the WordPress Repository.

But wait. Maybe you don’t even need those development plugins to be uploaded to your production site. What if some user activates one of those plugins by error and that ends up causing a mess in the website? You may not want that. Sure, you can exclude the plugins you want from your deployment script, but what if you have a lot of them? Maybe that could mean a lot of work, and you may not want that either. And if don’t want any of those things, the former methods can turn useless. So you see how this is a difficult scenario.

Use a MU Plugin to Load Other Stage-Restricted Plugins

Well, this is something pretty experimental that I came up with, so maybe there are better alternatives. But I currently use this in some sites, and it sure works.

This method requires that you save your development plugins into a separated directory, besides plugins and mu-plugins. For our practical purposes, we’ll call that new third directory local-plugins. Then you need to create a MU plugin with something like this:

This will load all the plugins you specify from the local-plugins directory right after all the MU plugins are loaded, and before standard plugins begin to load, so it should not be used for plugins that need some other standard plugin to be loaded first.

To keep these development plugins away from your production site, just exclude local-plugins in your deployment script.

The bad thing is that you still need to modify your code if you change your list of local plugins. The good one is that you still can write a plugin to automatize this kind of management.

It’s some kind of great thing, right? The fact that you can write plugins to manage other plugins. It’s like being meta and doing self-references all the friggin’ time! But be careful, because you never know how much meta is too much meta?

Have Any Question or Suggestion?

Please use the comments section. It would be awesome to have some feedback from you and know what other methods you use to work around this issue.