8 Comments


  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!

    Reply

  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.

    Reply

    1. 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.

      Reply

  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?

    Reply

  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.

    Reply

    1. 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.

      Reply

      1. 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.

        Reply

Leave a Reply