The Simple Criteria That Determines Which Jetpack Modules Are Auto-Activated

Auto Activate Jetpack Modules Featured Image
photo credit: 2createcc

Since the release of Jetpack in 2011, there have been several articles highlighting the fact that it auto activates modules. George Stephanis, a member of the Jetpack development team, has consistently explained that “Jetpack only auto-activates modules that provide enhancements without affecting the front-end layout of the site.”

Earlier today, Stephanis published a post on his blog that goes into detail on how the decision is made to auto-activate a module.

We’ve spoken to many, many users who find a default feature set convenient, and resent having to make a bunch of ‘decision points’ if they had to manually activate each and every module. Good software should run well out of the box. So we’ve set up the defaults as we have. Yes, some people disagree and are vocal about not wanting anything to auto-activate. That’s okay. We try to design for the majority, with the best user experience we can provide.

I appreciate the fact that new modules will not auto-activate if they impact the front end of my site. In this instance, the decisions being made for me are a convenience, not a hassle. If you disagree with the decisions being made, there are several filters you can use to customize the Jetpack experience, including one to deactivate all modules by default.

add_filter( 'jetpack_get_default_modules', '__return_empty_array' );

I doubt his post will resonate with those who have a strong stance against auto-activating anything. As long as the development team stick to their current philosophy, I’m ok with it.


8 responses to “The Simple Criteria That Determines Which Jetpack Modules Are Auto-Activated”

  1. I’m in the “don’t activate anything without my knowledge” camp. That is just sound security/privacy practice in my line of work. Thanks for the add_filter recommendation–I’ll use that as standard on my sites from here on out!

  2. There is no good reason for Jetpack not to simply offer a “auto-activate new modules” toggle in the settings. Default it to on, let anti-activationists unset it and forget it. As pointed out in the article, there are filters to do this, and third-party plugins are available that code could be copied from (with permission, obviously) if the Jetpack team is too busy to do it themselves. “Designing for the majority” is no excuse when giving people a CHOICE is so damn easy.

    • Putting an option in to turn this behavior off is antithetical to having the behavior in the first place. Providing the user with a choice requires them to make a decision that frankly, they shouldn’t have to make. If auto-activating the module provides helpful functionality and doesn’t break anything, then providing an option to not auto-activate it is a decision that your average user should not have to bother with.

      I personally turn off most of the Jetpack modules, simply because I don’t need them. I don’t post LaTeX code, for example, so that feature is pointless for me. But I know what LaTeX code is and I turned it off intentionally. A user who turned off auto-activation at some point in the past, and then is told by somebody else to “paste this bit of magic code in to get a math equation on your blog” might be surprised and potentially frustrated when it doesn’t work. They may not realize that this “option” that they didn’t understand or care about from months or years ago is now impacting something else that they’re trying to do.

      If you’re going to auto-activate new functionality, then simply doing it and not having an easy-off-switch is indeed the right decision. You can certainly argue about whether auto-activating new functionality is reasonable or not, but the decision to not put in an option for it makes perfect sense from a user’s perspective. Don’t give the user options they don’t understand, need, or can make the wrong choice for without knowing it. Power users who want those options can add them via a different means.

  3. I never used Jetpack and i always wanted to try it, but after read this…, I’ll be brief, everything that a plugin makes without my permission is trash. The auto activation (new or old module, affecting or not to the front end) is the reason #1 to not use Jetpack.

    For example, what happens if the new module auto-activated by Jetpack increase the CPU usage?

  4. I so wish that Jetpack was a collection of separate plugins rather than bundled everything together. Other plugin developers with multiple plugins don’t combine them and that feels like the best practice.

    • In my mind, Jetpack is a single plugin with multiple “modules”, or put differently a plugin pack – a collection of a number of plugins all working together to achieve a similar goal (in this sense it’s to minimize the time it takes you to manage your site on a day-to-day basis). You have the ability to go in and de-activate what you do not want to use. I believe this is the future of plugin development. Some plugins do this with downloadable modules (edd/gravity forms add-ons). These just come pre-packaged with the ability to activate, instead of download, what you want to use.

      • I’ve read other comments that say what Jetpack does is the future of plugins. But, do you know of any that are actually doing the same thing as Jetpack? One of the points of discussion when it launched in 2011 was that other plugins were going to start doing the same thing. I don’t think that’s happened yet, at least I haven’t seen any.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: