During the WordPress 4.2 cycle, one of the goals was to do some work aimed at improving the experience of users when updating and installing plugins.  While the decision was ultimately made to scale back to just updating for this release, the code that installed plugins also automatically activated plugins when a user installs them.  This generated a lot of controversy, but is ultimately what we should be doing for users.

The End User

Most end users of WordPress doesn’t have a staging site, doesn’t keep there site in version control, and doesn’t install plugins to activate them later on. When they install a plugin, they start using it right away. When they install a plugin, they want to either play with it to see if it works for them, or they set it up and start using it.

One of WordPress’s biggest strengths are it’s philosophies. One of them is that WordPress designs for the majority:

Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.

By following this philosophy, it is really easy for see that auto activation is the right path.

How about an option?

Some of the comments about this is that it should be a checkbox.  People think that the solution to a complicated and controversial decision is to add an option.  The WordPress philosophies once again guide us to say that an option shouldn’t be our default answer. We need to make smart decisions instead.

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

Yes, there are right times to add options. Andy Adams points this out when he wrote:

Instead of making a theme either fully-customizable or configuration-free, I’ve realized that the ultimate goal is to add “just the right options” to make the user experience more pleasant

There are absolutely use cases for not auto activating.  Some developers like to use the UI to do installs locally and then check out the code before deciding to install a plugin.  There are also plugins such as ones that enable a maintenance mode or help with debugging that you want easily available, but not necessarily activated.  These are the exception though, not the rule.

Why Installs are not a part of 4.2

This leads us to now.  Despite auto activating being the right decision, the decision was made to remove auto installs in large part do to auto activation.  This is a decision I ultimately advocated for taking.  The problem wasn’t the activation, it was the experience of what happens after activating.  The UX needs to be cleaned up there.  We need to make it possible for some plugins to opt-out and we need to make it easier for users to take action right after installing a plugin.

Shiny installs will be back, and when they come back I fully intend to advocate for auto activation. This may change with more information, but right now it is the right choice.