If you’ve been developing for a while, hopefully you aren’t cowboy coding any more and are using local and staging environments for your development instead.
If you are, then there’s probably a few plugins that you don’t want active on your local or staging environments. For example, I don’t want Google Analytics or InfiniteWP running unless it’s the production server, so here’s how I get around that.
Since my local environments have their own config file, I set a define that indicates what kind of environment I am running:
Then you need to create a plugin which will go in mu-plugins. It must go in mu-plugins because this fires early enough to be able to deactivate the plugins in question before WordPress tries to load the plugins. Also, if you’re syncing your production database to your local environment, then the active plugins will be synced every time as well, so if you install this plugin as a regular plugin, then it will be deactivated every time the database is synced.
The plugin is quite simple: it checks for the WP_ENV define that we set up earlier in wp-config.php and if it’s set and equal to ‘dev’, then it runs deactivate_plugins() to deactivate the plugins in question (you could modify this so that unless WP_ENV is equal to ‘production’ then it deactivates the plugins, allowing for more options that just dev and production):
You can add or remove plugins as necessary from the array to deactivate the plugins that make sense for you (note that you need to include a path from wp-content/plugins to the plugin’s main file). Also note that after the plugins are deactivated, I used Jetpack’s development mode to stop WordPress from trying to speak to Jetpack, which can cause more issues.
In this way, you can fairly easily create a blacklist of plugins that should not be allowed to run on dev or staging servers.