Jetpack corriendo localmente [cerrado]

Me preguntaba si alguien sabía una forma fácil de evitar esto.

El código detrás de mi versión de desarrollo local de una instancia de WordPress y la versión en vivo están sincronizadas (como deberían ser). El problema es que esto significa que el complemento "Jetpack" funciona en la versión en vivo (ya que es un blog en vivo que puede conectarse a WordPress.com) pero no en la versión de desarrollo local.

Esto significa que la funcionalidad está disponible en la versión en vivo (como el widget de barra lateral "Suscribirse") pero no en la versión de desarrollo local, por lo que no están sincronizados.

A partir de JetPack 2.2.1 ahora hay un modo de desarrollo / depuración local. http://jetpack.me/2013/03/28/jetpack-dev-mode-release/

utilizar:

define ('JETPACK_DEV_DEBUG', true);

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

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

Lo último ya está aquí: http://jetpack.me/support/development-mode/

El modo de desarrollo se habilita automáticamente si no tiene un punto en el nombre de host de su sitio, es decir, localhost. Si usa una URL diferente, como mycooltestsite.local o algo así, deberá definir la constante JETPACK_DEV_DEBUG.

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

add_filter( 'jetpack_development_mode', '__return_true' );

A partir de Jetpack v3.9 ahora también hay un filtro de modo de preparación que obliga a un sitio a ser reconocido como un sitio de preparación en lugar de producción: https://developer.jetpack.com/hooks/jetpack_is_staging_site/

add_filter( 'jetpack_is_staging_site', '__return_true' );

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 conectado.

Como la pregunta OP se trata de sincronizar un entorno de desarrollo y uno de 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, modifique la primera función get_access_tokencomo:

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;
            }

O simplemente pon un en return true;lugar del user_tokensque podemos copiar desde dentro de la opción jetpack_options.

_{PD: la primera versión de esta respuesta usó otro truco. Aquí, es una modificación de una línea que atrapa a todos, 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 wp_optionstabla option_namecampos que comiencen 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: http://www.ravendevelopers.com/node/57

Inspirado en la última solución de brasofilo, hay una manera aún más fácil, simplemente abra jetpack.php, busque

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

y reemplazar con esto:

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

Parece mucho más fácil que jugar con la base de datos y funcionó para mí con la versión Jetpack 2.1.1y la versión WordPress3.5

Pero debe establecer una regla de ignorar para este archivo o algo así si desea que el complemento funcione bien en el sitio en vivo porque es mejor estar conectado de la manera real que codificar el indicador activo.

Si desea la funcionalidad completa de Jetpack, su entorno de desarrollo deberá ser de consulta pública. Puede configurar esto haciendo que su dirección de desarrollo sea 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 las solicitudes del puerto 80 a través de a su máquina

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

El jetpack_development_modefiltro:

Solo quiero mencionar el jetpack_development_modefiltro.

Simplemente puede usar:

add_filter( 'jetpack_development_mode', '__return_true' );

para ejecutar JetPack localmente.

Un pequeño complemento:

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

define ('JETPACK_DEV_DEBUG', true);

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

Puedes verlo en GitHub .

La corrección en http://ravendevelopers.com/node/57 podría NO funcionar con las versiones de Jetpack anteriores 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 localhost / ejemplo que debe ser lo mismo (la configuración importada de example.com podría no funcionar con localhost / example2). La cosa es lo que haces en tu sitio en vivo, asegúrate de que la configuración importada sea para el mismo sitio en tu host local.

Hmm, parece que tu respuesta se puede simplificar. Adopte este cambio y votaré su respuesta.

Como is_active () devuelve verdadero, solo necesita cambiar una línea en admin_page ():

1.cambiar el valor $is_user_connectedatrue

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