Why I don’t have a problem with Jetpack

Want that magical tl;dr? Jetpack is for users, not developers.

I don’t know if I’m madly in love with Jetpack, or if I’m ever madly in love with a plugin, but with all the negative things I see from the WordPress development community on a regular basis, and some genuine interest in this topic, I figured I’d write about why I don’t have a problem with it. To be honest, I roll my eyes a little bit when I see yet another round of abuse from my fellow developers. I use it, my husband uses it, WordPress.com uses it, and so long as I remember to be a user, it’s great. My frustrations, like many of those of others, only come when I start approaching it like a developer, much like how I get frustrated with my MacBook Air only when I realize that 4GB of RAM wasn’t, in fact, enough at all and I can’t replace/upgrade it myself. If I really want to care about that above all else, then maybe I better not be an Apple user 🙂

Jetpack is not made for developers, and I don’t think it pretends to be. With that line of thinking, I believe it’s just a bit silly of us to get all affronted as developers so long as it’s secure and the codebase continues to mature, just like with any other project. It’s the kind of plugin that’s made for people who almost don’t know what a plugin even is, and have no concept of what others mean or disagree when we throw out our beloved “plugin territory” line when looking for something they want their site to do. Try reading some feature requests on core Trac sometime, and those come from people who managed to figure out to come to Trac! Anyway, as I always say, these users just want it to “clicky-clicky-worky”. I think Jetpack does just that the vast majority of the time, and technical annoyance points like some new modules auto-activating or having to connect through a WordPress.com account are a part of that successful behavior. We’re a vocal minority, you guys, and we should recognize that.

Most users, especially ones just getting started with the web, have a pretty standard set of things that they want their site to do, and it’s smart to put those common desires together in a one-stop-plugin. If Jetpack claims to be for everybody ever, then maybe-probably I’d have a problem with that. I’d also be surprised if a plugin started claiming anything at all 😀 I don’t think Jetpack exists to make your life as a developer easier, and while I’m sure/know that there are myriad ways in which it could be better for developers, I think it does need to be recognized that there is a focus on user-facing features and that time spent by Automatticians tends to go there. Maybe we can get in the spirit of open source and contribute back as developers when we find pain points (especially those of us who have to use it in replicating an environment), or maybe we can expect more for free, or maybe I don’t know what, really.

Getting my more technical complaints out of the way just so nobody feels as though I am criticizing them for being a critic (because I’m not – criticism is healthy, even when I personally might think the volume a little silly): I think some parts of the UI could be better, I’m not a big fan of the consolidated top-level menu because I think users think about and look for labeling suggestive of the features as opposed to Jetpack as a bundle, I hate the slippy-slidy-earth-moving-hidden-UI method of deactivating a module just like everybody else does, and no, local development is not always easy, although there is a way for modules that don’t rely on a connected account.

For the record, I deal with Jetpack on local and restricted staging development environments just about every day, as it’s a part of how we set up to do .com VIP development, and find that there are often equal annoyances like dummy Twitter accounts for testing things that we’ve hooked in to, say, shortlink generation, whether or not we use a .com/Jetpack feature to tweet that link in the end. Or, I mean, oAuth, or SOAP, or lots of other things, especially in PHP. There’s always something annoying or difficult in development, Jetpack or no, and to me one plugin doesn’t deserve an exaggerated share of complaints. Complaints, sure, but it seems pretty lopsided, at least in the public arena, and especially from those who aren’t really forced to deal with it as a part of their client development. Yes, I hate that we don’t have a perfect replicated environment to develop on, and abuse it soundly in our IRC channel, but I do the same for anything we can’t exactly replicate internally and stab at blindly.

There are also things like plugin conflicts, which happen to everybody. I don’t think anybody can claim to have never written a plugin without a mistake or possible conflict, even people who ostensibly deal with WordPress all day every day. I know I can’t, have no idea if I could even test for conflicts against all 22,942 plugins in the .org repo as of this writing (my fault or not), and it would be ugly for me to judge the people (yes, they are people, and as far as I’ve met, wonderful people) who work on Jetpack as a part of their job at Automattic. If we want to point the Automattic-should-know-and-do-better finger, all I can say is that I don’t believe much in statements like that – the only thing I believe in is getting better via hard work and owning up to mistakes, which I find the team (is it a team?) does when actually communicated with rather than reading negative comments second-hand like we “accidentally” dropped a note we were passing in grade school. Developers are always going to have opinions, and it’s not an easy task to ignore what you may actually completely agree with as a fellow developer in favor of your true or proclaimed audience, and I would rather respect that focus while encouraging forward motion. Basically, I don’t want to bash; I want to suggest something that might be better, because that’s how I’d like to be treated. I’m also prone to telling people how I feel as directly and exactly as I can, so I think it can certainly be said that I am projecting some of my own personal preferences and personality here. I mean, it’s my blog!

Let’s take the Publicize module as an example of one that is on by default. There are all kinds of things that I find myself wishing it would or wouldn’t do, but those things I wish are things I’m only aware of because I’m specifically internet-tech-oriented and with other non-Jetpack integrations going on, like IFTTT tasks set up that sometimes create conflicts or feedback loops and my own YOURLS domain. So, maybe Publicize isn’t the feature for me, or I need to take the time to dig into its hooks for my own site, or discover that it doesn’t have hooks I need and find the right person to nag about it if I want to commit to my complaint. Complaining that it exists and is turned on (with nothing connected) is sort of like complaining that OSX ships with a color picker that no longer gives out hex values, minus the earlier-feature-that-got-taken-away part. Yes, it’s lame if that’s what you need a color picker for, and complain away, but there are better and more appropriate tools out there if you really have that specific need and as a power user, I’m perfectly happy to use them instead because it’s just plain better for what I need. It’s easy enough to not open the application, or in the case of Jetpack, either not authenticate anything or turn off that module (slippy-slidy-earth-moving-hidden-UI notwithstanding).

