With the new features in Jetpack 2.0, it’s more important than ever to keep straight your wordpress.com 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 wordpress.com in general (for Stats, Sharing, Akismet, etc), but users will also need to connect (“link”) their website account to their personal wordpress.com 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:
- Find out if the client/contact person is actively using a wordpress.com 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.
- 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 wordpress.com.
- Install Jetpack, and initiate the connection to wordpress.com. Verify that Jetpack wants to connect to the correct wordpress.com account (which should automatically be chosen if you’re logged in already in another window).
- When you’ve got the “Connected to wordpress.com” 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.
kwight.blog 