Jetpack em execução localmente [fechado]

Gostaria de saber se alguém sabia uma maneira fácil de contornar isso.

O código por trás da minha versão de desenvolvedor local de uma instância do WordPress e da versão ao vivo está sincronizado (como deveria ser). O problema é que isso significa que o plug-in "Jetpack" está funcionando na versão ao vivo (já que é um blog ao vivo que pode se conectar ao WordPress.com), mas não na versão local do desenvolvedor.

Isso significa que a funcionalidade está disponível na versão ao vivo (como o widget da barra lateral "Inscrever-se"), mas não na versão local do desenvolvedor, portanto, eles estão fora de sincronia.

A partir do JetPack 2.2.1, agora existe um modo local de desenvolvimento / depuração. http://jetpack.me/2013/03/28/jetpack-dev-mode-release/

usar:

define ('JETPACK_DEV_DEBUG', true);

no seu wp-config e você deve ter acesso a qualquer módulo que não exija conexão para funcionar.

Atualização, já que na v3.3 outro gatilho de desenvolvimento local foi adicionado via filtro em vez de definir.

O mais recente já está aqui: http://jetpack.me/support/development-mode/

O modo de desenvolvimento é ativado automaticamente se você não tiver um ponto no nome do host do seu site, ou seja, localhost. Se você usar uma URL diferente, como mycooltestsite.local ou algo assim, será necessário definir a constante JETPACK_DEV_DEBUG.

Você também pode ativar o modo de desenvolvimento do Jetpack através de um plug-in, graças ao filtro jetpack_development_mode:

add_filter( 'jetpack_development_mode', '__return_true' );

A partir do Jetpack v3.9, agora também existe um filtro no modo de armazenamento temporário que força um site a ser recongizado como site de armazenamento temporário em vez de produção: https://developer.jetpack.com/hooks/jetpack_is_staging_site/

add_filter( 'jetpack_is_staging_site', '__return_true' );

O método no link fornecido pelo @TracyRotton parece não estar funcionando desde o Jetpack 2.0 e o WordPress 3.4.2.

Mesmo replicando todos os campos do banco de dados, ele não age como conectado.

Como a pergunta do OP é sobre a sincronização de ambientes de desenvolvimento e produção, talvez não seja possível.

Não testei detalhadamente quais módulos funcionam e quais não, mas o Jetpack pode ser induzido a acreditar que ele está conectado, fazendo a seguinte modificação no arquivo /plugins/jetpack/jetpack.php.

Dentro da classe Jetpack_Data, modifique a primeira função 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;
            }

Ou simplesmente coloque um em return true;vez do user_tokensque podemos copiar de dentro da opção jetpack_options.

_{PS: a primeira versão desta resposta usou outro truque. Aqui, é uma modificação de uma linha que captura tudo, em teoria ...}

É possível enganar o JetPack, copiando os valores do campo do banco de dados de uma instalação ativada para a instalação local.

Em uma instalação (remota) com o JetPack conectado, procure na wp_optionstabela os option_namecampos que começam com jetpack_, como:

• jetpack_activated
• jetpack_options
• jetpack_nonce_{random_string}
• jetpack_active_modules

Copie esses campos e valores no banco de dados de instalações locais.

Para mais detalhes sobre esse processo, consulte: http://www.ravendevelopers.com/node/57

Inspirado na solução mais recente da brasofilo, existe ainda uma maneira mais fácil: basta abrir o jetpack.php, procurar

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

e substitua por isso:

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

Parece ser muito mais fácil do que brincar com o banco de dados e funcionou para mim com a versão Jetpack 2.1.1e a versão WordPress3.5

Mas você deve definir uma regra para ignorar esse arquivo ou algo assim, se quiser manter o plug-in funcionando bem no site ativo, porque é melhor estar conectado de maneira real do que codificar o sinalizador ativo.

Se você quiser a funcionalidade completa do Jetpack, seu ambiente de desenvolvimento precisará ser consultado publicamente. Você pode configurar isso transformando seu endereço de desenvolvedor em um subdomínio, por exemplo, sandbox.mysite.com, configurando esse registro DNS para apontar para o endereço IP em que seu servidor de desenvolvimento está localizado e, possivelmente, configurando seu roteador / firewall para permitir solicitações de porta 80 através de à sua máquina.

Outra opção é executar um ambiente de teste e usá-lo para qualquer coisa relacionada ao Jetpack. Os ambientes de armazenamento temporário têm muitas vantagens, portanto, seria um investimento interessante configurá-lo de qualquer maneira.

O jetpack_development_modefiltro:

Eu só quero mencionar o jetpack_development_modefiltro.

Você pode simplesmente usar:

add_filter( 'jetpack_development_mode', '__return_true' );

para executar o JetPack localmente.

Um pequeno plugin:

Para evitar ter que modificar o wp-config.phparquivo com o truque usual:

define ('JETPACK_DEV_DEBUG', true);

agora você pode controlá-lo através deste pequeno 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' );

Você pode conferir no GitHub .

A correção em http://ravendevelopers.com/node/57 PODE não funcionar com versões do Jetpack acima de 2.x. Se não funcionar na versão 2.x, tente instalar o Jetpack em seu site ao vivo primeiro (exemplo.com), conecte-o ao wordpress.com e importe as configurações do site ao vivo para o host / exemplo local, que deve ser o mesmo (as configurações importadas de example.com podem não funcionar com localhost / example2). O que você faz no seu site ativo, verifique se as configurações importadas são para o mesmo site no host local.

Hmm, parece que sua resposta pode ser simplificada. Adote essa alteração e eu votarei na sua resposta.

Como is_active () retorna true, você só precisa alterar uma linha em admin_page ():

1.altere o valor $is_user_connectedparatrue

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