Jetpack, I wish I could love you

Dear Jetpack: I really want to love you, but you make it so hard

When I first heard about Jetpack, I was excited about the potential for features to be shared with users. It seemed like a clever setup with its various modules in one plugin. But Jetpack just keeps managing to get under my skin. A little gripe here and a little gripe there typically isn’t enough to get me upset, but Jetpack consistently disappoints in a variety of ways.

Let me preface

I am using Jetpack on this site. I really love some of its features. My favorite is the new gallery carousel. You can see it in action below. I’m not trying to rail against all things Jetpack. I’m just trying to make some notes, and express some frustrations.

Jetpack is not completely free.

Sure, I don’t pay money for Jetpack. But Automattic gets to advertise paid products, like VaultPress, via Jetpack. Jetpack also requires me to have a account even if I don’t want to use any of the modules that actually require such a connection. There is inherent value to Automattic in that registration, and a slight loss of privacy for me. And privacy is valuable.

From what I can tell, only four modules need to function:
  • Stats
  • Comments
  • Subscriptions
  • shortlinks – and I’m not even sure this one requires it

Why do I have to have a .com account so that I can use a few modules like latest tweets, After the Deadline, shortcode embeds, or gallery carousels? That’s frustrating. I’d love to enable these modules for a lot of client sites, but it’s just rarely worth it when I have to create them a account, which they don’t need, won’t use, or even understand. Not to mention, it feels “icky”, for lack of a better word, that I have to connect to .com for features that shouldn’t require it.

edit: according to Matt on a Jetpack blog post, 10 modules connect to .com. See the links in the comment below.

Jetpack could get some major feel good points by letting me use it without a .com connection for all the things that don’t need a .com connection.

Some good plugins have been sent to the graveyard

You may tell me I’m being unreasonable for the connection to .com, and tell me that if I don’t want to connect, use something else. After all, there are plenty of alternatives! And you’d be right. There are alternatives, but some of the best plugins for these functions are the plugins that got gobbled up into the Jetpack version.

And when they got put into Jetpack, they stopped development on the non-Jetpack .org version. Here are some that have done so:

But these were all Automattic plugins, quit complaining

You’re right. Each plugin above has Automattic’s name on it. These are plugins that people liked and relied on. With Jetpack, each plugin has discontinued support on the non-Jetpack version (as far as I can tell – or they’ve said so themselves). To my knowledge, none of these require connection to in order to function, yet I must now have a .com account to use them. Sad.

To me, this goes against the very first statement in Jetpack’s launch post: has grown into one of the most amazing cloud architectures in the world. This has enabled blogs hosted here to have features unavailable on self-hosted WordPress installs.

Breaking WordPress UI best practice

People look up to Automattic and the work they do. I know I do. It makes me sad when I see them breaking the rules we so often try to encourage following in the .org world. The Jetpack UI is a prime example of this in action.
Jetpack needs to be brought down a notch Lead Developer Mark Jaquith created a plugin called Menu Humility to get Jetpack to chill out. Think about this, is Jetpack really more important than my posts tab? I think not.

Also, Jetpack likes to depart from traditional WordPress settings pages, and standard notifications UI. When you activate the plugin, you get a big cloudy box on the dashboard and plugins pages telling you to connect to You can disable it, but it deactivates the plugin. Compare that to the Gravity Forms nag to update with the traditional mild yellow warning box. Gravity Forms is much less obtrusive.

Once you go to the settings page, it presents itself in a completely custom manner, and does its best to make it hard to find where to deactivate modules. (hint: click “Learn More” and the “configure” button changes to “deactive”).

Here are some screenshots of these things in action:

Oh yeah, and most of this stuff auto-activates

Jetpack has a bad habit of assuming we want every new feature. Until they came out with the comments integration, they were auto-activating every new feature. Even features as big as the Grunion contact form integration.

I think it’s safe to assume most websites had a comment form solution figured out, but Jetpack figured they’d autoactivate it anyway. That enduces slightly more than mild frustration. I mean, they could have at least done a check with is_plugin_active() for say, Gravity Forms and Contact Form 7. It’s not like millions of people use those or anything.

In yet another defensive move against Automattic plugins, Mark Jaquith released Manual Control to prevent this assumptive behavior by Jetpack. Unfortunately, only a couple thousand inside-baseball WordPress fanatics are likely to know about that.

Mark Jaquith’s plugin banner for “Manual Control”

Hopefully, hopefully, Jetpack got the message on this behavior though; because to their credit, both Comments and Carousels didn’t come auto-activated. But I’m not sure if it’s because of community revolt or the revolt that would have happened if they hijacked every Jetpack users comment forms. Either way, thanks for not doing that on those add-ons, Jetpack. Let’s keep it that way.

Some “Woah” moments

Some aspects of Jetpack aren’t really related to “Grrr, this is evil”, but just unexpected behavior that bothered me a bit.

When I turned on Jetpack comments to try them, I was surprised that it replaced my entire comment form, and anything else that was hooking into comments. So I lost my buttons that allowed people to subscribe to comments and whatnot. Not that big of a deal, but kindof disappointing.

