Wondered if anyone knew an easy way around this.

The code behind my local dev version of a WordPress instance and the live version are in sync (as they should be). Problem is this means the "Jetpack" plugin is working on the live version (since it's a live blog that can connect to WordPress.com) but not on the local dev version.

This means functionality is available on the live version (like the "Subscribe" sidebar widget) but not on the local dev version, thus they're out of sync.

closed as off-topic by Pieter Goosen, Mark Kaplun, birgire, Nicolai, cybmeta Dec 9 '14 at 11:30

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.


As of JetPack 2.2.1 there is now a local development/debug mode. http://jetpack.me/2013/03/28/jetpack-dev-mode-release/


define ('JETPACK_DEV_DEBUG', true);

in your wp-config and you should have access to any modules that don't require a connection to function.

Update, since around v3.3 another local development trigger was added via filter instead of define.

Latest is now here: http://jetpack.me/support/development-mode/

Development mode automatically gets enabled if you don’t have a period in your site’s hostname, i.e. localhost. If you use a different URL, such as mycooltestsite.local or something, then you will need to define the JETPACK_DEV_DEBUG constant.

You can also enable Jetpack’s development mode through a plugin, thanks to the jetpack_development_mode filter:

add_filter( 'jetpack_development_mode', '__return_true' );

As of Jetpack v3.9 there is also now a staging mode filter that forces a site to be recongized as a staging site rather than production: https://developer.jetpack.com/hooks/jetpack_is_staging_site/

add_filter( 'jetpack_is_staging_site', '__return_true' );
  • 2
    The Dev/Debug mode looks for the header Requires Connection in the modules files (jetpack/modules/*.php). This way we can check which ones will work in dev mode or not. – brasofilo Jul 17 '13 at 20:25
  • A list of what features still work when development mode is enabled on localhost: wpperform.com/jetpack-development-mode – Casey Jan 10 at 2:57

The method in the link provided by @TracyRotton seems not to be working since Jetpack 2.0 and WordPress 3.4.2.

Even replicating all database fields, it doesn't act as connected.
jetpack database

As the OP question is about syncing a development and a production environments, maybe it is not possible.

I haven't tested in-depth which modules work and which not, but Jetpack can be tricked into believing it is connected making the following modification in the file /plugins/jetpack/jetpack.php.

Inside the class Jetpack_Data, modify the very first function get_access_token like:

class Jetpack_Data {    
    function get_access_token( $user_id = false ) {
        if ( $user_id ) {
            if ( !$tokens = Jetpack::get_option( 'user_tokens' ) ) {
                return false;

Or simply put a return true; instead of the user_tokens that we can copy from inside the option jetpack_options.

PS: the first version of this answer used another trick. Here, it is a one-line modification that catches all, in theory...

  • You may also need to hack individual modules, like the force_user_connection() method in publicize/publicize-jetpack.php. Even with that, though, it still doesn't seem to behave exactly the same as if it's actually connected. I haven't dug through the code extensively, but my suspicion is that there are many more places in the code that need to be hacked in order to really make it execute exactly the same as it would on a live server. – Ian Dunn Jan 1 '13 at 21:42
  • 1
    @IanDunn, agreed, my answer is more about "don't nag me about being connected and let me test some hooks" and doesn't really target the OP issue of having dev and deployed versions in sync. – brasofilo Jan 2 '13 at 12:34
  • @IanDunn, found another way, maybe more effective. Updated the answer, what do you think? – brasofilo Jan 2 '13 at 14:08
  • I tried something similar to that yesterday, but still couldn't reproduce the problem I was seeing on my staging server, so I'm not sure if it works completely or not. The problem turned out to be a bug in a different plugin and it's fixed now, so I no longer need to hack Jetpack. – Ian Dunn Jan 2 '13 at 17:08

It is possible to trick JetPack by copying the database field values from an activated install into your local install.

On an install (remote) with JetPack connected search the wp_options table for option_name fields beginning with jetpack_, such as:

  • jetpack_activated
  • jetpack_options
  • jetpack_nonce_{random_string}
  • jetpack_active_modules

Copy these fields and values into your local installs database.

For more detail on this process see: http://www.ravendevelopers.com/node/57

  • Thanks for the link. I get the MySQL error "#1062 - Duplicate entry 'jetpack_activated' for key 'option_name'" – AlecRust Oct 12 '12 at 0:30

Inspired by brasofilo's latest solution, there's even an easier way, just open jetpack.php, search for

* Is Jetpack active?
public static function is_active() {
    return (bool) Jetpack_Data::get_access_token( JETPACK_MASTER_USER );

and replace with this:

* Is Jetpack active?
public static function is_active() {
    return true;

Seems to be alot easier than playing with the database and worked for me with Jetpack version 2.1.1 and WordPress version 3.5

But you should set an ignore rule for this file or something like that if you want to keep the plugin working fine on the live site because it's better to be connected by the real way than hardcoding the active flag.


If you want full Jetpack functionality, your development environment will need to be publicly queryable. You can set this up by making your dev address a subdomain, e.g. sandbox.mysite.com, setting that DNS record to point to the IP address where your development server is located, and possibly configuring your router/firewall to allow port 80 requests through to your machine.

Another option is to run a staging environment, and use that for anything Jetpack-related. Staging environments have many advantages, so it would be a worthwhile investment to set that up anyway.


The jetpack_development_mode filter:

I just want to mention the jetpack_development_mode filter.

You can simply use:

add_filter( 'jetpack_development_mode', '__return_true' );

to run JetPack locally.

A tiny plugin:

To avoid having to modify the wp-config.php file with the usual trick:

define ('JETPACK_DEV_DEBUG', true);

you can now control it via this tiny plugin:

 * Plugin Name: Run JetPack locally
 * Plugin URI:  http://wordpress.stackexchange.com/a/144317/26350
 * Version:     0.0.1
add_filter( 'jetpack_development_mode', '__return_true' );

You can check it out on GitHub.


The fix on http://ravendevelopers.com/node/57 MIGHT not work with Jetpack versions above 2.x. If it doesn't work on version 2.x try to install Jetpack on your live site first like (example.com), connect it to wordpress.com and then import the settings from your live site to your localhost/example which must be the same (settings imported from example.com might not work with localhost/example2). Thing is what you do on your live site, make sure the imported settings are for the same site on your localhost.


Hmm, seems like your answer can be simplified. Adopt this change and I'll up-vote your answer.

Since is_active() returns true, you only need to change one line in admin_page():

1. change the value $is_user_connected to true

function admin_page() {
    global $current_user;

    $role = $this->translate_current_user_to_role();
    $is_connected = Jetpack::is_active();
    $user_token = Jetpack_Data::get_access_token($current_user->ID);
    $is_user_connected = true;//$user_token && !is_wp_error($user_token);
    // ...function continues
  • Hi Matt, I understand that this is a comment to my answer. There are 2 is_active functions in JetPack, that's why the solution seems redundant, but it's not :) – brasofilo Nov 27 '12 at 2:15
  • Hmm, I'll take a look. I thought I only found one is_active method that was in the Jetpack class, but will check again. – Matt Senate Nov 30 '12 at 21:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.