20 Comments


  1. Great stuff! This didn’t make the release. “Added SSO option to turn off login form completely, to use WordPress.com login exclusively”

    Looks to be commented out in the code ‘Remove default login form?’

    Reply

    1. There is not a UI element for controlling turning off local login in this version, however it can still be done via a filter with the following:

      add_filter( ‘jetpack_sso_bypass_login_forward_wpcom’, ‘__return_true’ );

      Reply

  2. I wonder if the code has been trimmed down at all, as Jetpack typically is a resource hog.

    Reply

      1. Thanks Ben. I have a client with a very large and high traffic site hosted on Synthesis. We’ve had quite a few performance issues, and Synthesis recommended removing Jetpack as the codebase is larger than WP itself. Definitely seems bloated to me. There’s only a couple of modules I ever use anyway, and the rest are just superfluous. Thoughts?

        Reply

        1. Hey Seth—
          The size issue is somewhat unfair. WordPress, uncompressed, runs at about 16.9 MB. Jetpack, uncompressed, runs at 6 MB—if you exclude the language files included in Jetpack.

          WP doesn’t ship with any language files and, for the moment, there isn’t a way to have a translated plugin without shipping all languages to everyone (unless you ask the user to manually download and upload a file). Those files aren’t called upon unless the WPLANG is defined in wp-config.php to a non-English language.

          That’s changing in the near-ish future once language packs—the ability to on-demand ship translations to only the users who need them—are rolled out to plugins.

          With the module approach, the modules that aren’t activated aren’t called upon, so those files are just sitting on the file system. They wouldn’t be in active memory and wouldn’t impact performance.

          Cheers!

          Reply

          1. Thanks for the clarification, Brandon. I might give it another go, just worried about the resource usage after the last time. We’ll see though!


          2. Some modules will use considerably more resource usage than others. I’m not sure what the resource hogs are, but I know that the contact form plugin for example, had significantly better performance than Gravity Forms last time I checked. So individually, some of the modules are quite good.


  3. Looking at all the modules in Jetpack I feel I need more education, and start reading. So far so good. But worry about the end user trying to figure out what feature would be relevant for his/her site. Jetpack try to explain, but it’s a lot of buzzwords and of “fantastic” things work.

    What is the “Google+ Authorship Banner”? When and where is it seen? Is it annoying?
    What is the “Google Maps Engine”? Something else than Google Maps?

    “Infinite Scroll” has been just a disaster on any site, on any theme, I have tried it. Doesn’t work and makes it impossible to go to the next page. Does this update mean that it now will work?

    It’s said that Jetpack is primarily for the end user. I regard myself a developer, and I love most of the features, but this is really hard to understand. Why should I need Twitter “card”? Never heard of it. What is the benefit? And so on.

    I like the new module management under Settings, but the “Home” is far to big in height and covers more than my entire screen. Ridiculously high.

    Is Jetpack aiming to be the new, big SEO plugin, taking over for AIOSEOP and WP SEO? I fear conflicts, problems for the end user, when SEO plugins also add Open Graph tags and other technologies related to social media.

    Has Jetpack now become the advanced site developers toolkit, not “goodies” for the end user or common blogger?

    Jepack is an options, not decisions hell. This is the opposite philosophy of WordPress core, and Matt Mullenweg is behind both. I still I love it for what it does, when it works. I makes WordPress a mature CMS for todays world and demands. The greatest plugin of all times. But I am worried.

    I never have had any resource problems with Jetpack, but I am not using all the modules all the time, of course.

    Reply

    1. Thanks for the thoughtful comment and it makes a lot of sense.

      The Google+ Authorship banner is a little piece of “flair” that is added when linking your WP account to your Google+ account. It is enabled on this post above. Some folks don’t like it, so it is optional now.

      Twitter Cards are discussed more here: https://dev.twitter.com/docs/cards
      Basically, when you click on a tweet and it has more to it than just the tweet, that’s how.

      With Infinite Scroll, we’ve made a lot of enhancements, including making it less of a resource hog (loads new posts only within two screenfuls of the bottom instead of within the bottom 25%, which got kinda crazy if you scrolled down a few times, etc). I’m not sure if it will fix your specific problem or not.

      Can you try it and if things are still amiss, send us a note at http://jetpack.me/contact-support/ ? We’d be happy to check it out.

      Thanks again for the comments. Cheers!

      Reply

  4. From a visual point of view and in light of usability, the update makes Jetpack even worse than before.

    Still we have useless background image that lets users feel like they are in a whole different app. Also, the intro page is totally useless, it’s just propaganda, it has no use.

    The “settings” page alone would be totally sufficient, but with module descriptions and fonfig buttons/ links *permanently* “on”, I mean viewable/ clickable!

    In the current state I consider this plugin user unfriendly – and my experience with clients showed just that, even in version 2.x.

    Another thing, are the unresolved privacy issues and the many settings links/ redirections to a lot of different locations within WordPress admin dashboard.

    WordPress plugin developers are being preached to use WordPress default admin styles, but the Automattic product Jetpack does not care for a lot of that. Bad role model.

    Reply

    1. Hi David. We take the privacy of our users very seriously. Whenever you have any privacy or security concerns we want to know. I would really appreciate it if you could shoot us an email with the privacy concerns you have at http://jetpack.me/contact-support/.

      As far as the UI is concerned, Jetpack is a constantly evolving process. We always strive to do things with the user in mind. It sounds like you may have some good ideas on how to accomplish that. I would love to see you involved in the process. Jetpack exists on Github and is available to all to submit patches. Take a look at our contributor guide at http://jetpack.me/contribute/ and get involved in the discussion at http://github.com/automattic/jetpack.

      Reply

  5. The related posts is a nice new addition. My only concern with Jetpack is that I have always found it slowed my site down a bit. Anyone else experience this?

    Reply

  6. While I might read a lot of WordPress articles, I’ve rarely commented.

    I decided to comment here because I’m finally seeing more than a couple of people in one place articulate the frustrations regarding Jetpack. I can tell by reading most of the remarks I’m not alone in having frustration build over a long period of time.

    The discontinuation of the old Stats plugin is the *only* reason I started using Jetpack in the first place. I didn’t want to lose several years of stats history with understood parameters, so yes, it was a “decision” to continue. However, I wasn’t a happy camper regarding the change from a single purpose tool to what I viewed *at that point* as _________________ [fill in the blank with points made above]. And that was when there were…what…at most…six modules?

    With the exception of a couple of older sites with that Stat history I do want to keep, I’m working towards phasing Jetpack out completely.

    Unfortunately, a good amount of “available” time for research on the subject has been spent on first triaging sites with load time issues and very often finding Jetpack is somehow involved, directly or indirectly (slow load or conflict), and/or dealing with new issues with almost every update (automatically activated modules, trying to figure what some of the stuff even is).

    all the while, knowing, I need to decide whether I can customize things, permanently, where I would like to retain Stats.

    As far as privacy (and security) concerns go, I don’t think you can fix what is baked in the cake, but my biggest concerns about Gravatar. (http://wptavern.com/how-to-use-ghostery-to-find-trackers-added-by-wordpress-plugins, http://meta.stackexchange.com/questions/44717/is-gravatar-a-privacy-risk http://meta.stackexchange.com/questions/21117/is-using-gravatar-a-security-risk, http://arstechnica.com/security/2013/07/got-an-account-on-a-site-like-github-hackers-may-know-your-e-mail-address/, http://benjamin-meyer.blogspot.com/2014/03/how-to-stop-leaking-your-internal-sites.html)

    I do believe most of the individual folks who work on Jetpack are incredibly responsive and helpful, etc. To underline this, I’ll point out something that might be helpful to people who still want / need to use Jetpack but want to strip out modules altogether. Jeremy Herve provided detailed instructions and code last November. I’ve tested it and it does work wonderfully:

    http://jeremyherve.com/2013/11/19/customize-the-list-of-modules-available-in-jetpack/

    You can have some fabulous, incredibly smart people working on a project, but, if there’s a set plan or a philosophy that’s the problem, you can’t change what’s baked in the cake. This quot from Knut summarizes the root of the problem(s):

    “Has Jetpack now become the advanced site developers toolkit, not “goodies” for the end user or common blogger?

    Jepack is an options, not decisions hell.”

    The best thing would be to make all plugins separate and have Jetpack be a warehouse of all Automattic plugins IF users DECIDE that’s what they want.

    Reply

    1. Thank you for your comment. We love receiving feedback from our users and are constantly iterating based on what we hear from users like you.

      Jetpack was created with the philosophy of making it easier to bring features from WordPress.com to WordPress self-hosted sites. The description on the about Jetpack page (http://jetpack.me/about/) summarizes it as:

      “Back in the day, there were great features available to WordPress.com users that were not available on self-hosted WordPress installs. Jetpack is a plugin that connects to WordPress.com and enables awesome features, powered by our cloud infrastructure.”

      Automattic began releasing small plugins for WordPress.com features but as the set of features to be released grew the need to have a unified point of development and release also grew and thus Jetpack was born. Now instead of installing more than 33 individual plugins you only need to install 1 to bring the power of the WordPress.com platform to your site. This unification also allows a lot of code to be shared across Jetpack instead of duplicated throughout what would be individual plugins.

      We are working on improving error catching and profiling the code to make Jetpack even faster and more powerful for users. If installing Jetpack to utilize just one feature is providing a sub-optimal experience the Jetpack team would be happy to work with you on an individual basis. I hope we can work together. Drop us a line at http://jetpack.me/contact-support/ and one of our people will get back to you.

      Lastly, Jetpack is an open project on Github. Everyone is free to contribute code patches, submit issues, talk about features, and even provide support for the future of new/existing features in Jetpack. I encourage you to join the conversation at https://github.com/automattic/jetpack. Together we can build an even better Jetpack and propel ourselves into the future!

      Reply

Leave a Reply