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.