Jetpack in esecuzione localmente [chiuso]

Mi chiedevo se qualcuno sapesse un modo semplice per aggirare questo.

Il codice dietro la mia versione di sviluppo locale di un'istanza di WordPress e la versione live sono sincronizzati (come dovrebbero essere). Il problema è che questo significa che il plugin "Jetpack" funziona sulla versione live (dal momento che è un blog live che può connettersi a WordPress.com) ma non sulla versione di sviluppo locale.

Ciò significa che la funzionalità è disponibile nella versione live (come il widget della barra laterale "Iscriviti") ma non nella versione di sviluppo locale, quindi non sono sincronizzati.

A partire da JetPack 2.2.1 esiste ora una modalità di sviluppo / debug locale. http://jetpack.me/2013/03/28/jetpack-dev-mode-release/

uso:

define ('JETPACK_DEV_DEBUG', true);

nel tuo wp-config e dovresti avere accesso a tutti i moduli che non richiedono una connessione per funzionare.

Aggiornamento, poiché intorno alla v3.3 è stato aggiunto un altro trigger di sviluppo locale tramite filtro invece di definire.

L'ultima è ora qui: http://jetpack.me/support/development-mode/

La modalità di sviluppo viene abilitata automaticamente se non hai un punto nel nome host del tuo sito, ad esempio localhost. Se usi un URL diverso, come mycooltestsite.local o qualcosa del genere, dovrai definire la costante JETPACK_DEV_DEBUG.

Puoi anche abilitare la modalità di sviluppo di Jetpack tramite un plugin, grazie al filtro jetpack_development_mode:

add_filter( 'jetpack_development_mode', '__return_true' );

A partire da Jetpack v3.9 ora esiste anche un filtro per la modalità di gestione temporanea che forza un sito a essere ricongelato come sito di gestione temporanea anziché produzione: https://developer.jetpack.com/hooks/jetpack_is_staging_site/

add_filter( 'jetpack_is_staging_site', '__return_true' );

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

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

Poiché la domanda di OP riguarda la sincronizzazione di uno sviluppo e di ambienti di produzione, forse non è possibile.

Non ho testato in modo approfondito quali moduli funzionano e quali no, ma Jetpack può essere indotto a credere che sia collegato apportando la seguente modifica nel file /plugins/jetpack/jetpack.php.

All'interno della classe Jetpack_Data, modifica la prima funzione get_access_tokencome:

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 semplicemente metti un al return true;posto di quello user_tokensche possiamo copiare dall'opzione jetpack_options.

_{PS: la prima versione di questa risposta ha usato un altro trucco. Qui, è una modifica di una riga che cattura tutto, in teoria ...}

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

Su un'installazione (remota) con JetPack connesso, cerca nella wp_optionstabella i option_namecampi che iniziano con jetpack_, come:

• jetpack_activated
• jetpack_options
• jetpack_nonce_{random_string}
• jetpack_active_modules

Copia questi campi e valori nel database delle installazioni locali.

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

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

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

e sostituiscilo con questo:

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

Sembra essere molto più facile che giocare con il database e ha funzionato per me con la versione Jetpack 2.1.1e la versione WordPress3.5

Ma dovresti impostare una regola ignora per questo file o qualcosa del genere se vuoi che il plugin funzioni correttamente sul sito live perché è meglio essere connessi in modo reale piuttosto che codificare il flag attivo.

Se si desidera la piena funzionalità Jetpack, l'ambiente di sviluppo dovrà essere interrogabile pubblicamente. Puoi configurarlo trasformando il tuo indirizzo di sviluppo in un sottodominio, ad esempio sandbox.mysite.com, impostando quel record DNS in modo che punti all'indirizzo IP in cui si trova il tuo server di sviluppo ed eventualmente configurando il tuo router / firewall per consentire le richieste della porta 80 attraverso alla tua macchina.

Un'altra opzione è quella di eseguire un ambiente di gestione temporanea e utilizzarlo per tutto ciò che riguarda Jetpack. Gli ambienti di gestione temporanea presentano molti vantaggi, quindi sarebbe comunque utile investirlo.

Il jetpack_development_modefiltro:

Voglio solo menzionare il jetpack_development_modefiltro.

Puoi semplicemente usare:

add_filter( 'jetpack_development_mode', '__return_true' );

per eseguire JetPack localmente.

Un piccolo plugin:

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

define ('JETPACK_DEV_DEBUG', true);

ora puoi controllarlo tramite questo piccolo 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' );

Puoi verificarlo su GitHub .

La correzione su http://ravendevelopers.com/node/57 potrebbe non funzionare con le versioni Jetpack precedenti alla 2.x. Se non funziona con la versione 2.x, prova a installare Jetpack sul tuo sito live prima come (esempio.com), collegalo a wordpress.com e quindi importa le impostazioni dal tuo sito live al tuo host locale / esempio che deve essere lo stesso (le impostazioni importate da example.com potrebbero non funzionare con localhost / example2). La cosa è ciò che fai sul tuo sito live, assicurati che le impostazioni importate siano per lo stesso sito sul tuo host locale.

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

Poiché is_active () restituisce true, devi solo cambiare una riga in admin_page ():

1.cambia il valore $is_user_connectedintrue

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