Jetpack ejecutándose localmente [cerrado]

A partir de JetPack 2.2.1 ahora hay un modo de desarrollo / depuración local. enlace

utilizar:

define ('JETPACK_DEV_DEBUG', true);

en tu wp-config y deberías tener acceso a cualquier módulo que no requiera una conexión para funcionar.

Actualización, ya que alrededor de v3.3 se agregó otro desencadenante de desarrollo local a través de un filtro en lugar de definir.

Lo último ya está aquí: enlace

  

El modo de desarrollo se habilita automáticamente si no tienes un período   en el nombre de host de su sitio, es decir, localhost. Si usas una URL diferente,   como mycooltestsite.local o algo así, entonces necesitarás   define la constante JETPACK_DEV_DEBUG.

     

También puede habilitar el modo de desarrollo de Jetpack a través de un complemento, gracias al filtro de modo de desarrollo jetpack:

add_filter( 'jetpack_development_mode', '__return_true' );

A partir de Jetpack v3.9 ahora también hay un filtro de modo de ensayo que obliga a un sitio a reconocerse como un sitio de almacenamiento en lugar de producción: enlace

add_filter( 'jetpack_is_staging_site', '__return_true' );

El método en el enlace provisto por @TracyRotton parece no estar funcionando desde Jetpack 2.0 y WordPress 3.4.2.

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

ComolapreguntaOPserefierealasincronizacióndeundesarrolloyunentornodeproducción,talveznoseaposible.

Noheprobadoenprofundidadquémódulosfuncionanycuálesno,perosepuedeengañaraJetpackparaquecreaqueestáconectadorealizandolasiguientemodificaciónenelarchivo/plugins/jetpack/jetpack.php.

DentrodelaclaseJetpack_Data,modificalaprimerafunciónget_access_tokencomo:

classJetpack_Data{functionget_access_token($user_id=false){return'USER_TOKENS-VALUE-FOUND-INSIDE-THE-OPTION-JETPACK_OPTIONS';//<---trickif($user_id){if(!$tokens=Jetpack::get_option('user_tokens')){returnfalse;}

Osimplementecoloqueunreturntrue;enlugardeluser_tokensquepodemoscopiardesdedentrodelaopciónjetpack_options.

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

Es posible engañar a JetPack copiando los valores del campo de la base de datos de una instalación activada en su instalación local.

En una instalación (remota) con JetPack conectado, busque en la tabla wp_options para los campos option_name que comienzan con jetpack_ , como:

• jetpack_activated
• jetpack_options
• jetpack_nonce_{random_string}
• jetpack_active_modules

Copie estos campos y valores en su base de datos de instalaciones locales.

Para obtener más detalles sobre este proceso, consulte: enlace

Inspirado en la última solución de brasofilo, hay incluso una forma más sencilla, simplemente abra jetpack.php, busque

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

y reemplace con esto:

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

Parece ser mucho más fácil que jugar con la base de datos y me funcionó con la versión de Jetpack 2.1.1 y la versión de WordPress 3.5

Pero debe establecer una regla de ignorar para este archivo o algo así si quiere que el complemento funcione bien en el sitio en vivo porque es mejor estar conectado de forma real que codificando la marca activa.

Si desea la funcionalidad completa de Jetpack, su entorno de desarrollo deberá ser públicamente accesible. Puedes configurarlo configurando tu dirección de desarrollo como un subdominio, por ejemplo. sandbox.mysite.com, configurando ese registro DNS para que apunte a la dirección IP donde se encuentra su servidor de desarrollo, y posiblemente configurando su enrutador / firewall para permitir que las solicitudes del puerto 80 lleguen a su máquina.

Otra opción es ejecutar un entorno de prueba y usarlo para cualquier cosa relacionada con Jetpack. Los entornos de prueba tienen muchas ventajas, por lo que sería una inversión valiosa para configurar eso 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 complemento:

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

define ('JETPACK_DEV_DEBUG', true);

ahora puedes controlarlo a través de este pequeño complemento:

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

Puede comprobarlo en GitHub .

La solución en enlace NO PUEDE funcionar con versiones de Jetpack superiores a 2.x. Si no funciona en la versión 2.x, intente instalar Jetpack en su sitio en vivo primero como (example.com), conéctelo a wordpress.com y luego importe la configuración de su sitio en vivo a su host local / ejemplo, que debe ser lo mismo (es posible que la configuración importada de example.com no funcione con localhost / example2). Cosa es lo que haces en tu sitio en vivo, asegúrate de que las configuraciones importadas sean para el mismo sitio en tu host local.

Hmm, parece que tu respuesta puede ser simplificada. Adopte este cambio y votaré su respuesta.

Como 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);
    // ...function continues