So what does Publicize do for your clicky-clicky-worky user? The biggest benefit I see, besides the whole broadcasting thing, is that it removes the intermediary step of setting up oAuth applications. I’m a developer, and I find that setup stuff almost impossibly confusing, especially on Facebook with all those Open Graph actions and whatnot. Have you tried setting up the Facebook plugin? Does it do what you want even when you make it past those hurdles? It didn’t for me or, perhaps more likely, I missed a hurdle. (Otto, I miss Simple Facebook Connect, even though I understand.) When it comes to Twitter, maybe it’s not completely true just yet, but as their API becomes more and more locked down and difficult to access, somehow I get the feeling that authenticating through .com may just come in handy.

Jetpack commenting, which some may know as Highlander from .com development, did not come turned on by default, but got its own share of abuse for routing through a .com site. I have no idea if it still does it, and to be honest, I’m not sure it bothered me even conceptually. If you’re noticing things like a redirect, then it should probably also be pretty clear to you that something external is happening to make social media logins and email notifications work out of the box. Social media login integration is approximately negative 17% fun, and potentially voluminous email across an unknown and crazy wide assortment of hosting environments is perhaps even less fun. Again, I’m not coming down on anybody for being concerned about the external routing, because I understand, but I think this is a case where it’s also pretty easy to understand why it works that way and to use something else if it is a deal-breaker or otherwise particular concern of yours. If it doesn’t do that routing anymore (seems unlikely), or it’s less noticeable, then great! They iterated and made it better. How much more can you really ask for, especially as a hopefully-empathetic developer? 🙂

As I’m trying to come up with a conclusion to this rambling post, I find myself worried that vocal critics are going to feel as though I am turning around and criticizing them. I’m really not trying to, I promise. I’m a huge critic, both of the thing that I work on the most and of myself. After all, why would you commit to working on WordPress itself if you didn’t want it to be SO much better slash hate it just a bit? What would my everyday motivation be if I didn’t constantly think I could be and do better? In any case, I find all the different perspectives quite interesting, and as somebody who has no interest in creating the next Jetpack, have no real desire to be loudly judgmental, as I don’t envy the task. I just feel it’s important to consider perspective. In this case, it’s the perspective of the clicky-clicky-worky user that matters the most, and I think in that regard, the only problems to have with Jetpack are those of when a feature is actually broken or perhaps being impatient to see what it will do next.

Why I don’t have a problem with Jetpack

