Jetpack Running Localmente

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

O código por trás da minha versão local de dev de uma instância do WordPress e da versão ao vivo está em sincronia (como deveria ser). O problema é que isso significa que o plugin “Jetpack” está funcionando na versão ao vivo (uma vez que é um blog ao vivo que pode se conectar ao WordPress.com), mas não na versão local do dev.

Isso significa que a funcionalidade está disponível na versão ao vivo (como o widget “Assinar” da barra lateral), mas não na versão local do dev, portanto, eles estão fora de sincronia.

Solutions Collecting From Web of "Jetpack Running Localmente"

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

usar:

define ('JETPACK_DEV_DEBUG', true); 

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

Atualização, uma vez que, em torno de v3.3, outro gatilho de desenvolvimento local foi adicionado por meio de filtro em vez de definir.

O último momento está aqui: http://jetpack.me/support/development-mode/

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

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

 add_filter( 'jetpack_development_mode', '__return_true' ); 

A partir do Jetpack v3.9, existe agora um filtro de modo de teste que obriga um site a ser recongificado como um site de teste 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 database, ele não age como conectado.
banco de dados do jetpack


Como a questão OP é sobre a synchronization de um desenvolvimento e um ambiente de produção, talvez não seja possível.

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

Dentro da class Jetpack_Data , modifique a primeira function get_access_token como:

 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 colocar um return true; em vez de user_tokens que podemos copiar de dentro da opção jetpack_options .

PS: a primeira versão dessa resposta usou outro truque. Aqui, é uma modificação de uma linha que capta tudo, em teoria ...

É possível enganar o JetPack copiando os valores do campo do database de uma instalação ativada para sua instalação local.

Em uma instalação (remota) com o JetPack conectado, pesquise a tabela wp_options para os campos do nome da opção que começam com o jetpack_ , como:

  • jetpack_activated
  • jetpack_options
  • jetpack_nonce_{random_string}
  • jetpack_active_modules

Copie esses campos e valores para o database de instalações local.

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

Inspirado na última solução da brasofilo, há ainda uma maneira mais fácil, basta abrir o jetpack.php, procurar por

 /** * 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 jogar com o database e funcionou para mim com Jetpack versão 2.1.1 e WordPress versão 3.5

Mas você deve definir uma regra de ignorar para este arquivo ou algo assim se você quiser manter o plugin funcionando bem no site ao vivo, porque é melhor estar conectado pela maneira real do que codificar a bandeira ativa.

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

Outra opção é executar um ambiente de teste e usar isso para qualquer coisa relacionada ao Jetpack. Os ambientes de teste têm muitas vantagens, por isso seria um investimento valioso para configurar isso de qualquer maneira.

O filtro jetpack_development_mode :

Eu só quero mencionar o filtro jetpack_development_mode .

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 arquivo wp-config.php com o truque usual:

 define ('JETPACK_DEV_DEBUG', true); 

agora você pode controlá-lo através deste minúsculo 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 verificá-lo no GitHub .

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

Hmm, parece que sua resposta pode ser simplificada. Adote esta mudança e vou votar a sua resposta.

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

1. altere o valor $is_user_connected para 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