Jetpack Running Locally [closed]

Question

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.

Answer 1

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

use:

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' );

Answer 2

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.

---

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 ) {
        return 'USER_TOKENS-VALUE-FOUND-INSIDE-THE-OPTION-JETPACK_OPTIONS'; // <---trick
        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...}

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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:

<?php
/**
 * 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.

Answer 7

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.

Answer 8

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