Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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.

share|improve this question

8 Answers 8

up vote 13 down vote accepted

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.

Yay!

share|improve this answer
1  
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

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.

share|improve this answer

It is possible to trick JetPack by copying the DB 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 install's DB.

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

share|improve this answer
    
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

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 ) {
        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...

share|improve this answer
    
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

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
share|improve this answer
    
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

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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