If you’re creating WordPress websites for clients, Jetpack is for you. Jetpack easily adds a great number of features to your client’s websites without the need for a dozen different plugins, reducing the technical debt that you or your client will need to maintain over time.
We recommend these best practices when using Jetpack for a client site that will keep things running smoothly and help you provide a great service to your clients.
This article covers:
- Use Jetpack’s Development Mode
- Invite your client to connect a WordPress.com account
- Activate Jetpack only on the live domain
- Use your account when a connection is required
- Work with staging sites
- How to install Jetpack
1. Use Development Mode
Jetpack offers a Development Mode that is enabled when using Jetpack on a localhost. If you’re developing on a development server, you can manually enable development mode.
You can enable this as constant in wp-config.php by adding:
define( 'JETPACK_DEV_DEBUG', true);
or you can add this as a filter in your theme’s functions.php or a development plugin via:
add_filter( 'jetpack_development_mode', '__return_true' );
Use a development plugin
We suggest using a “Development Plugin” that you can use for all of your in-development needs. With a custom development plugin, you can include the Jetpack Development Mode filter and include other necessary tools like the Debug Bar. The added benefit is that it reduces the number of items on your launch checklist and consequently less things to slip through the cracks when launching. The code might look something like this:
No matter how you enable Development Mode, ensuring that it is disabled before handing the site over the client is important to ensure your clients aren’t asking you or us why Jetpack isn’t working!
2. Invite your client to connect the site to a WordPress.com account
Many site developers will connect Jetpack to WordPress.com with their WordPress.com account for convenience. This becomes problematic however when you end up with hundreds of sites listed on your http://wordpress.com/my-blogs/ page. After your work is done its very likely that for many (if not most) of them you do not need or want access to any longer unless you have a continued relationship with the client. (Even if you do, its a good idea to teach your clients to self-serve so that you’re not a bottle-neck.)
From your client’s perspective, if Jetpack is connected to your account, they aren’t able to manage their Jetpack connection via http://wordpress.com/my-blogs/ or access their enhanced stats via WordPress.com.
Your client may already have a WordPress.com account if they’ve used Gravatar or Akismet in the past so very often its easy to connect Jetpack with their existing account.
3. Activate Jetpack only on the live domain
Jetpack connections are based on the URL of the site. Often, we’ll see a Jetpack user write in asking why all of their stats suddenly disappeared or why do their wp.me shortlinks don’t work. Typically, their site was originally connected when it was on a development address and the migration to the live URL didn’t pass back to us.
To avoid this, connect Jetpack to WordPress.com only on the live domain.
4. Use your account when a connection is required
With the above practices stated, we realize that development processes can’t always follow the practices outlined above. What if you’re developing off of a feature that requires a WordPress.com-connected feature, like styling our Subscription widget?
While on a development server, you can connect your client’s site to WordPress.com with your own WordPress.com account. The key is to disconnect Jetpack from WordPress.com using the link in the footer of the Jetpack dashboard page at the beginning of the migration to your production server and reconnecting after the site is on the production URL with the client using their WordPress.com account.
By doing this, you’ll disassociate your account from the client site and your client’s site will be connected using the production URL, avoiding the most common pitfalls of client sites.
5. Work with staging sites
An increasing number of hosting providers include a staging site, where you can have an exact copy of the client’s site on a separate server. This is great for testing out updates, new features, and more.
Jetpack communicates with WordPress.com through a shared token and blog ID that is stored in the database. When the staging site is copied from the live site, these database values are included. Whenever you deactivate Jetpack, Jetpack communicates with WordPress.com to invalidate the token as a solid security practice.
For you, this means if you deactivate/disconnect Jetpack on the staging site, the same token used on the live site is now invalid. If this happens, simply have the client disconnect and reconnect Jetpack on the live site.
6. How to install Jetpack
If you’ve never used Jetpack before and you’re looking for some guidance on how to install it for the first time, you’re in the right place!
There are two ways of installing the Jetpack plugin:
- The simplest way is install it directly from your Dashboard. You can find step-by-step instructions here.
- Alternatively, if you’re an advanced user, you can download the plugin files (.ZIP) and install it manually.
Finally, if you discover a bug in Jetpack during your development work, please submit an issue or a patch via GitHub. If you have questions or run into problems, drop us a line or leave a comment to share your tips on using Jetpack with clients.
Jetpack 
Very helpful hints Brandon, thank you!
I have a question related to points 3 and 4 (and maybe 5): How does Photon behaves in that case?
I mean, say that I am temporarily connected with my (developer) WP.com account, or I’m developing the site on a “non live URL” (or a staging site).
Now I’m uploading images with Photon activated.
When the site is finished I move the site to it’s official URL (and hosting), and disconnect Jetpak from my account and reconnect it with the client account.
What happens to the Photon images? I’ll stil get them?
Stefano
LikeLike
Photon caches images simply—through the URL of the image. No matter the account attached to the WordPress site, it will be cached at an URL like http://i2.wp.com/www.example.com/wp-content/uploads/2014/06/image.jpg . If the account changes, everything still works fine.
If the URL changes, Photon uses the siteurl as defined by the site, so it will recache the images on the live URL at new addresses. The location of the Photon-ized images aren’t saved within WordPress since we dynamically replace the URLs.
Cheers!
LikeLike
Cool!
Thanks!
LikeLike
It would be nice if there could be shared connections for JetPack — kind of like Google Analytics works, or Facebook Pages — i.e. the connection can be setup and maintained by any account deemed an “Admin” for the domain. This way, stats and connections can be setup and maintained by a developer, but also accessed by the client via their account.
Most of my clients can’t be bothered to set up their own WordPress.com account, and even if decide they do want one, I usually have to set it up for them anyway, along with their Facebook Page and Twitter account, etc.
Conversely, if a client uses their own account, I don’t have access to their full stats which I often need to look at for them.
I think the reality is that a lot of developers use their own WordPress.com accounts for JetPack connections, so it’d be nice if JetPack moved to support that scenario more fully, because the reverse — clients using their own WordPress.com accounts — is just not a very practical real-world scenario.
-Michael
LikeLike
That’s a good suggestion. It’d take a good amount of background improvements, but something to absolutely keep in mind as we retool/improve Jetpack.
LikeLike
Thanks Brandon! I’m a big Jetpack fan, I’ve installed it on dozens of sites. I’m also a big Markdown fan, and before Jetpack Markdown I tried at least 9 different Markdown plugins and had issues with all of them, so Jetpack Markdown has been a dream for me!
Here’s the *but* … I’ve just run Plugin Performance Profiler and was disappointed to discover that Jetpack adds nearly 600ms to my page load times. I wondered if turning off as many Jetpack modules as possible would help, but that didn’t lower times at all.
I love Jetpack, but we all know how critical tiny differences in page load times are for your visitors. Just 2 plugins: Jetpack + Yoast SEO are putting almost 900ms on my load times and almost nothing is worth that huge a performance hit. Do you have any suggestions for taking less of a performance hit from Jetpack? Or do you think the Plugin Performance Profiler numbers are wrong? TY Brandon!
LikeLike
P3 is a great tool as part of a larger overview of what your site is doing. We’re working with the developers of P3 to make it more useful for Jetpack users (e.g. breakdown by module, instead of Jetpack as a whole).
One caveat of P3 with Jetpack is Jetpack is more resource intensive while logged in (the stats “sparkline” in the admin menu, Notifications, and other processes that run only for logged-in users) which “inflates” what P3 reports since it, by default, checks the site while logged in as you.
In other words, it isn’t perfect, but we are working with them to improve the report’s relevance as well as actually improve the performance of Jetpack.
LikeLike
I’m confused. Isn’t jetpack just used for non WordPress.com sites (self-hosted)? Normally you cannot install plugins with WordPress.com sites (I.e. inlinkz, rafflecopter), which is why I’m thinking of moving to self hosted. What is jetpack exactly and can I install on my WordPress.com site?
LikeLike
Jetpack is for self-hosted sites. The quickest way of thinking of Jetpack is it adds much/most of the features exclusive to WordPress.com to self-hosted sites (Stats, Sharing, Publicize, etc).
It can’t be installed on WordPress.com, if for no other reason, that all of the features are already enabled on WP.com sites.
LikeLike
Okay thanks for clarifying. Still lots to learn. I think it was point 2 that had me confused.
LikeLike
One thing I’ve experienced since using Jetpack is that Jetpack breaks stuff. I liken it to the Microsoft philosophy of developing exclusivity in the software, any way they can. The ‘fix’ is always to delete plugins. When usually, the fix is to delete the Jetpack module. My most recent experience with this is the broken comment ‘feature.’ Something about an invalid token.
Thanks for listening.
LikeLike
If anything seems broken, please do contact us—either via our contact form or via the link in the Jetpack Debugger (accessible from the footer of the Jetpack page in your site’s dashboard).
We specifically avoid the exclusivity model. For example, Jetpack includes Open Graph tags by default when certain modules are active, which many other plugins add too. If we know of a plugin that can add them, we add them to a list that, if the plugin is active, we silently deactivate our Open Graph tags to avoid duplication (which would cause problems when sharing to Facebook, Twitter, etc).
Likewise, we specifically won’t auto-activate modules when we know they conflict with an existing plugin. The code for both of these checks can be viewed here for 3.0.2.
Since Jetpack does touch a number of aspects of WordPress, there are more opportunities to discover conflicts and issues involving other plugins. When possible, we gladly try to work around them on our end and will reach out to theme or plugin developers if it something that require them to adjust something for both to play together nicely.
For the invalid token issue, typically, that presents itself when deactivating Jetpack from a staging site or if someone is using an existing site as a “template” to create another site, then deactivate Jetpack on the second site. The connection is severed for the first site, resulting in the invalid token.
For the site displaying the invalid token notice, disconnecting from WordPress.com via the footer of the Jetpack page in your WordPress dashboard and reconnecting to WordPress.com typically resolves it.
LikeLike
Reblogged this on WP Devsigners and commented:
This is a really useful post for those of you using Jetpack. I’m admittedly terrible about having clients connect with their own account rather than mine, though that has never caused me a problem…yet. The tips about staging sites and activating on the live domain seem REALLY important!
LikeLike