Cómo ejecutar Jetpack localmente en desarrollo

El método en el enlace proporcionado por @TracyRotton parece no funcionar desde Jetpack 2.0 y WordPress 3.4.2.

Incluso replicando todos los campos de la base de datos, no actúa como si estuviera conectado.

Como la pregunta original es sobre sincronizar entornos de desarrollo y producción, tal vez no sea posible.

No he probado en profundidad qué módulos funcionan y cuáles no, pero se puede engañar a Jetpack para que crea que está conectado haciendo la siguiente modificación en el archivo /plugins/jetpack/jetpack.php.

Dentro de la clase Jetpack_Data, modifica la primera función get_access_token así:

class Jetpack_Data {    
    function get_access_token( $user_id = false ) {
        return 'VALOR-DE-USER_TOKENS-ENCONTRADO-DENTRO-DE-LA-OPCIÓN-JETPACK_OPTIONS'; // <---truco
        if ( $user_id ) {
            if ( !$tokens = Jetpack::get_option( 'user_tokens' ) ) {
                return false;
            }

O simplemente coloca un return true; en lugar del user_tokens que podemos copiar de la opción jetpack_options.

_{PD: la primera versión de esta respuesta usaba otro truco. Aquí, es una modificación de una línea que lo cubre todo, en teoría...}

Es posible engañar a JetPack copiando los valores de los campos de la base de datos desde una instalación activada a tu instalación local.

En una instalación remota con JetPack conectado, busca en la tabla wp_options los campos option_name que comiencen con jetpack_, como por ejemplo:

• jetpack_activated
• jetpack_options
• jetpack_nonce_{cadena_aleatoria}
• jetpack_active_modules

Copia estos campos y sus valores en la base de datos de tu instalación local.

Para más detalles sobre este proceso, consulta: http://www.ravendevelopers.com/node/57

Inspirado en la última solución de brasofilo, hay una forma aún más sencilla, solo abre jetpack.php, busca:

/**
* ¿Está Jetpack activo?
*/
public static function is_active() {
    return (bool) Jetpack_Data::get_access_token( JETPACK_MASTER_USER );
}

y reemplázalo con esto:

/**
* ¿Está Jetpack activo?
*/
public static function is_active() {
    return true;
}

Parece ser mucho más fácil que manipular la base de datos y funcionó para mí con la versión de Jetpack 2.1.1 y WordPress versión 3.5.

Pero deberías establecer una regla de ignorar para este archivo o algo similar si deseas mantener el plugin funcionando correctamente en el sitio en vivo, ya que es mejor estar conectado de la manera real que codificar manualmente la bandera de activo.

Si deseas toda la funcionalidad de Jetpack, tu entorno de desarrollo deberá ser consultable públicamente. Puedes configurar esto haciendo que tu dirección de desarrollo sea un subdominio, por ejemplo sandbox.misitio.com, estableciendo ese registro DNS para que apunte a la dirección IP donde se encuentra tu servidor de desarrollo y posiblemente configurando tu router/firewall para permitir solicitudes al puerto 80 hacia tu máquina.

Otra opción es ejecutar un entorno de staging y usarlo para todo lo relacionado con Jetpack. Los entornos de staging tienen muchas ventajas, por lo que sería una inversión valiosa configurarlo de todos modos.

El filtro jetpack_development_mode:

Solo quiero mencionar el filtro jetpack_development_mode.

Puedes usar simplemente:

add_filter( 'jetpack_development_mode', '__return_true' );

para ejecutar JetPack localmente.

Un pequeño plugin:

Para evitar tener que modificar el archivo wp-config.php con el truco habitual:

define ('JETPACK_DEV_DEBUG', true);

ahora puedes controlarlo con este pequeño plugin:

<?php
/**
 * Plugin Name: Ejecutar JetPack localmente
 * Plugin URI:  http://wordpress.stackexchange.com/a/144317/26350
 * Version:     0.0.1
 */
add_filter( 'jetpack_development_mode', '__return_true' );

Puedes verlo en GitHub.

La solución en http://ravendevelopers.com/node/57 PUEDE que no funcione con versiones de Jetpack superiores a la 2.x. Si no funciona en la versión 2.x, intenta instalar Jetpack primero en tu sitio en vivo (por ejemplo, ejemplo.com), conéctalo a wordpress.com y luego importa la configuración desde tu sitio en vivo a tu localhost/ejemplo que debe ser el mismo (la configuración importada desde ejemplo.com puede que no funcione con localhost/ejemplo2). El punto es que lo que hagas en tu sitio en vivo, asegúrate de que la configuración importada sea para el mismo sitio en tu localhost.

Mmm, parece que tu respuesta puede simplificarse. Adopta este cambio y votaré positivamente tu respuesta.

Dado que is_active() devuelve true, solo necesitas cambiar una línea en admin_page():

1. cambia el valor $is_user_connected a 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);
    // ...la función continúa