63 thoughts on “Why I don’t have a problem with Jetpack

  1. I respectfully disagree with all this approach. You’re not either a dev OR a user, you can be both. I don’t see a valid reason to neglect dev feedback just because the average Joe who’ll never read a source code is cluelessly happy with it. Making both population happy is feasible with zero comprise on quality or usability.


    1. I guess I opened myself up to “devs are users too” by not starting the post with a stab at a definition for the scope of this post. Then again, I think it’s pretty obvious that I’m both, and so of course others can be, too. I’m talking about the perspective of the complaints I see, and I disagree that dev feedback is actively neglected (looking for a reason for neglect paints a picture of it being active/purposeful, at least in my eyes). I also completely disagree that you can make everybody happy with zero compromise unless you never, ever ship. Iteration is more valuable than being perfect every single time, every single way. I see Jetpack getting better behind the scenes all the time, but there’s always something new to hate instead if you want to look for it.


    2. I totally agree. I think it’s forgotten that the developer frustration is usually because of equally frustrated users. I’ve complained about Jetpack interfering with one of my plugins – but behind that are a lot of my users who are contacting me because they can’t get it to work and wonder why. I’ve emailed one of the Jetpack developers (who suggested doing the same to another plugin developer) and received no response.

      In the next release of my plugin I’m going to have to code something specific to detect Jetpack and report any potential problems back to users.

      I am a user though – I have Jetpack installed and happily use a lot of its functionality (although I can’t get Photon to behave itself) – so I see it from all angles.


      1. I am in no way saying that Jetpack is perfect for users, or that non-devs are never frustrated with it, but I do believe in letting plugins grow and mature, just as I do with my own code. Believing something can be better != having a problem with it in its current state. As for the shortcode thing, yes, it’s a problem, but it’s not a problem unique to Jetpack. That’s a situation of volume/scale along with the way shortcodes work. Maybe the issue there isn’t this one plugin, but one of non-unique shortcodes as a general practice, or that a shortcode can be registered multiple times with no indication as to what the end result is, or something else. I’m sure accommodating Jetpack feels like a burn, and I guess you’re probably doing it because of the volume, but it should be recognized that if you’re trying to avoid conflict ever at all, you’d have to accommodate any plugin OR theme (including custom ones for both), because any could cause the same issues.

        I *do* have problems with shortcodes. 🙂


      2. Thanks for responding Helen.

        If you read my response to Matt you’ll see my “shortcode” issue is not just that anyone can use them – my plugin is as guilty as Jetpack in that respect (I don’t check for existing use) and I wouldn’t blame it for that. It’s more the fact that there is no fine control on Jetpack’s many, many functions and, in the case of the YouTube shortcode, the error reporting is poor so users have no idea what’s going on.

        However, to say an issue of Jetpacks is no different to that in any other, you may be missing a point. Jetpack is by Automattic / WordPress themselves. They are the owners and authors of WordPress. Through their own publicity, takes pride of place as a “Featured Plugin” on their plugin front page. They’ve taken a number of existing plugins, combined them and got rid of the originals – the only way to use one of them is to install the whole thing, much of which activates by default (including new features upon updates). I would say it’s not the same as “any other” plugin and should be setting it itself as an example of how others should be written – mass setting up of common shortcodes with no fine control of them, error messages embedded in the HTML source, etc, do not suggest it to me.

        Back to the shortcode subject – it is possible to tell if another function is using a shortcode so the next release of my plugin will check and report this (hopefully getting rid of the numerous queries I get from users trying to use my plugins and Jetpack at the same time and getting mightily confused).



      3. There is no error reporting with shortcodes. Seems like a problem fundamental to shortcodes that Jetpack has fallen prey to, just like everybody else. I don’t think they hide that the shortcodes are a part of the plugin, and so the conflict problem is just the same as it is for any two plugins that have functional overlap. It’s not an okay problem, but it’s not a special problem. Also, why a YouTube embed shortcode? What’s wrong with oEmbed, or the embed shortcode that’s built into core itself?

        Automattic is NOT the makers of WordPress or WordPress.org, which includes the Plugin repo page I assume you’re talking about. I am a guest committer on the core project, am in no way an Automattician, and take serious issue with that misconception and spread of such. They (as in Automattic, the product and service company) cannibalized some of their own existing single-feature open-source plugins, took some previously-in-house pieces of their hosted WordPress.com service, and put them all together as one open source project that is under continuous development. Any plugin developer can do that to their own plugins as they wish, and you are free to have an issue with that, just as I am free to have an issue with your inaccurate view of who Automattic is.

        I 100% understand (and have some of) the feeling that Jetpack should set a better example when it comes to things like UI and code and best practices because it is so high profile and I don’t believe end users are responsible for knowing the difference between Automattic/WordPress.com and the WordPress free open source software project. But it’s not a good thing to be an active developer who doesn’t know the difference between the two and spread misinformation, either.


      4. Ok,This was a civil conversation but I find your reply rude.

        I do understand the difference between Automattic and WordPress but, as you rightly point out, a lot of people don’t. You’ll note my only reference to Automattic was “Jetpack is by Automattic / WordPress”. Visit the Jetpack page on WordPress.org and it lists Automattic as the primary author – that’s what I was referring to.

        That last line of yours, in particular, is unnecessary – you’ve misinterpreted what I’ve said and made no attempt to check on this before pronouncing me as “spreading misinformation”.


      5. WordPress and Automattic/WordPress.com are not the same thing. You said:

        Jetpack is by Automattic / WordPress themselves. They are the owners and authors of WordPress.

        That is inaccurate, period.


      6. I’m not going to get into a petty argument over this. Automattic are the owners of WordPress.com so my comment was correct. You’re just being pedantic now – as I said before, it would really have made sense to check up on my meaning before berating me.


      7. You talk about the plugin front page. That lives on WordPress.org. Automattic doesn’t make WordPress.org. I think your meaning was pretty clear in context, but just like anybody else, I can be wrong, too. I still think it’s bad to spread misinformation, even if boils down to whether or not you remembered to specify that you’re talking about WordPress.com. I’m fine with having misinterpreted you, but I think perhaps it’s also okay for you to say that you were unclear.


      8. We’re going round in circles. I think I was clear, you don’t think I was. We’ll just have to agree to disagree 😉 However, as I said, in future it may be worth just clarifying before “having a go” at someone.


      9. I’m one of the Jetpack developers and I agree: Jetpack should be leading the pack with regard to coding standards and such. I’ll temper that with: we’re human, too, so there have been, are, and will be mistakes. I’m always available to talk about an issue (tim@automattic.com) and really want te see Jetpack, WordPress, and the community grow.

        David, Helen lays out the issues well with shortcodes. The issue that the Jetpack devs and I look at now is: do we change the shortcodes, thus breaking people’s sites, or continue with the known conflicts? Detecting a loaded shortcode isn’t always accurate, since plugin loading order may effect the results. Feel free to email me to discuss this more.

        It sounds to me like we should look at starting a conversation on Make WordPress about updating shortcode handling.


      10. Hi Tim,

        Again, there’s been some misinterpretation here. I’m not expecting Jetpack to detect another user of the shortcode and complain about it (Jetpack gets to it first, btw, so no other plugin would be assigned to the shortcode at this point) – that’s not the fault of Jetpack.

        My issue is the lack of some fine tuning of the modules and the poor messaging, which is what is confusing users of my plugin. What would be ideal is if, in the case of the shortcodes module, a user could switch individual shortcodes on and off.

        I’m not going to get into specifics here, I’ll email you as you suggest as I have a number of ideas that would be useful.


    3. Feedback, developer or user, isn’t ignored. We do our best to incorporate the feedback we get into each release we do. There may be requests that we can’t fulfill immediately due to current roadmaps or available resources, though we always note feedback down in tickets for later.

      Feel free to email me (tim@automattic.com) any time you’d like to talk.


  2. I see the criticism the same as you, and I usually ignore it. If for no other reason than I don’t use it. Other than Photon, there isn’t much in there that I have any use for, so it’s a non-issue for me as a user.

    But as a developer, I have to work with the users you mention. Their blissful ignorance becomes my problem when something doesn’t work as expected, or conflicts with something else installed or that I’ve built. So while Jetpack is maturing as a platform and popular amongst users, the issues you mentioned (the bad UI, auto-activate, etc) cause me problems, which due to the quirks of running it on local, are that much harder to fix.


    1. The user training and maintenance part is definitely a tough one. I actually have no problems with auto-activate, mostly because I anticipate it both in terms of usage and development as much as I can, but the UI stuff sticks for sure. I haven’t tried a whole lot to contribute in that area, though, so I’m loathe to complain at the moment 🙂 That said… when it comes to clients, I probably have a pretty different perspective and experience than most devs, and I do own up to that. My primary code focus is on making custom UIs for specialized workflows, so that means running custom Twitter integration (stuff like per-category per-account auto-tweeting) when it makes sense, ignoring their widgets, or any number of other things that don’t fit super well with Jetpack’s necessarily generalized approach. Really, my developer perspective here is largely one of “okay, guess we have to use it to replicate .com and make sure nothing is totally borked”, in which case I don’t have much choice.

      I’m not super convinced Jetpack is the right choice for a custom/managed non-.com site, even though I also can see that if Jetpack is supposed to be good for users, we should be able to push it to them more and not re-invent the wheels it does provide. Maybe that’s where we install Mark’s Manual Control plugin, because it’s more of a developer-controlled environment. Every situation is unique, even if we approach them with the same base set of tools. I mean, you’re right, users end up with conflicts when they get into updates and installing stuff themselves, but I think that happens whether or not Jetpack or difficulties with local dev are in the picture. And, for what it’s worth, I’ve actually not yet managed to create a conflict with Jetpack, even with the limited local abilities, but maybe I’m just not being adventurous enough. Issues I’ve seen are slightly-wrong or very-wrong things other plugins are doing that Jetpack just so happens to expose on a larger scale 🙂


  3. Two points I wanted to add:

    1. A lot of people don’t know that all Jetpack development happens in the open in the plugin directory, including unreleased and unannounced-otherwise features, and it’s all open to outside contributions. Just like with core, patches are welcome if there’s something that is particularly bugging you and is easy to fix.

    2. Besides the obvious point of making local dev easier, would be very open to suggestions on how to make Jetpack better for developers. Some of the more recent features, like Photon, are really designed to give theme and plugin devs a new set of tools they can do fun and exciting things with, and reasonably expect that a plurality of their users will have the Jetpack APIs available, so Jetpack-as-a-platform is definitely something that will get work in 2013.


    1. Hi Matt.

      From my own perspective my own issue is around the shortcodes module – many of the shortcode names being used are pretty obvious ones that other plugins will use. However, and this is certainly the case if you use the YouTube shortcode, errors are written as HTML comments. The average user isn’t going to know to look at their page source to know the cause of a problem. If the shortcode module is installed along with my plugin, which embeds YouTube videos, then Jetpack will take priority with the shortcode but it won’t be obvious to the user that this has happened and incorrectly assume that their video not then showing is because my plugin isn’t working. So, for my situation, some better error reporting would be useful – I always prefix my messages with the plugin name so that it’s absolutely clear what is reporting the problem.

      However, what I think is an issue for a lot of people is the automatic switching on of modules and the lack of fine control in some cases – maybe the shortcodes module could do with an ability to switch on/off individual shortcodes for instance.

      Running Jetpack on a live site and updating it can be problematic – with new functions often being switched on by default, and not yet configured. I really think that by default all modules should be switched off, or at least, an ability to activate a module but have a separate switch for making it “live” – allowing site owners to configure the module before then making it fully active.

      I’m happy to get involved as you suggest – who would I approach and how?



      1. So I’ve never caused a shortcode conflict, but as a shortcode fan, now that you’ve mentioned it, I totally see how problems could be caused.

        As Helen mentions, the problem seems to be that there is no real shortcode error checking functionality. But hey, that’s an easy problem to solve right? Let’s build a shortcode conflict checker.

        After reading this post, I figured I’d put something together. I’m not saying it is perfect or error-free, but hopefully it’s a place to start, it is in a public github so people can make changes, work on it themselves, include it elsewhere, etc…

        The idea of the plugin is to provide devs with a set of functions to allow them to check and properly deal with shortcodes and shortcodes that conflict with already existing shortcodes. So, we need it to:

        1. Check if a shortcode exists.
        2. If that shortcode already exists, provide an alternate shortcode name.
        3. Provide a way to tell the user what the shortcode name is, in case it is an alternate name.
        4. Ensure that the shortcode alternative name is site- or network-consistent always.

        So, this is rough, but I think this will do it – https://github.com/AramZS/shortcode-checker

        Lines 129 through 172 are an example of how to use the plugin’s functions in your own plugins or themes.

        David, think this helps?


      2. Thanks Aram.

        Looking at your code I can see you’ve done what I was intending to. I had a look through Core code a few weeks ago and worked out how to see what functions were assigned to a shortcode. The only question is, if this check is performed by my plugin and Jetpack takes control of the shortcode afterwards, would it be detected? I haven’t yet worked out why but Jetpack always seems to take the shortcode whether its activated first or last.



      3. Hey David,

        So unless Jetpack does a similar check for shortcodes a conflict will be created if they add a shortcode that already exists elsewhere. The proper solution would (I suspect) be to add a similar set of functions to the Core and have Jetpack use them along with everyone else. Then Jetpack would do the same. Perhaps it would be worthwhile for me (or anyone) to propose them as additions to the Core (and then Jetpack) myself. Not sure if something similar or better exists out there.

        But failing that, I suspect Jetpack just sets itself to init before any other plugins, which is why its shortcodes override anyone else’s. There’s no solution to that outside of altering Jetpack’s code. But, if the following occurs:

        You create a plugin or theme that uses a shortcode, it is not in conflict.
        Jetpack adds a conflicting and overriding shortcode.

        Your plugin or theme can be deactivated and reactivated, properly create an alternate shortcode to prevent conflict, and inform the user of the new shortcode. Of course, this won’t solve the problem of existing uses of the shortcode, but perhaps we could write a regex solution to solve the problem, auto-replacing uses of the code previous in such a case as above, triggered by the user.

        Now, this is really only a half-solution until Jetpack gains something to make it conflict-free. Until Core and Jetpack are altered the checker is the most adequate stopgap I can think of right now.

        The only other thing I can think of is trigger the function to run on every plugin activation (including upgrades) to seek un-safe conflicts and inform the user of shortcode changes. I’ll have to do a bit more research to figure out how that could be done.

        Really, the best solution would be for the Core shortcode code to check every item added to the array for a conflict and do something useful in reaction to finding any conflict.

        As a thought: in wp-includes/shortcodes.php, line 97, we could add the sc_set_best_shortcode function call and send an alert back to the user, if triggered, saying something like “Plugin X wants to use shortcode Y already in use, so the shortcode has been changed to Z.”


      4. Aram,

        Those were my thoughts too (I had a good long think about this problem on the drive home!). Additionally, some plugins may not create their shortcodes in administration (because they’re not needed there), which is really the only place you can ideally report any problems.

        However, I did have one thought – why not make better use of the meta at the top of the main plugin file? So, at the top of my-plugin.php you would put the author name, version, etc. How about a new tag where developers can specify the shortcodes that they use? Core could be changed to read this and report on any newly activated plugin that will conflict with another. It relies on the relevant plugin developers adding this, but a bit of meta is certainly a lot easier than performing shortcode usage checks. It will also work within administration too.



      5. I think that’s a good idea, but if we’re trying to fix this problem, better to do it in a way that insures backwards compatibility and will include plugins that may be actively used, but not actively maintained, of which there are many.

        I think we can suggest implementation of your idea as well, but that requires compliance by every plugin developer to use a shortcode. Better to just have WordPress Core code enact the solution regardless of the plugin or theme causing the conflict IMO.


    2. Regarding point #2, that all sounds really nice, but my main concern is that you can’t rely on Photon unless your theme is hosted on WordPress.com, where the user will ALWAYS have Jetpack installed. Otherwise, you have to make Photon support an enhancement to your theme or plugin and add some complexity to your code to integrate with it. As a theme/plugin developer, the fewer third-party dependencies and connections I have, the less support and customer confusion I have to worry about.


      1. Chris, Photon should work out-of-the-box on a wide variety of themes, regardless of their existence on WordPress.com, and I have personally used it on blogs with themes which have never been on WordPress.com and whose development predate Photon.

        There is an optional API which can be implemented in the theme, but it’s not a requirement: http://jetpack.me/support/photon/


      2. James, my point is that you can’t use it standalone. In other words, you have to have Jetpack enabled in order to use it:

        “Photon is only allowed to be used by sites hosted on WordPress.com, or on Jetpack-connected WordPress sites. If you move to another platform, or disconnect Jetpack from your site, please also switch to another magic image service.”

        Which is totally fine, since it’s their server processing your requests. But how/why would you rely on a service that isn’t guaranteed to be available for all users? It doesn’t make much sense to me.


      3. Chris, I think I see your point. You mean why add the Photon API to a theme if you can’t guarantee that all your users will use Jetpack? As someone who has dabbled in themes, I’d say that it’s very easy to implement the API and a nice option to offer a growing a user-base, but it’s not a requirement.

        Photon works with images inserted into posts and pages out-of-the-box. The API only helps you to add some HiDPI goodness the theme’s resource images for Jetpack users. It doesn’t affect non-Jetpack users.


      4. I’d like to think that any theme developer would check that functions are active, in which case you could add Photon functionality for those who do have Jetpack but allow it to gracefully “fallback” otherwise. Building this in to a theme, considering the large user base that Jetpack has, sounds like a good idea.


  4. I have found the issue with Jetpack and it problemattic Sharing tool… How is it automatically added to each post and how you can’t added it to a theme with a template tag so you the developer can place it where you see it best in your design were huge issues with me. I kinda like how Yoast handles his breadcrumbs add-on in his SEO plugin he gives you a template tag that you implement. He didn’t say “I think that my breadcrumbs should go here and I know best.”

    I also though that sheer amount of time it took just to get the pintrest share button into the sharing platform was a huge let down in both support and communication. It was always… It’s coming… and six months later we were still waiting for it. http://wordpress.org/support/topic/plugin-jetpack-by-wordpresscom-pinterest-button?replies=16

    If you were to make a plugin more friendly to developers wouldn’t that attract more users? I know that has certainly been the case with Gravity Forms and WP-Touch… I have clients who have loved these plugins and have done much more with there site because of these awesome tools.

    Truth is I really want to use and recommend Jetpack. But the track record with me and it hasn’t been a good one and I know I am not the only one with that sentiment or feeling. Doesn’t mean that can’t be changed in the future.

    My two cents


    1. Robert, I like the template tag suggestion for the sharing buttons.

      As to the Pinterest button issue: we do have planned roadmaps for features going into Jetpack. We also have a set number of resources to work on those roadmaps and other features. This is similar to how core WordPress operates. With Pinterest, we added it as soon as our roadmap and resources aligned and allowed us to do so.

      I could have communicated better in the thread you link, yes, and I apologize for that. At no point did we actively ignore users requesting the feature.

      As I’ve told others in my responses here, feel free to email me directly if you’d like to talk further. I’d really enjoy talking with you about this and seeing if we can get Jetpack in your arsenal of WordPress plugins.


  5. You haven’t met me, but I work on Jetpack, and I can confirm that I am also a wonderful person. Also, great post. It enunciates my feelings about Jetpack in a way that I have been unable to do.

    For every “jetpack sucks lol” tweet out there, there’s a user in the forums reporting a real bug and helping us fix it, which I find really inspiring. (Not that all of the criticism is trivial or transient.) As long as the end-users are willing to wade into bug-reporting territory instead of just uninstalling the plugin, I feel ok.


  6. […] I don't know if I'm madly in love with Jetpack, or if I'm ever madly in love with a plugin, but with all the negative things I see from the WordPress development community on a regular basis, and some genuine interest in this … WordPress Plugin 2013 Why I don't have a problem with Jetpack « Helen on WordPress WordPress Plugin 2013 I don't know if I'm madly in love with Jetpack, or if I'm ever madly in love with a plugin , but with all the negative things I see from the WordPress development community on a regular basis, and some genuine interest in this … WordPress Plugin 2013 Why I don't have a problem with Jetpack « Helen on WordPress […]


  7. bradyvercher says:

    I feel like I should leave a comment explaining my frustration since I’ve made a couple of comments on Twitter about Jetpack, although they were pretty tame.

    Jetpack is a popular plugin (3+ million downloads) with a relatively massive codebase and a bunch of disparate modules, so it’s only natural that the number of complaints it receives appears to be extraordinary in comparison. There’s nothing wrong with that, it’s just a byproduct of the approach. Personally, I’m not a fan of the concept, but don’t have a problem with it if that’s the route they want to take. As has been mentioned, devs can be users and most of my frustration actually comes from a user perspective.

    The deactivation rigamaroo isn’t good usability for anyone.
    Jetpack has discarded a few comments I’ve left on blogs. Not sure if this is due to a short nonce expiration or what, but it doesn’t provide a notice and redirects after submission, so I can’t use my back button to see if it was cached by the browser.
    The notification emails for follow ups can be confusing and don’t always appear to work correctly.

    To be honest, I haven’t actually needed to use it in my client work much, so I’m not familiar with the code. I did help someone debug why standard oEmbed filters for YouTube videos weren’t working when Jetpack was enabled, however, and it appears to completely bypass the oEmbed functionality built in to core and generates the embed code itself, so the standard filters don’t even work.

    I can completely identify with the developers, the challenges they face, and assume they’re all great people, but I don’t think that should be used to marginalize the issues with Jetpack. I do wish them luck, though, and I’d love to be able to recommend it to my clients because some of the features are nice, but having run across these issues in my limited experience with it and seeing others with similar experiences makes me extremely hesitant.


    1. I agree, the deactivation UI needs work. We’re going to be looking at this.

      On Jetpack discarding comments: could you email me some details on this issue? (tim@automattic.com) I’ve run across issues with other plugins and some web server set ups that don’t like the iFrame and third party stuff we do, though most of it is able to be worked around.

      Please don’t be hesitant. If you use Jetpack and run across an issue, report it to us or email me directly. One thing I recommend, and this isn’t specific to reporting Jetpack bugs, but any bug to any company/product, is to be thorough in your bug report. Provide a detailed bug report, exact steps that you used to make the bug happen, your server set up, etc. The more details, the better. A report of “this is broke” doesn’t help as much as “do this and that to produce this wrong output.”


  8. Well said Helen. I am a developer myself and I enjoy JetPack. I use the features that fit for my blogs, easy as that. If something doesn’t work, I turn it off and post the error in the forums. Usually it gets fixed in the next release 🙂



  9. Helen, Simple Facebook Connect is still there and it still works. I still use it too.

    When the official Facebook plugin reaches feature-parity, then I might kill it off. But they’re not there yet. They are getting there quite rapidly though, and I think that them having to dogfood their own APIs and Application Setups and such are causing them to improve that process quite a bit, actually.


    1. BTW, my problem with Publicize is actually that “it removes the intermediary step of setting up oAuth applications” without properly explaining how much of a massive hit you take to your views on Facebook because of that. There is a rather large penalty for not having/using your own application on FB, and piggybacking onto the WordPress.com one, while perfectly fine and easy from a user-standpoint, is completely insane from the standpoint of wanting people on Facebook to actually want to see your posts. Yes, this is a problem with Facebook and their systems. No, they probably will not “fix it” anytime soon, because it’s that way by design.


      1. That’s a good point, didn’t think about that.

        What irritates me is after the latest round of JP updates all of the sudden half my clients have double opengraph tags and Facebook does not approve. Then I had to go digging to figure out what damn module(s) are adding that automatically. Lame.


  10. The idea that addressing developers needs is not addressing users needs is a false dichotomy that could have negative unintended consequences. Empowering developers enables users to have fewer bugs and more and better features. It’s very short-sighted to position developer concerns as not a concern for users; if people who don’t understand this take up as a rallying cry then things will get worse for users over time, not better. It’s a bit like saying that the people in a city don’t need to be concerned about funding issues that affect the city’s water supply. Ultimately it will be the people drinking the water, not the people who make sure it’s available so best to empower the latter to benefit the former.

    My #1 issue as a developer with JetPack is the fact it doesn’t offer a local development mode. I can’t fix bugs and I can’t add features without a local development mode. If I am working with someone’s site I need to be able to install the site locally and run it through a debugger. Anything else is just a time waste for me. It’s especially problematic when users have issues with my others plugins and I need to install JetPack locally to see if it is causing trouble but it’s very difficult to do that. And this affects users.

    My other developer issue is all the PHP5 strict warnings it throws so it makes it hard to notice when an important notice is throw (I see these within the PhpStorm debugger.) And the fact it’s easy to fix these tells me that certain aspects of quality control on JetPack are lacking. BTW I have no issue with the techniques used to simplify oAuth, or at least none I’ve discovered, it’s the other things I mentioned.

    That said, I just start blogging after a several year hiatus and I very recently tweeted about JetPack and commented on a blog post about JetPack from last year (so I wonder if I triggered your post?) As a developer I haven’t needed JetPack but as a user I have, and the issues I found with it as a user keeps me from using it. As a user I wanted more control over what features it adds to my site, I want it to feel less intrusive in the admin console.

    And since I won’t be using it I’ll also not be going doing anything to improve it simply because “what’s out of sight is out of mind.”


    1. The perception that I don’t care about developer-facing things just because it more-or-less works for users is a false one that is insanely tiring. I just don’t have some fundamental problem with its existence, and as a developer am willing to give Jetpack a chance to grow while continuing to avoid voluntarily using it in a way that needs development for client work until it reaches a certain point. Feedback is essential to the growth and success of any plugin, and being written by Automattic doesn’t intrinsically make it any different from any other plugin, at least in my eyes. I’ve given my developer-facing feedback to the people who are involved with Jetpack rather than just complaining about it at large, again just as I would with any other plugin. I hope it’s useful feedback, and that they have the resources to do something about it. Again, just like any other plugin. I don’t generally assign Automattic a higher value or some sort of special status, I guess is what I’m saying, and no, I wouldn’t voluntarily develop on Jetpack right now or recommend that it be used in situations that require such.

      My #1 issue as a developer with JetPack is the fact it doesn’t offer a local development mode.

      I’m guessing you missed this link: http://vip.wordpress.com/documentation/development-environment/#jetpack. It is not complete by any means, but it at least allows you to use the features that do not absolutely rely on the connection to .com. Given the number of us who have to use it to replicate the .com environment when developing for VIP clients, they definitely do care about getting it working better locally. It was a fairly recent event that Jetpack arrived at a point where it replicated enough .com features for us to use it for development, and while I am also frustrated, I imagine (and have heard) it’s just as much a priority for them to get it working locally/without connection, if only so the VIP team can stop reviewing and pushing commits from various VIP developers that deal with .com features we couldn’t account for in our development environments. I’m sure that isn’t their only motivation, so don’t be tempted to read it that way, but it doesn’t hurt to push on one that I can already think of. It’s also better than it was, which isn’t to say that that’s good enough, but I like to focus on what’s working and encourage more of it rather than contribute to stubbing out any forward momentum.

      so I wonder if I triggered your post?

      No. I guess this could be interpreted as sounding mean, even though it’s not meant to, but the only things I’ve read from you are on Trac. I’m not much of a comment subscriber otherwise, so I guess I missed whatever it is you’re referring to from elsewhere. I can only hope that you sent the contents of your comments to Jetpack developers, especially if it’s a bug or PHP messiness. Tim, one of the devs, very kindly left his own email address above in the comments for direct contact.


      1. The perception that I don’t care about developer-facing things just because it more-or-less works for users is a false one that is insanely tiring.

        This is the first time we’ve interacted and the first time I’ve really considered your position on an issue I have had to deal with. So if others have said similar things, I’m sorry but like I said it’s the first time I’ve interacted with you.

        Still that response misrepresents the point I was trying to make. I was responding to the following comment, pure and simple. Nothing more needs to be read into what I wrote, and if you re-read what I wrote you’ll see I was very careful not to target you personally:

        Jetpack is not made for developers, and I don’t think it pretends to be.

        My comments targeted the meme that worrying about developers is different from worrying about end users and I think that if too many people think that way it causes unintended negative consequences. One simple example is the Web API; I can’t tell you how many business people I’ve heard say that web APIs are not important for end-users but without them developers can’t provide end-users with the explosion of new integration functionality being made available on the web.

        So as a courtesy I would ask please to appreciate how I positioned my comments and don’t take my comments as personal, please.

        . I don’t generally assign Automattic a higher value or some sort of special status

        I didn’t address this before but will since you brought it up again I will. I appreciate and acknowledge your opinion however others here made comments that mirror my opinion: JetPack is special because 1.) It’s the top featured plugin on WordPress.org, 2.) it’s positioned as the one plugin you should start with because it addresses so many needs, and 3.) it is provided by the company seen as the shepherd of the WordPress community irregardless of the actual ownership, management structure etc. between Automattic and WordPress.org I don’t begrudge any of that but I do think that qualifies JetPack as “special.”

        No. I guess this could be interpreted as sounding mean…

        Not at all, and thanks for acknowledging. I’m quite happy to not be the trigger of anyone’s rant in the blogosphere or elsewhere. 🙂

        And I hear you about local mode. Here’s hoping they team makes it a priority so that developers in the community can more easily help make JetPack better for the end-user.


      2. Well, I guess it’s not really personal, I’m just using “I” in the context of this being a single blog post by me. Don’t worry, I don’t take much of anything personally, especially on the internet 🙂

        The feeling I’m getting at large, not necessarily specifically from you, is that accepting something as not-developer-oriented in terms of its background motivators and goals implies a belief that developers shouldn’t be cared about, which just isn’t true of me, and really shouldn’t be true of anybody, including Jetpack’s developers. I just wonder if perhaps as developers we should actually be better attuned to the issues Jetpack faces and focus on betterment rather than abuse, even as we are extra-frustrated by these issues. As hindsight almost always tells me, I could probably have written a much shorter post!

        I agree that Jetpack as a plugin is special in its prominence and adoption, and it would be completely hypocritical of me to say otherwise when I’ve written a whole post about it. In that way, though, then we should be extra motivated to encourage it to be better and provide feedback in a direct manner, because developer complaints on Twitter or blogs or comments generally don’t do a whole lot about actual user adoption. I mean, I’m sure we could (but let’s not) name plenty of very popular plugins that are horrifying to developers, and we all know it, but continue to be adored by non-dev-type users who would happily upgrade to a better version of that plugin, but are unlikely to jump to another one entirely. When it comes to how I view the author of a plugin, then I guess that is a personal thing. I definitely understand that outside perception about something like Automattic is stronger and more important than what I, as an individual person who willfully refuses to worry about “the system” as much as possible in favor of just getting things done, think or perceive.


      3. The feeling I’m getting at large, not necessarily specifically from you, is that accepting something as not-developer-oriented in terms of its background motivators and goals implies a belief that developers shouldn’t be cared about, which just isn’t true of me, and really shouldn’t be true of anybody, including Jetpack’s developers.

        Truth be told I think I reacted to your wording because of the many times I’ve been told by software product managers that “Our users are not asking for an API.” Users wouldn’t ask for an API because they are not developers, but developer who get an API can create things for users that don’t require the primary vendor to make it a priority. Imagine the iPhone without Apps. If Apple had said “Our users are not asking for an API” then the iPhone would be at least 100 times less successful.

        So I’m actually not worried about you or JetPack’s developers thinking that developers are not be worried about. I’m much more concerned when I see blog posts that give the casual reader justifcation to consider their user’s needs as disconnected from their potential developer needs. I’ve been fighting this battle with too many people for too many years.

        As hindsight almost always tells me, I could probably have written a much shorter post!

        Yes, I know the feeling. On my blog I consciously follow the advice given in my high school reader “The Elements of Style” where the author’s father suggested he “Cut in half. Now cut in half again!” Of course I don’t always work so hard when I’m commenting. 🙂

        perhaps as developers we should actually be better attuned to the issues Jetpack faces and focus on betterment rather than abuse, even as we are extra-frustrated by these issues. …
        then we should be extra motivated to encourage it to be better and provide feedback in a direct manner, because developer complaints on Twitter or blogs or comments generally don’t do a whole lot about actual user adoption.

        WordPress as a blogging platform encourages the people to write to have their opinions heard and I would say Twitter is similar. So to take issue with people sharing their opinions regarding a WordPress plugin seems ironic to me… 🙂

        That said, it’s never very clear to me how to encourage productive change with Automattic. I constantly get the feeling there are “in people” and there are “out people” where the former wield high influence and the contributions of the latter are shunned. At this point I’m learned-helpless about how to contribute to core or Automattic plugins. Maybe you can suggest approaches that are not clear to me nor to others whom I’ve discussed this concern with in the past


      4. I don’t have any issues with people expressing their opinions beyond hoping that they give feedback in a direct manner, I guess behind the scenes, in addition to at-large broadcasting 🙂 It’s how I operate, and keep hoping to be treated the same, even though I rarely am.

        I guess I don’t worry about encouraging change with Automattic as a whole, because it’s a company I’m not involved with and one with its own motivations and goals that are, in my view, unrelated to the open source project, so I refuse to change anything I’m doing to accommodate 🙂 Plus that’s an awfully large group of people, especially now. For me it’s a continuation of giving direct feedback – if I give it to the wrong person, I’m usually sent to the right one or ones (not just Automattic – anywhere). Then I can focus on giving feedback or interacting with somebody who is actually hands-on on a given project. 10up only has something like 1/8 the number of people Automattic has, and it’s already impossible to keep track of what everybody is doing or who is on what project, and I was the first full-time employee and am in a senior role, so I’ve been there through it all and specifically keep a higher level view of people and projects. So, I can only imagine that it’s even more difficult for them, especially with people who are just coming in or switching onto a project. I am neither judging right nor wrong, because I’m just not built that way – I just think about what is or isn’t, and to me, the reality is that railing at a company is probably not going to do a whole lot of good, but reaching out to people seems to be something that works.

        Basically, I see it as a game of individuals, not a company/body as a whole. The same goes for core, and actually even more so because of the whole open source community thing – there’s no “them”; there’s only “us”. Whether or not that feels true all the time is irrelevant – so long as I keep that attitude internally and give it back in my own interactions, I find that things keep moving forward and I don’t get distracted/bogged down in petty (or not-so-petty) disagreements. Maybe it doesn’t move forward at the pace that I want all the time, and I get plenty of ugly behavior tossed my way, but I tend not to worry too much. I also find that interactions are much more valuable and productive when conducted at the individual level, as in understanding where an individual might be coming from, what other pressures that individual might have upon them, what they might or might not mean (especially when reading text on the internet – I prefer not to read any sort of intent or emotion unless I have actually met the person, and even then I might not), if they can actually do anything about it, etc. That is, individual not meaning personal (really fine pedantic line that I’m not trying to draw), so no point in taking something as an affront to you specifically, or starting anything in a defensive manner because you anticipate blowback, etc. Being polite and sticking to just-the-facts goes a long way. I get told I sound naïve or overly-optimistic when I say stuff like this, so I’ll understand if you think similarly, even though I know that I’m not. I’ve just found that a lot more energy is spent being negative once you factor in consequences and further interactions, so I look for what works rather than focusing on what doesn’t.


    2. Mike, if you’ve seen issues like this, I’d appreciate it if you could send me details. The PHP5 strict warnings won’t be seen by non-developers (production environments are typically set up to only log these, at the most). This isn’t an excuse; just a note that it isn’t something most users will see, so not something that most users would report to us.

      To the local dev environment: we’ve got some tools to do this now and we are working on integrating them into the Jetpack plugin.

      As I’ve said, we are concerned about all types of users and are open to feedback. Please get in touch with me by email if you have more concerns, comments, or questions.


      1. Hi Tim,

        Thanks for acknowledging.

        Most of the warnings are for when you are calling non-static methods with the :: syntax, i.e. JetPack::get_option() but get_option() is not declared static. Why this is a concern is that if I have JetPack on a site I’m debugging it makes it very hard to notice real errors in my own plugins if JetPack is throwing so many messages.

        If you want to see the warnings JetPack throws you can see them here on Gist: https://gist.github.com/4410469. It’s almost 300 warnings but ironically it’s really only a few places you need to fix since most of the warnings are repeated many times. There are however a few warnings regarding call_user_func_array() that could actually be undiscovered bugs.

        As for emailing you, what’s your email? Or via this? http://dreaminginbetween.com/contact/ Also, may I suggest you guys add a prominent link to the plugin with text like “Report an Issue with JetPack” and have it link to a page in the WordPress admin that allows for submission of issues? I don’t always want to post issues in the support forum and offering an obvious way for users to give you feedback will minimize the number of people who vent on Twitter or on blogs. Oh, and make sure the issue reporting link is visible *before* connection to WordPress.com because the issues might be with connection.

        P.S. I just tried installing JetPack on a publicly accessible site and got the “site_inaccessible” error. The site has WP e-Commerce installed and when I deactivated it JetPack connected. Just FYI.


      2. Mike,

        tim@automattic.com is the way to get to me.

        One of our Jetpack devs has gone through and changed a lot of the functions to static to fix these warnings. Version 2.1 should be cleaner for you.

        I’ve been thinking along the same lines about the direct submission form in the Jetpack plugin. We’ve also got some debugging tools that we’d like to build in at some point to help with errors, such as your “site_inaccessible” one. Lots of stuff on the roadmap.

        Let me know any time you have any feedback.




      3. Very cool Tim, glad to hear about v2.1 and the potential for a direct submission form and thanks for the email.

        Also, looks like we are going to be working on debugging tools as well although it sounds like you might be working on something specific to JetPack. We need something to help us more quickly diagnose conflicts between our plugins and the theme or with other plugins and/or that can help a support person gain access to the users site to inspect it. If you think there’s room collaboration via GitHub contact me at mike -at- newclarity.net.


  11. I resent being forced to have the WP.com account. Why self host? The ability to use these plugins without the Jetpack would be nice. thanks, Matt.


  12. […] After years of free support, and now doing this for a living, the common user doesn’t have the experience to understand that while I may need to connect to WordPress.com for the stats, why do I need it for a mobile theme? The problem comes up when the user wants to start with the items they don’t need to connect. Springing it on them later is an uphill battle I wish I didn’t have to make. So yes, it’s sensible for the average user. As Helen said, Jetpack is for users, not developers. […]


  13. Thanks for one’s marvelous posting! I truly enjoyed reading
    it, you happen to be a great author.I will always bookmark
    your blog and will often come back later on. I want to encourage
    continue your great writing, have a nice day!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s