If you’re creating WordPress websites for clients, Jetpack adds a number of features to your client sites without the need for a dozen different plugins — reducing the technical debt that you need to maintain, and saving you time and your clients money. Here are some of our favorite tips for using Jetpack to streamline your work with clients.
Using Jetpack during development
Jetpack lets you work on sites in either Development Mode and Staging Mode, enabling you to test and try new things without impacting a client’s live site. What’s the difference, and how are they useful? Keep reading!
Development Mode
Development Mode lets you work with features that don’t require a connection to WordPress.com servers and often a great way to build on top of Jetpack. Development mode is automatically enabled when you don’t have a period in your site’s hostname, i.e. localhost, and can also be manually enabled if you’re working on a development server or other URL.
Enable Development Mode as constant in wp-config.php by adding:
define( 'JETPACK_DEV_DEBUG', true);
or add it as a filter in your theme’s functions.php or a development plugin via:
add_filter( 'jetpack_development_mode', '__return_true' );
For adding filters, we strongly recommend using a development plugin to 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. A good development plugin reduces the number of items on your launch checklist, leaving fewer things to slip through the cracks when launching a site.
A Development Mode filter added via a plugin might look something like this:
No matter how you enable Development Mode, ensure it is disabled before handing the site over the client to ensure your clients don’t ask why Jetpack isn’t working!
Staging Mode
A staging site is a testing site meant to replicate a production site, so you can test changes without impacting your site’s visitors — or your client’s business. Enabling Jetpack’s Staging Mode on your staging server enables you to keep all of Jetpack’s functions active without possibly impacting your production site.
Your staging site will have all the same Jetpack features enabled, except nothing will be sent up to WordPress.com. You can test styling on Related Posts or customize the default message in Publicize without actually publicizing anything to your social media networks or generating e-mail notifications.
As of Jetpack 3.9.2, you enable Staging Mode by adding this to your staging sites’s wp-config.php:
define( 'JETPACK_STAGING_MODE', true );
Then, simply clone your production site to staging and enjoy. You can safely copy your site from production to staging and back to production without impacting Jetpack or Jetpack’s connection to WordPress.com. To make things even easier, we automatically enable Staging Mode on all WP Engine staging sites, and will be adding more hosting providers soon.
Other Development Tips
We realize that development processes can’t always follow the practices outlined above. What if you’re testing changes to a feature that requires a connection to WordPress.com for a site still in development and never connected to WordPress.com, 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 while you work on the site. One thing to remember when using a connected site during development is to first disconnect Jetpack from your WordPress.com account before migrating to your production server. Then, when the migration is done, reconnect the site on the production URL with your client’s WordPress.com account.
Why is it important to disassociate your account from the client site? Many site developers will connect Jetpack to WordPress.com with their WordPress.com account for convenience. This becomes problematic when you end up with hundreds of sites listed on your https://wordpress.com/sites page. Since it is often likely that your work will be done for the client once development is completed, it’s also likely that you do not need or want access to the site 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 bottleneck.
From your client’s perspective, if Jetpack is connected to your account, they also aren’t able to manage their Jetpack connection via https://wordpress.com/sites 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.
Speaking of managing sites on WordPress.com…
Managing Sites on WordPress.com
If you do manage sites on behalf of your clients, you can manage menus, posts, pages, plugins, and more through a single unified dashboard on WordPress.com — saving time and money for you and your clients. We’re adding more and more functionality to site management on this dashboard – keep an eye on our blog for updates and new additions.
Through WordPress.com, you can also upgrade to Jetpack Premium and Jetpack Business to access Akismet and VaultPress for an anti-spam solution, backups, and security scanning services.
Finding help
Question? We offer free support, so contact us anytime. If you think you’ve discovered a bug or found a particular pain point, don’t keep it to yourself! We want to make Jetpack the first plugin you install on every client site.
In addition to our e-mail support, for bugs or feature requests, we develop Jetpack on GitHub.
If you’re particularly proud of how you have used Jetpack on a client site, let us know in the comments; we’re always excited to hear how people our using our tools and services to make the web a better place.
Jetpack 
I love the features of Jetpack but it’s getting more and more complex from a UI standpoint. And some of the features overlap with very popular plugins. Take sitemaps for example… it should honestly just be a part of the core WP platform and not even require a plugin. All search engines have agreed on the standard. But Jetpack doesn’t have critical optimization tools for meta titles and descriptions that other plugins do. It requires me to now configure each against the other to ensure no conflicts. It’s getting busy folks. I feel like Jetpack should extend itself into dozens of plugins rather than trying to be everything to everyone.
LikeLike
Thanks for commenting, Doug! We do aim to play nicely with other plugins that provide similar features. For example, our Sitemaps module will not auto-activate if you have a plugin we know about that already provides one. Jetpack, too, allows site admins to customize the modules that appear at all so you can remove the Sitemaps modules from appearing at all on client sites.
Our philosophy is we try to provide the functionality that virtually every site could benefit from having. In some cases, there are specific use cases that go beyond what Jetpack has out of the box, and so we do aim to play nicely if you install a case-specific plugin (e.g. our Contact Form module doesn’t activate if you have another form plugin installed already).
Cheers!
LikeLike
thanks
LikeLike
Why dont you simply add a switch in the GUI for “Dev” “Staging” “Live” and save having to hack the WP Config file?
LikeLike
There’s a few considerations that makes that problematic, a major one being that any time that a staging site is set to “live”, it has the potential to update options on WordPress.com, polluting the data there. We had the beginning of a UI in Jetpack 3.8 that demonstrated that. Another one is an UI will generally need to save the state to the database, which means moving the site between staging/dev/production will likely modify the state of the other site (requiring you to use the UI to switch between them everytime you switch and relying on you to remember to update it each time).
With the ability to use a constant or a URL regex pattern, you can add modify what Jetpack looks for via a plugin that can live on the production site—so you can actually avoid using wp-config.php if you’re solid with regex or if there’s a known PHP constant that is only active on staging/dev (WP Engine and Pantheon both do that, and likely most of the other managed hosts that provide staging environments).
In short, we’ve thought of that but it provided more problematic to expose a developer/advanced feature via UI. Cheers!
LikeLike