Jetpack em execução localmente [fechado]

16

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.

AlecRust
fonte

Respostas:

24

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' );
jb510
fonte
2
O modo Dev / Debug procura o cabeçalho Requires Connectionnos arquivos dos módulos ( jetpack/modules/*.php). Dessa forma, podemos verificar quais funcionarão no modo dev ou não.
Brasofilo 17/07/2013
A lista do que ainda apresenta o trabalho quando o modo de desenvolvimento é ativado em localhost: wpperform.com/jetpack-development-mode
Casey Plummer
9

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.
banco de dados jetpack


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

brasofilo
fonte
Você também pode precisar de cortar os módulos individuais, como o force_user_connection()método publicize/publicize-jetpack.php. Mesmo assim, ele ainda não parece se comportar exatamente como se estivesse realmente conectado. Eu não procurei o código extensivamente, mas minha suspeita é que existem muitos outros lugares no código que precisam ser invadidos para realmente fazer com que ele seja executado exatamente da mesma maneira que faria em um servidor ativo.
Ian Dunn
1
@IanDunn, concordou, minha resposta é mais sobre "não me chateie por estar conectado e deixe-me testar alguns ganchos" e realmente não tem como alvo o problema do OP de ter versões dev e implantadas em sincronia.
Brasofilo
@IanDunn, encontrou outra maneira, talvez mais eficaz. Atualizado a resposta, o que você acha?
Brasofilo
Tentei algo semelhante ao de ontem, mas ainda não consegui reproduzir o problema que estava vendo no meu servidor de teste, por isso não tenho certeza se funciona completamente ou não. O problema acabou sendo um bug em um plug-in diferente e está corrigido agora, então não preciso mais hackear o Jetpack.
Ian Dunn
7

É 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

Tracy Rotton
fonte
Obrigado pelo link. Eu recebo o erro do MySQL "# 1062 - Entrada duplicada 'jetpack_activated' para a chave 'option_name'"
AlecRust
4

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.

GabLeRoux
fonte
3

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.

Matthew Boynes
fonte
2

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 .

Birgire
fonte
-1

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.

anithegregorian
fonte
-2

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
Matt Senate
fonte
Oi Matt, entendo que este é um comentário à minha resposta. Existem 2 is_activefunções no JetPack, é por isso que a solução parece redundante, mas não é :)
brasofilo
Hmm, vou dar uma olhada. Eu pensei que havia encontrado apenas um método is_active que estava na classe Jetpack, mas verificará novamente.
Matt Senado