Jetpack in esecuzione in locale

Il metodo nel link fornito da @TracyRotton sembra non funzionare a partire da Jetpack 2.0 e WordPress 3.4.2.

Anche replicando tutti i campi del database, non viene riconosciuto come connesso.

Poiché la domanda originale riguarda la sincronizzazione tra ambienti di sviluppo e produzione, forse non è possibile farlo.

Non ho testato in profondità quali moduli funzionino e quali no, ma Jetpack può essere ingannato facendogli credere che sia connesso apportando la seguente modifica nel file /plugins/jetpack/jetpack.php.

All'interno della classe Jetpack_Data, modificare la prima funzione get_access_token in questo modo:

class Jetpack_Data {    
    function get_access_token( $user_id = false ) {
        return 'VALORE-USER_TOKENS-TROVATO-NELL-OPZIONE-JETPACK_OPTIONS'; // <---trucco
        if ( $user_id ) {
            if ( !$tokens = Jetpack::get_option( 'user_tokens' ) ) {
                return false;
            }

Oppure semplicemente inserire un return true; al posto del user_tokens che possiamo copiare dall'opzione jetpack_options.

_{PS: la prima versione di questa risposta utilizzava un altro trucco. Qui, si tratta di una modifica di una riga che dovrebbe coprire tutto, in teoria...}

È possibile ingannare JetPack copiando i valori dei campi del database da un'installazione attivata alla propria installazione locale.

Su un'installazione (remota) con JetPack connesso, cerca nella tabella wp_options i campi option_name che iniziano con jetpack_, come ad esempio:

• jetpack_activated
• jetpack_options
• jetpack_nonce_{random_string}
• jetpack_active_modules

Copia questi campi e i relativi valori nel database della tua installazione locale.

Per maggiori dettagli su questo processo consulta: http://www.ravendevelopers.com/node/57

Ispirato dall'ultima soluzione di brasofilo, c'è un modo ancora più semplice, basta aprire jetpack.php, cercare

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

e sostituire con questo:

/**
* Jetpack è attivo?
*/
public static function is_active() {
    return true;
}

Sembra molto più semplice che giocare con il database e ha funzionato per me con la versione di Jetpack 2.1.1 e WordPress versione 3.5

Ma dovresti impostare una regola di esclusione per questo file o qualcosa di simile se vuoi mantenere il plugin funzionante correttamente sul sito live, perché è meglio essere connessi nel modo reale piuttosto che hardcodare il flag di attivazione.

Se desideri la funzionalità completa di Jetpack, il tuo ambiente di sviluppo dovrà essere interrogabile pubblicamente. Puoi configurarlo rendendo il tuo indirizzo di sviluppo un sottodominio, ad esempio sandbox.miosito.com, impostando il record DNS per puntare all'indirizzo IP in cui si trova il tuo server di sviluppo e possibilmente configurando il tuo router/firewall per consentire le richieste sulla porta 80 alla tua macchina.

Un'altra opzione è quella di utilizzare un ambiente di staging e usarlo per tutto ciò che riguarda Jetpack. Gli ambienti di staging offrono molti vantaggi, quindi sarebbe un investimento utile configurarlo comunque.

Il filtro jetpack_development_mode:

Vorrei menzionare il filtro jetpack_development_mode.

Puoi semplicemente utilizzare:

add_filter( 'jetpack_development_mode', '__return_true' );

per eseguire JetPack in locale.

Un piccolo plugin:

Per evitare di dover modificare il file wp-config.php con il solito trucco:

define ('JETPACK_DEV_DEBUG', true);

ora puoi controllarlo tramite questo piccolo plugin:

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

Puoi verificarlo su GitHub.

La correzione su http://ravendevelopers.com/node/57 POTREBBE non funzionare con le versioni di Jetpack superiori alla 2.x. Se non funziona sulla versione 2.x prova prima a installare Jetpack sul tuo sito live (ad esempio example.com), connettilo a wordpress.com e poi importa le impostazioni dal tuo sito live al tuo localhost/example che deve essere lo stesso (le impostazioni importate da example.com potrebbero non funzionare con localhost/example2). Il punto è che quello che fai sul tuo sito live, assicurati che le impostazioni importate siano per lo stesso sito sul tuo localhost.

Hmm, sembra che la tua risposta possa essere semplificata. Adotta questa modifica e voterò positivamente la tua risposta.

Dato che is_active() restituisce true, devi solo modificare una riga in admin_page():

1. cambia il valore $is_user_connected in 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 funzione continua