Jetpack also somehow connected to the wrong .com account, and apparently my stats were for my domain, but connected somehow to a domain I set up Jetpack on for a friend’s site. I didn’t know it until I was getting errors by would-be commenters, who couldn’t comment. When I reconnected under the proper .com account, I lost all my .com stats : ( Mega sad-face. Now my end-of-the-year email about how my blog did will be even more depressing. I’ve been told that this is not near as uncommon as you may think.

Oh, have you enabled Jetpack comments? Go to a post in incognito mode or while not logged in. Leave a test comment. It’s even better if you try it from a slow connection. When you submit, the entire page redirects to, and back again. That was pretty frightening to me when I first saw it. Who knows what a random commenter would think: probably that something wrong happened, before they click out of your site.

I had another client at work I was setting up a latest tweets widget for. This isn’t the hardest thing in the world, but I wanted to use a service I thought would stay up to date with Twitter’s inevitable api changes down the road. I chose Jetpack, only to realize I was in trouble. See, our dev sites are password protected. To use the tweets module, I had to connect to .com (see above for why that’s super annoying). Well, I couldn’t connect to .com because the site was password protected. So that means I can’t style this simple tweets widget! Grrrrrrrr. Perfect example of why I shouldn’t have to connect to .com for front-end facing stuff that doesn’t need it.

Is Jetpack getting a special privilege to be in the .org repository?

I am no legal or license expert, and I really hate getting in on such debates. However, just reading the plugin guidelines for, it seems Jetpack skirts awfully close to the limits on a number of things.

I don’t want to spend too much energy on this topic, as it’s not my primary point of contention with Jetpack. But I’d encourage you to read both the posts and comments on both WPCandy and WPMU regarding the business importance of Jetpack for Automattic.

I wonder if other plugins that require connections, like the WP App Store, and WooDojo, would be allowed in the repository. If I had to guess, they’ve probably tried. Are they really that different than Jetpack? if WP App Store only acts as a storefront and isn’t offering anything for free, then that’s flat out against the plugin guidelines, but WooDojo is basically the same as Jetpack. I wonder why it’s not in the plugin repository.

And I find this tweet interesting:

I should say I know zero inside information on these topics, but I think it’s worth bringing up.

I’m not just trying to bitch

Jetpack, I really want to love you. Really, I do. But these issues just add up. And they keep me from activating Jetpack on all of my client sites. I’m sure that’s not a big deal to you, since all the big hosts install it automatically. I’m only one person in about 2 million downloads.

But I look up to Automattic, and I really like everyone I’ve ever met that works there. I have an enormous appreciation for what they do for the WordPress project. This appreciation extends from the newest employees that have done great things for .org in the past, to Matt. I didn’t write this post to start a flame war, or incite controversy. I just want to publicly express my feelings about Jetpack – why it’s dissapointing right now, and let you know I think it could be great. But it’s not right now. Maybe a couple of people agree with me.

I expect a little better from you. I’m sorry if that comes off as harsh.

95 thoughts on “Dear Jetpack: I really want to love you, but you make it so hard

  1. I don’t think you could have said this any better. When I first installed it when Jetpack was brand new, I loved it, but over time it has grown farther and farther away from kind of things I expect Automattic.

    Like you, I was shocked when I first saw that the new comments module not only removed all normal comment-related hooks, but also redirected to When I saw that, I almost threw that module away immediately. I still use it, but only because I decided a lot of people might like the option to have the social login.

    I can understand why WPAppStore is not in the repo, but as far as I can tell, there is zero reason WooDojo shouldn’t be allowed, not when Jetpack is.

      1. No, you are not the only one – I think also and I hate the education from the team and this plugin is the best part, how not to make.

    1. How Jetpack Comments works, including the comment iframe and redirecting through, is a requirement of its design goals and constraints:

      * We wanted people to be able to authenticate with the most popular third-party services, especially Facebook and Twittter, but more down the line.
      * We didn’t want them to have to register as developers with them, or ones we add down the line, to have support third-party services. (If you think connecting/registering to one service is bad, imagine 3-5!)
      * If you logged in one place we wanted you to be logged in on every site on the internet that uses Jetpack Comments, to remove friction from the commenting experience.
      * We wanted it to be secure.
      * We wanted to provide the best commenting user experience, driven largely by tests we’ve done with hundreds of thousands of users (literally) on

      If someone likes Jetpack Comments it it’s because of one of those bullet points.

      In order not to have people have to register every single one of their domains as a new application with every third-party service (two today, more down the line), we needed everything to go through a single top-level domain. The one that makes the most sense was, because we had already registered it and it already had millions of users logged in already, including from many VIP sites. This way the apps we’ve registered can “work” on your domain, and though it’s through an iframe, that’s completely invisible to most users, they just see a nice-looking comment form on your site.

      We have to do this through an iframe rather than writing information directly to your site because otherwise your domain would have access to user’s information just when they visit, which would be a security problem. (Michael Adams gives a fascinating presentation on cross-domain cookie, Javascript, and iframe communication issues, I’ll see if I can find a video.)

      Like I said earlier the iframe should be transparent to your users, and the redirect should happen so quickly you don’t see it, but I’ll look into if there might be something slowing that down. (It shouldn’t be any slower than your old POST to wp-comments-post.php.)

      The design and functionality of the comment form is such that we have to replace it because there’s no way to predict the infinite variety of markup that may or may not be there. There are some built in options to accomodate light and dark themes.

      I’ve personally run into wanting to hook into that form (for a comment policy) and I’ll see if there’s a way to replicate some of the arguments that comment_form() supports to make the system more flexible.

      That said, I think it’s the most elegant hybrid between hosted systems that replace the entire comment section, like our own IntenseDebate, Livefyre, Disqus, and Echo, and a plain-jane comments section where you can control every line via PHP. It should also be noted that every comment comes back to your database, and you still have complete control over the markup and styling of the rest of the comment thread. I think we addressed the above points, while maintain the most flexibility we technically could.

      1. Everything about the iframe makes perfect sense, though I can tell you first hand that the redirect is definitely shown. I’ve seen the URL with almost every comment I’ve ever left through the plugin. I currently have it active on my site and I don’t think I’ve posted a comment without seeing it.

        I do really, really, really appreciate the fact that all comments get posted back to the site’s database. That is invaluable.

      2. I agree with Pippin completely. I’m sure y’all thought long and hard about how to handle comments, and am really glad they get to stay on my database. You brought up a lot of things I wouldn’t even begin to think about. But the redirect is definitely noticeable, and imo would be pretty surprising to an unsuspecting user. comments was a feature I most hoped would hit Jetpack, and I’m glad it did. But some of my early on issues kept me from being able to use it. I definitely agree that the cross-domain logged in status is nice, and UI of the comment form in general is great. I look forward to trying it again as it improves.

        Owning the data is by far the biggest plus though. That’s always been my biggest beef with other third party systems. I think Jetpack has great potential for a hybrid system.

    2. You don’t need a account to use the Carousel, Contact forms or Sharedaddy.

      I’ve written a post about this last week and also provided the downloads for the individual modules.

  2. How appropriate, given that earlier today I was complaining about some CSS being loaded from (SO not allowed) that was mucking up the dashboard. I’d seen some .org forum posts about it this past week, with understandable confusion because the users hadn’t updated anything on their respective installs, and then today saw even more broken-ness on one of the Make WP sites. The external loading appears to have been inadvertent and they’ve since fixed it, but I was not very pleased about that.

    1. I’ve had a post draft with a title “Oh, Jetpack” for a few months. I started actually writing it after I saw your tweet regarding the CSS stuff this morning. I didn’t include it in this post because I didn’t quite know the details, but thanks for chiming in here : )

    2. I found your tweet, but looking at my dashboard I don’t see the symptom you describe (messed up columns) or any CSS being directly loaded from Is it all fixed up as you said or are you still running into this? And what was loading from

      Regardless, if you come across a bug like that again as a core contributor and a VIP developer you (or anyone at 10up) don’t have to complain with ephemeral tweets, feel free to reach out directly and we’ll try to get it address as soon as possible. Just like with core, we can’t fix what we don’t know about. (And there will always be bugs, no matter how hard you try, what matters is how you respond to them.)

        1. It seemed like a big deal from your comment (“today saw even more broken-ness”) so don’t be shy about reaching out directly, even if there’s already a forum thread.

          1. Reading you @matt respond here made my day!

            Not a fair expectation, but I would have loved to read a comment from likes of Bill G., Steve G. or Marc Z. on such random reading (no offense to @brian). I came here by chance!

            I got carried away, but yes, I don’t see how making .com integration “per need basis” was un-intuitive.

            @brian you should check-out slim jetpack.

  3. A pay version would be great. I also feel this way about jet pack. Why not a free version, developer and enterprise!? Please!!!!

    1. There are no plans to do a paid (or enterprise) version, it would be weird to charge for what you can get for free on

  4. I wanted to try it, but I haven’t used Jetpack on any client sites mainly because of the .com account issue. I’ve heard of other people complaining about this, so you’re not alone. I didn’t even know about the other problems. Hopefully, they’ll rethink it and make it better down the road.

  5. Wow, I too really can’t imagine it said any better.

    Not using standard UI is utterly unacceptable… Auto-activating ANY of the modules is unacceptable… Removing hooks from comments that other plugins rely on, again, unacceptable…

    Authenticating needlessly to .com is super annoying and why I can’t use it on 90% of the sites I build for clients. I used to try to set clients up with their own .com account but it just utterly flummoxed them. The confusion between and self-hosted is bad enough without trying to explain clients that they need a .com account separate from their site. I recently had one client baffled why when they logged into .com they could not get to their site anymore and blamed me for it… I get that Automattic is 100% focused on blogging, I just wish that focus didn’t bleed quite so heavily over into .org.

    FWIW, I pushed HARD for the .com comments module and hence am beyond words with disappointment over it’s implementation. Hijacking everything is about as “un-wordpress” as they could have been. I’ve yet to be able to use it on ANY site.

    Jetpack had such awesome potential… but rather than being a shining example of doing thing right it keeps being an example of how NOT to do things.

    1. I think I addressed authentication and Jetpack Comments in other comments, so let me talk about the UI:

      The vast majority of Jetpack is useless (or broken) without a connection to, especially stats and subscriptions which are people’s #1 feature. We’ve been doing this connection thing for 4 years now, when it was overly hidden or constrained to a specific page people just didn’t notice it and it generated a huge support burden. You’re also loading a bunch of code you don’t need to, so if you’ve activated Jetpack you should either connect it right away, or deactivate it, there is no utility or feasible reason to keep it active but not connected for longer than a moment. I’d rather have it prominent and usable than hidden and causing frustration.

      The comparison to Gravity Forms is different because one shows an update, and the other shows a required connection. We actually don’t show update notifications, so are less aggressive than GF in that regard, we rely entirely on the built-in WordPress UI there and GF is breaking it.

      As for the clouds, perhaps it’s a matter of opinion, but I like them and think they’re pretty. It’s nice having a bit of extra design love (and color!) put into an otherwise extremely utilitarian space, and one of the goals with the Jetpack aesthetic is to make people happy. (To remind people there’s an outdoors… ;)) I hope that more care and polish into details like that will become standard UIs in the future.

      1. Gravity Forms was a lazy example on my part, as I needed to update it so it was there ready for my screenshot : )

        Perhaps more relevant is WP Remote.
        It’s still there, and like Jetpack, it’s pointless to have installed without it enabled, but it’s much more subtle, though more noticeable. Jetpack is *so* intrusive it just rubs me the wrong way. Other than that aspect of the cloud-look, I guess we can agree to disagree to the importance of the prettiness.

        A couple of UI components you didn’t address:

        • Is there any reason at all for the Jetpack admin menu to be higher than my posts tab? PS, this applies to VaultPress too.
        • Isn’t it pretty darn presumptious to enable the new features as they’re added? Even if you used the new tooltips to say “Hey, we got a couple new things – check them out!” it’d be much better than auto-activating
        1. The Jetpack menu item actually consolidates several things, including site stats (the number one most popular page in the admin on, above any core pages), Akismet configuration and stats (most popular plugin on, usually gets its own menu item under Dashboard), and the VaultPress status, stats, and configuration, which gets its own top-level menu item if Jetpack is not installed.

          The respective stats pages are quite popular, which is why we link to blog stats in the admin bar with the sparkline, and I feel it goes best with the “Dashboard” part of the WordPress menu rather than the content or settings area, or buried at the bottom.

          On activating modules, it’s a case-by-case decision. When you upgrade to a new version of Jetpack it says “you’re going to get XYZ when you update” and people expect that when they click the update button, not to have to go through a second activation step for the thing they just installed, especially if it’s more of an under-the-hood thing like additional widgets. (Presumably if someone didn’t want the new features, they wouldn’t be motivated to upgrade.)

          Where we choose to have something off by default for people upgrading is when it significantly modifies the front-end of the blog, or potentially conflicts with an existing plugin, as we did with Comments, Carousel, and should have done with Contact Form, the last three major things we’ve added to Jetpack.

          This next update we’re doing, however, is all UX, backend, and under the hood stuff, so will likely be on-by-default. It’s always a case-by-case decision based on what we think will benefit the most people, be the most intuitive, and feedback from our early testers.

          1. Presumably if someone didn’t want the new features, they wouldn’t be motivated to upgrade.

            They might want to upgrade to get new features or bug fixes for existing modules (that they use), for security updates, or to clear the plugin update nag (which is an inclination we should encourage).

  6. Great overview of what’s wrong with jetpack. On my site I use the comments and the latest tweets widget. Another small issue you haven’t mentioned is that Jetpack also suppresses the widget_title filter so I couldn’t modify the HTML for it.
    I do find it annoying that I can’t style the widgets on my local install, as Jetpack doesn’t seem to work on localhost, because of the connection to

  7. What‘s so cool about JetPack anyway? From what I read and see it‘s the same old trap disguised as the same simple choice users are supposed to make in the days of ad-powered web app budgets:
    a) donnot use me,
    or b) use me AND I get access to every darn piece of your data I am able to chew.
    Almost looks like Matt and Mark had a couple of beers and a good talk lately, doesn‘t it?

  8. Great post, really! Had some major issues with JetPack Contact form taking over “control”, thanks for the tip on the plugin to control just that 🙂

  9. I deactivated it after the Quantcast non-disclosure garbage a couple of years ago and never looked back. I shouldn’t ever be made to feel as though I’m compromising my ethics merely for some extra chrome or functionality on my blog.

    1. For the record, the description of Jetpack now mentions the Quantcast bit, and the stats stuff that uses that is much closer to launching.

      1. Matt:
        Thanks for the clarification. I fought that battle back when WP Stats was a separate package and it really left a bad taste in my mouth in re: federated services. I’ve had a rough go of it replacing the functionality, particularly in the stats and spam departments (because, try as they might, Google Analytics just doesn’t/can’t understand the innards of a WP blog the way WP itself does) but I’m to a point now where I think I’ve got things just about right.

        I think the iframe/CSS/redirect/Quantcast issues nicely encapsulate why I don’t use Jetpack (except on, where it’s non-optional): it makes my blog both beholden to an outside provider whose code can change without my knowledge and it can expose my end users to side effects, again, without their or my knowledge.

        1. That’s true — most people see it as a benefit that they constantly get new features and improvements from a service, but if you either aren’t interested in them or don’t want any third-party domain calls for whatever reason then Jetpack is not a good fit.

  10. I’ve never used the plugin myself, but this is a common support conversation I often have with theme buyers:

    “I can’t find the Screen Options tab you show in your video tutorial so I can’t follow your instructions.”

    “Do you happened to have a giant jet pack banner in the place where it should be?”

    “Oh ya, I suppose I do.”

    1. There was a bug in an older version where it partially covered up the screen options and help tabs, but that should be fixed now. The best advice, of course, is for them to activate it or turn it off.

  11. It’s so true. After the Deadline has been essential for me, but after the last update it had a huge blue banner saying that I would have to use it via JetPack from now on. Sadly, I’d rather give up on AtD than install JetPack – it’s just too bloated and heavy. And at least I can use the Chrome extension for AtD in it’s place.

  12. I see the same issues as you do, good post! I was working on a project when I noticed every single item you’ve touched on. Automattic should definitely address these things, and hopefully they will because of your post. Thanks for bringing attention to this in the way you’ve done: Elegantly, descriptive, respectful.

  13. I’ve always been baffled as to why anyone installed that plugin at all. I disliked it from the beginning.

    I have a fork of the Twickett Twitter widget plugin on Github that I’m intending to maintain.

    Contributors welcome 🙂 If someone is interested in contributing, then I might change the plugin name as I just arbitrarily stuck my own name on it due to complete lack of creativity 😉

    It’s essentially just the original plugin with a few bits of legacy code yanked out. I like it the way it was and don’t have any plans to add extra features to it. I might do a few performance enhancements as I have a vague recollection of there being something screwy with the way it handled caching last time I looked (I can’t remember what was wrong, but it was nothing major IIRC).

    1. Also, if someone is keen on taking it over entirely, I’m cool with that as well. I’m not overly keen on looking after this thing, I just didn’t want to let such a terrific little plugin die.

    2. Thanks, Ryan. I actually had a link to your fork in the post : ) took a lot of twitter searching to find that little guy, as I couldn’t remember where I saw it first!

      1. Oh, thanks 🙂 I didn’t notice that.

        I wish someone would make a fork of the Grunion contact form plugin. That’s a hell of a little plugin and I’d love to see it prosper as it’s own little entity rather than stuck inside the silly Jetpack.

    3. The code is all open source so you can do exactly this. I keep an eye on the forks, and the plugins like Mark’s which modify Jetpack behavior, and they really don’t have much adoption. What people told us, why we created Jetpack in the first place, is they had plugin fatigue — too many different plugins with different updates and varying compatibility, security, performance, and code quality. We made separate plugins (dozens) for half a decade, so I understand that point of view, but my mind was changed.

    4. The thing is, a single user is unlikely to actually need all the features that JetPack provides, so I don’t see how it’s a good idea to activate almost everything by default. For instance, how many people need WP LaTeX?

      Still, one of the biggest gripes I have with Jetpack is the inability to activate it on a local development install. The reason I usually want to do this is to test & style the twitter widget, which doesn’t (or at least shouldn’t) require a connection. I suggest adding a developer fallback for activating jetpack anyway for this purpose.

  14. Just wanted to add my voice to the consensus of agreement — you’re quite right that it’s not really on for Automattic to essentially abuse their position and have one set of rules for them and another set for everyone else.

    Would be good to hear if there’s any particular reason why Jetpack is allowed to break the rules (and if it’s not breaking the rules why other plugins with similar functionality aren’t permitted).

  15. As a jetpack user, I really love the stats side of things don’t really bother with the others in fairness apart from the comments as @pippin mentioned at the beginning it’s nice to have options for commentators.

    I fail to see why WooDojo is not added as a plugin in the repository as I have been playing with it of late and it’s pretty darn good I have to say, considering WP used there menu system in the end they might do well to include it.

    I can understand to a degree, that they offer paid for services via Jetpack such as VaultPress, after all they need to generate revenue for the betterment of WordPress, and we self installs maybe a hard nut to crack in terms of monetizing.

  16. Thanks for writing this. I’ve always hated the connection to .com for stats, but you bring up lots of other good points to think about. I delete it by default on my client sites (along with Akismet) and use other services when needed. I prefer a plugin:functionality model (or just write my own custom code) rather than one plugin to rule them all…

  17. I have to say that I completely agree with you. Requiring users to create a account for services like AtD and others is totally abusing the power. I understand that for Stats and other services that you mentioned the login is necessary. However, nagging everyone for a account just to use other basic features is one of the main reason why we do NOT install Jetpack on our client’s websites.

    I also wrote a post about whether this is the future of product placement model in the plugins directory. Surprising how WooDojo is not in the repository.

    1. Do you have a link to the post? I’d like to read it.

      As to WooDojo, my best guess is that it has to do with the PressTrends integration for tracking users/engagement. But I don’t really know if it’d be limited to that.

    2. Imho it does not make sense to sign up for for any reason, other than getting the service FREE. A pay service would make more sense here. That still of course does not excuse all the other points!!!

    3. Hopefully what we’re providing is not basic features, but features that provide a ton of value, certainly more than the 30 seconds it takes to create or link a account. If not, the plugin won’t be popular. I think we have some good stuff in there now, but it’s not a “killer plugin” yet, I think we need another year to complete the vision I had when we launched it.

      1. Matt, I never questioned the quality of plugins in JetPack. Perhaps, I should clarify what I meant by basic features because as I re-read my comment, it is probably not the best word choice.

        I was trying to refer to features that does not require authentication as “basic features”. I know that AtD is no basic feature. It is a totally bad a** plugin. But I liked the option to use it without being able to connect/create a account.

        I totally understand why we need to authenticate to use Stats, shortlink, Comments or Subscription. However, do we really NEED to login to use AtD? or the LaTeX module? Or the Grunion Contact Form? Or Shortcodes? or the other features that have no connection with the

        There are other plugins that does require authentication like MailChimp, some Google Analytics plugin, Akismet, the Aweber plugin etc. I don’t think people are complaining about that as much because:

        1. They do not aggressively take over the dashboard with the giant nag.
        2. Their is obvious need for the third-party API in order to make the plugin work.

        Why I think JetPack is setting the wrong example here for others is because now anyone can release a plugin as simple as Hello Dolly and require authentication (when it’s not needed at all). I’m not saying that people will download and use that plugin. Many users find JetPack plenty useful (I think the # of downloads speak for itself). All what I’m trying to say here is that it would be much better, in my opinion, if JetPack didn’t deactivate all modules.

        It should only deactivate the modules that would not work without connecting to Just my 2 cents.

        1. You should look again — both After The Deadline and Latex use remote APIs, I cover both in this comment thread on the main Jetpack blog:

          You’re correct that contact form, shortcodes, and (most) widgets don’t require authentication, but those features aren’t the main reason anyone downloads and uses Jetpack, they’re only 3 of the 14 modules we promote on the homepage. The majority of the services use and rely on remote APIs. (Or as we like to call it, awesome cloud power. :))

          1. Hey Matt,

            Thanks for clarifying. I was going based on the AtD version that I used in the past, and still have activated on the site. If I recall correctly, we didn’t need API for that.


            Now even that plugin is adding a nag for Jetpack in my plugins area. I already removed it from WPB and told the team to just download the browser extension.

            Carousel is yet another example. It adds some serious power to WP gallery. I absolutely love it. I am 100% sure that it does not require remote connection.

            I just wonder what’s the good reason behind locking widgets/modules that don’t need the connection? I looked through the Jetpack code with my little code knowledge… I saw few checks that make sure to deactivate those other modules.

            For someone like me (I might be in a minority here), I only need a certain features of Jetpack. Most that don’t need the awesome cloud power.

            – Stats: I use GA, so I don’t need that.
            – Subscription: I use MailChimp, so I don’t need that.
            – I use ( pro) so I don’t need that.
            – Comments: I use the built-in comments with Otto’s SFC / STC integration. So I don’t need JP comments.

            What I would love to have:

            – Carousel – Does not require connection.
            – AtD – didn’t use to require connection, so not sure why now?

            Most other features like sharing, embeds and others I have covered with other services or my own custom code.

            It was really silly that I had to fork the carousel to use it on WPBeginner. All that took was taking the carousel out of the modules folder and saving it as it’s own plugin.

            Now, it makes it a little bit more work for me to keep track of Jetpack updates and update accordingly if/when Jetpack updates the carousel. On the other hand, I have full control over the plugin. I have optimized it a little bit for performance. I only load the additional carousel scripts in the footer if the post has a gallery.

          2. If you read the code you’ll see that version uses a remote API as well. The English language model for AtD uses 4 gigabytes of memory, so not something that’s easy to run locally. By its terms of service, the API is only free for personal use — . You can run the service yourself under whatever terms you like.

            We ported Carousel and it’s pretty standalone in this iteration, but two major features in the pipeline for it are going to require a connection, so its standalone-ness is temporary. Remember, our goal is to create a parity experience with

            For most people, the “cost” of connecting a free account to their blog is more than worth the features they get in return, if it’s too much trouble for you then I wouldn’t recommend using Jetpack in the long-term.

  18. I was seriously considering this suite of plugins but those changes in the interface, custom configuration limits + all the privacy issues mentioned here are a mayor drawback.

    I understand their reasons to request an API connection but there are limits.

    Thanks for such valuable post.

    1. To address your three drawbacks:

      * Jetpack does not change the vast majority of the WordPress interface, once it’s activated it’s 2 menu items (Jetpack and Feedbacks) out of 13, and the Feedbacks one is optional. Posting, commenting, everything else works exactly the same and uses WP UI conventions, many of which we created, for widgets, post boxes, settings, et al. What people have raised issue with is the activation notice and the main plugin config and information page, both of which are colorful and designed using Jetpack’s visual language.

      * There are no custom configuration limits I’m aware of, besides what’s been noted in the thread vis a vis Jetpack Comments. Modules can be activated and deactivated, many have ample options, and of course you can dive right into the code and change what it’s doing line-by-line.

      * Everything that happens with Jetpack is covered by Automattic’s privacy policy which you can read in its entirety here. I believe it compares very favorably to most internet services, and is even better than most web hosts provide. (Yes, your site is hosted somewhere and their privacy policy applies to your account. Read it!)

  19. Sorry I’m a few days late to this post, I missed it when it came out.

    First I’d like to say I agree with you on several points:

    * Activating and deactivating modules is too hard right now.
    * There is no good workflow for clients.
    * People do get confused by having two logins, and local install.
    * The integration between the dashboard and user tools and Jetpack installs should be tighter.
    * We didn’t anticipate the contact form conflicts.
    * It is difficult to develop locally or behind password protection with Jetpack.

    First let me talk about those points, since we’re on the same page:

    The first and last points we hope to address with updates, as they’re pretty fixable. The contact form conflict we address with minor updates to 1.3 line as soon as we became aware of the problems.

    The login and identity issues are tougher, and I don’t know the answer and I think it won’t be easy, but I think we’ll be able to evolve something a lot more elegant there where there are both admin and user connections to, and options to log in with a identity that’s tied to a specific user (so novice users only have to keep track of one login), and better integration of Jetpack installs with the dashboard, for example allowing you to use Instapost, or any of the new APIs, to route posts to any Jetpack install.

    Thank you for raising those issues and I really hope we start to live up to your high expectations better with the updates coming down the line.

    A few other points in the post I think might be misconceptions or misdirected, I’ll try to address those above in replies to people who concurred with you, or as new comments after this one, so as not to mix too much up into one comment. (Subscribing… :))

    1. Wow, Matt – thank you for your incredibly thorough and thoughtful replies. I’m really flattered that you are willing to spend your time responding to this post!

      First off, I’m really glad we are on the same page on the issues you mention. Those are my biggest personal gripes as someone who creates websites for clients. It’s a very difficult workflow and confusing to explain the process to the client.

      I’ll respond to the other comments inline as you did.

      Thank you for raising those issues and I really hope we start to live up to your high expectations better with the updates coming down the line.

      Like I said in the post, I don’t hate Jetpack, and I’m hopeful for its future. I apologize for my high expectations : ) I definitely know that code is poetry and best when iterated on over time. I’d be embarrassed to show you my code from today much less that from just a few months ago!

      I really appreciate your comments, and maybe if I’m (really) lucky I’ll be able to buy you a beer in SF and listen to more about what you have in mind for Jetpack in the future : )

    2. By the way, a couple of your responses on the Jetpack ratings-request post early today had some really valuable information that I think would be worthwhile on the JetPack FAQ page.

      I had no idea Jetpack was talking to .com in 10 of the modules (I need to update that in my post).

      However, I do think you downplay it a bit to say the Jetpack modules are still available as .org plugins – considering those in my “graveyard” list in my post have all seemingly abandoned development outside of Jetpack.

      Either way, I thought people here may want to read those two comments.

  20. Obviously, I’m chiming in late to this [fantastic] post so there’s very little left that can be said but, for what it’s worth, the overall Jetpack interface is my biggest complaint (the promoted menu and the huge header) primarily because it’s so juxtaposed to the general interface and design principles generally practiced by Automattic.

    Other things, although a bit concerning, I see as the nature of software so I’m more forgiving – at least to a point.

    For example: the current behavior of Jetpack’s comment form is weak – it rips you out of the context of the site you’re on, it’s slow, and some people dislike the new UI.

    But is it a step closer in right direction? That is, is it helping to bring us closer to, say, accepting comments from multiple networks (as covered earlier in this thread) while also letting us keep our comments in our databases (unlike third-party plugins)? Absolutely.

    Tradeoffs are exactly that – they come at an expense. Maybe some of the features were one step forward and two steps back and maybe it shouldn’t have been released in the current state that it’s in. I don’t know. And this is but one feature of Jetpack – there are other aspects that you and others have hit on in the comments, too.

    Still, I see this is the nature of software. So many parts of Jetpack are what I consider to be ‘1.0’ products and most people know 1.0 is never the latest and greatest (just the latest :)). They are, however, perfect for getting something functioning into the wild in order to gather feedback to create a significantly better version (of which I believe Automattic generally does a killer job) – where the line should be drawn for 1.0 isn’t clear and is obviously a point of contention.

    The thing is, continuing to release a suite of 1.0’s makes for a weak product. Growing the Jetpack plugin without refining existing pieces is something that needs to stop.

    Anyway, and completely in a different direction, it’s refreshing to see a thread of comments where people are actually having a solid discussion (not some lame argument) about a product they care about. Too, I see people complaining about some WordPress theme developer’s mistake or complaining about the people talking about WordPress without bringing anything constructive to the table.

    Not so here and I dig that.

    1. You’re right that this conversation has been substantive, which is why I’ve been taking the time to address everything raised.

      On the version 1.0 “problem” — it is very true that I believe there are many iterations in the future for all of the features of Jetpack, however it should be noted that one of the huge advantages of Jetpack is taking the learning we have from hosting, supporting, and listening to 30M+ blogs on By that regard Jetpack is some of the best-tested code and interfaces in the entire repository.

      A good example is the recently-launched Carousel: it was actually our version two of something we originally launched about seven months ago in November and one of our teams spent over two months not only responding to user feedback on the existing functionality, but the significant overhead of turning it into something that runs in heterogenous hosting environments. For example on we can resize every image on the fly, there are hundreds of web servers able to create any size of any image we want, but not so on WordPress.

      The luxury of a hosted service, as a software developer, is that you can iterate many times a day, versus a few times a year like you do with shrink-wrap software, and you can get real data not just about what people say but what they really do, and that’s what makes great software.

      The commenting form on Jetpack Comments has had at least a dozen iterations as well. It’s just a long way of saying that just because is something is new to Jetpack doesn’t mean we just started working on it, and often what we’re porting over is a highly optimized and tested approach already. That’s the big idea, to bring the best bits of, the things people tell us they miss if they leave, and make them available to all WordPress users regardless of where they’re hosted.

  21. For the reasons above Jetpack Comments has to replace the entire comment form, so if you had custom checkboxes there they’ll be gone, but for subscriptions at least it should integrate well with the built-in Jetpack functions. We can’t guarantee compatibility with other plugins though, that’s why we have an integrated suite. The good news is you’re just a few clicks from turning it back off, since all the data is in your database there’s no downside to turning Jetpack Comments on and off again.

    For connecting the wrong .com account, your stats are not lost, they’re still there somewhere, you just need to contact support and they can fix them up. (You can tell them I sent you.)

    There are lots of plugins that require connections in the directory, from the obvious like Akismet, to the non-obvious like Google Analytics plugins, which you need a Google account for it to do anything useful, or an Adsense plugin, or the Facebook plugin, or the Disqus plugin… The guidelines in the plugin directory are (1) always evolving, (2) endorsed and enforced by the entire core team, not just me and (3) designed mainly to prevent bad licenses, spam, malware, and things designed to confuse or bait and switch users. (I personally think it’s more straightforward to be up front about requiring a user account, and set expectations correctly for users in the title and description, rather than springing it on someone later in the process like many iPhone apps do.)

  22. Ok just saying great post and amazing reply thread, one of the most informative and interesting i’ve read in quite a while, great job guys.

    Also Kudos to Matt for putting the time in to reply in such detail and for putting the work in on Jetpack (necessity for novice users to have a separate account aside I’m keen).

    When so many committed and knowledgeable peeps chip in the tone can feel a bit negative, but I think most if not all the points are mean’t constructively.

    I for one think although not perfect Jetpack does offer a nice dose of functionality that’s especially useful for migrating clients who aren’t ready for the full plugin ecosystem. Even for non novice users I think it’s got some great stuff- the social comments are fantastic and I can’t see how that could work without the integration, personally I think the hybrid model used is a good call.

    Anywhooo – great post, good job contributors and keep your Chin up Matt 😉

  23. Has there been any kind of official answer as to why Woo Dojo is not in the plugin repository?

    There’s been a lot of passive beating-around-the-bush here, and the real issue has not been addressed, maybe not even posed as a question. I’ll try to do that.

    Jetpack is an aggressive plugin that is “not really free,” as Brian originally noted. It is “not free” in a way that is not allowed for other plugins. It seems clear that Automattic is flexing muscle and gaining some monetizable access to users, their data, and potentially their ad space in a way no one else is allowed to do. Even if the big, loud, non-standard UI with its gotchas and aggressive, unfriendly default behaviors are exchanged for a less imposing and standard format down the road, is Jetpack the kind of thing the WP .org user and developer community really wants to see from Automattic? How does it affect that relationship? How do folks feel about a less clear boundary between WP .org and .com — while the boundary remains clear for all other such .coms? Is there a valid feeling of unfairness here, that sees Jetpack muddying the waters and compromising the ethic of “free” software, or at least the standard idea of what that means within the plugin repository?

    Yes, you can always not use Jetpack, or you can use (or create) alternatives, but this does not mean that anything Jetpack does is simply pointless or inappropriate to question because you’re not affected. You ARE affected.

    Jetpack affects everyone using WP whether they use it or not. Even if you think it’s OK for Automattic to absorb projects into a quasi-commercial plugin/service like Jetpack/, and even if you think it’s OK for this plugin/service to target the mass majority of users who want convenience more than freedom, who don’t understand or care about the hidden costs, you have to admit its very existence segments and alters the nature of the community and its relationship with Automattic. Users and sites that weren’t really a market for to monetize in the past now are.

    How do you feel about that?

    1. Has there been any kind of official answer as to why Woo Dojo is not in the plugin repository?

      I’d also be interested to read more details about this since it has been mentioned several times in this post/thread.

      p.s. I don’t use Jetpack or Woo Dojo, just interested in the future path of the community…

  24. I’ve noticed even when using the sharing module as a stand alone plugin that shortlinks don’t work which can cutoff titles so it takes more time to share as you have to manually replace the link and add the title again

    Is their a way to use your own shortening & tracking service hosted on your own server with this?

    Love the Carousel and even deactivated NGG to focus on using the native gallery and media functions.

    Contact forms also great but i read none of these will be updated on an individual basis which seems a bit strange.

    1. You’ll be wanting YOURLs and a custom short domain then. There’s an excellent WP plugin for it as well.

  25. The single biggest bug bare for me (correct me if I am wrong) is that I cannot style the Greeting Message for comments (Leave A Message). Can this be styled – in any way?

    Also agree that once you click Post Comment that big white page saying comment posting is a major distraction.

    1. I was just about to say something similar on the subject Matt, so it’s nice to see you’ve already beat me to it, and remember the discussion above. There’s going to be a good chance I’ll make use of the Jetpack Comments module; it looked good in some quick testing! 😀

  26. Thanks for the great article!

    I absolutely agree with many of your points. The only reason I keep using Jetpack is because 1) it offers a lot of functionality in one package 2) is up to date 3) offers the social log-in for comments.

    The stats look neat too – especially if Google Analytics is not necessary.

  27. I wish I’d read through this before installing JetPack on my blog. Now my server moves at a snail’s pace and the darn plug-in won’t deactivate no matter how many times I click on the deactivate link.

  28. I’m very late to this party but would like to add my comments for anyone still listening.

    My thoughts about Jetpack are relevant to my history with WordPress and blogging so let me give that background. I just launched a blog about developing WordPress plugins at and for 3+ years I’ve been a professional WordPress plugin developer building plugins for clients.

    On the other hand the last time I actively blogged was at my personal blog well over 5 years ago back when dasBlog was still popular. So my comments are based on my perspective as a plugin developer and a newly reborn blogger.

    I agree with many things said about JetPack above but there are two things not mentioned that I have issue with and one that was only mentioned once that I want to really emphasize because it’s the one of the two things that absolutely keep me from using JetPack, in increasing order of importance:

    1.) This is cosmetic, but that’s important. I think JetPack treads on one of the core philosophies of WordPress: "Decisions, not Options." JetPack overwhelms the user with too many modules on an ongoing basis. It needs to segment it’s main module page into three (3) pages; one for active modules, one for inactive modules and one for all modules. And it’s should present the active modules page by default, not the page with all of them, please.

    2.) You can’t active JetPack on a local install so you can’t reasonably use it when a professional site deployment workflow is used for client’s sites where site development happens on developer’s machines with testing happening behind a firewall prior to deployment to both staging then production site. Yes there is a workaround, you can activate on a machine on the web and then copy the database down but that doesn’t allow local debugging through activation and it’s also a big hassle if you have to activate many times to resolve a problem.

    3.) The local activation issue is a killer but even worse JetPack throws hundreds of warnings in PHP5 strict mode when using the PhpStorm debugger (see them at this Gist). This makes it completely impossible to use JetPack for anyone that depends on a debugger for professional development. And the sad this is that more than 99% of the warnings are for calling non-static methods with the static method call operator (::); actually they need to declare those methods as static. Doing that would resolve most of the warnings.

    So there are my list of issues with JetPack. I can’t even consider using it until issues #2 and #3 are resolved because all my development where I might use it requires local development and debugging. Besides, when I see a plugin with so many warning I wonder what other problems it may be hiding that have yet to be found.

    Here’s hoping Automattic hears this and addresses these issues.

  29. Hi Brian and friends here

    Thanks for all of this info.

    Will jetpak ever be like ‘1 click to activate only feature you want’ instead of ‘1 click to learn more and then 1 more click to deactivate the feature you don’t want ‘ ?

    I don’t mind clicking but hey, there are tons of modules in jetpack to not use. It’s so wrong, no matter what angle you are viewing from, that a plugin packed with tons of features and auto activates all upon install.

  30. Howdy I am so delighted I found your webpage, I really found you by error,
    while I was searching on Aol for something else, Anyhow I am here now and would just like to say kudos for
    a incredible post and a all round exciting blog (I also love the theme/design), I don’t have time to go through it all at the moment but I have book-marked
    it and also included your RSS feeds, so when I have time I will be back to read much more, Please do keep up the
    superb work.

  31. I actually like JetPack. I love the stats and not having to worry about it being updated/compatibility issues. I also like the non-standard interface (although all the required clicking is a bit excessive).

    I do agree with a lot of the comments here, though – especially that it shouldn’t auto-activate everything (I mean, Jimminy Cricket!).

    One additional gripe:
    I’d really like to know why the menu shows for non-admin users and why we can’t hide it?! Not nice.

Comments are closed.