WordPress 4.2 is around the corner, and if the folks at WPBeginner are right about how it’s going to work one of the “enhancements” in WordPress 4.2 will create a gigantic WordPress Plugin Problem.
We’re aware that what follows will sound nit-picky, just as we know that our advice on bypassing the WordPress Media Library will be ignored by most users. We also know that the folks who were bothered by this criticism of WordPress.org support will cry foul at what’s about to come. Criticize the WordPress mother ship? How dare we!?
One of the changes coming to WordPress 4.2 is a streamlining of the plugin installation process. While we’re all for the parts of this that make searching for and uploading plugins easier, it appears that when you install a plugin it will automatically be activated, and there’s no way to elect otherwise.
This is a big mistake.
We’ve been spoon-feeding you information about The WordPress Database, and encouraging you to learn a bit about it in pieces like this one on WordPress database fields, this article on WordPress database tables, and this piece on WordPress Database Password Hashing.
Here’s why automatic activation will be a Big WordPress Plugin Problem
Have you noticed that whenever you update WordPress you get a warning to back up your database before doing so? At The WordPress Helpers we say you need to backup your database before installing plug-ins, as well. New plugins not only can create new tables, but references from those tables to others can get created as well, and changes and additions can occur in your existing tables—most often the options table—and while cleaning them up should happen automatically, often this process fails. If you’re lucky, that doesn’t create any more of a problem than extra, orphaned database entries with no purpose, but you can’t count on that.
If you’ve ever had a problem that led to support advice like “first, deactivate all your plugins”, you understand why protecting your WordPress database matters.
This WordPress plugin problem isn’t undefeatable, but it takes away a layer of uh-oh protection that needn’t— and simply shouldn’t—go away. As it stands now, installing a plugin does nothing more than replicate what you do manually when you upload a plugin via FTP. You can then do your database maintenance before activating the plugin. But in WordPress 4.2 the simple act of installing a plugin will “do stuff” in your WordPress database. The control and protection you lose is not worth the simplicity you gain.
Hey, WordPress Guys? If you’re listening, please, please reverse course on this WordPress plugin problem, or at the very least make its behavior optional.