Jetpack and accounts

With the new features in Jetpack 2.0, it’s more important than ever to keep straight your accounts – particularly if you’re developing sites for clients that will be using Jetpack. I won’t pretend to understand all of the details yet, but some quick research and perusing of the sparse, user-centric Jetpack site led me to the following.

Certain features (Notifications, Publicize, Post by Email, Mobile Push Notifications) are specific to users on your website. This means that not only is your site connected to in general (for Stats, Sharing, Akismet, etc), but users will also need to connect (“link”) their website account to their personal account also for the above-mentioned features to be usable. This explains the confusing screenshot below:

It also means that additional care should be taken when setting up a new site with Jetpack for the first time. I’ll be using the following procedure with new client websites from now on:

  1. Find out if the client/contact person is actively using a account. If they say no, create a new account for them, using the same email that was used to create their admin account on their own website.
  2. Log in to their site using the client’s admin account, not your own. In a different window, also log in to their account on
  3. Install Jetpack, and initiate the connection to Verify that Jetpack wants to connect to the correct account (which should automatically be chosen if you’re logged in already in another window).
  4. When you’ve got the “Connected to” go-ahead, activate whichever additional modules are appropriate for your client.

By connecting Jetpack in this manner, the additional user-specific features of Jetpack will be functional for the client’s account by default.

Jetpack has a lot of tools to offer developers for easing the process of creating WordPress websites: contact forms, built-in stats, sharing, social comments and the awesome new Photon and Infinite Scroll are just a few. Starting to work “with” instead of against Jetpack (and much better developer-focused documentation and localhost capability from Automattic) will result in better .org sites with less stress on the part of developers.

Published by

Kirk Wight

I am a Code Wrangler at Automattic, helping make the best it can be. Pender Island, British Columbia, Canada is where I call home. Lover, not a fighter.

Leave a Reply

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

You are commenting using your 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