Jetpack Running Locally [fermé]

Je me demandais si quelqu'un connaissait un moyen facile de contourner cela.

Le code derrière ma version de développement local d'une instance WordPress et la version live sont synchronisés (comme ils devraient l'être). Le problème est que le plugin "Jetpack" fonctionne sur la version live (car c'est un blog live qui peut se connecter à WordPress.com) mais pas sur la version de développement local.

Cela signifie que les fonctionnalités sont disponibles sur la version live (comme le widget de barre latérale "S'abonner") mais pas sur la version de développement local, donc elles ne sont pas synchronisées.

Depuis JetPack 2.2.1, il existe désormais un mode de développement / débogage local. http://jetpack.me/2013/03/28/jetpack-dev-mode-release/

utilisation:

define ('JETPACK_DEV_DEBUG', true);

dans votre wp-config et vous devriez avoir accès à tous les modules qui ne nécessitent pas de connexion pour fonctionner.

Mise à jour, car autour de la v3.3, un autre déclencheur de développement local a été ajouté via le filtre au lieu de définir.

Le plus récent est maintenant disponible: http://jetpack.me/support/development-mode/

Le mode de développement est automatiquement activé si vous n'avez pas de point dans le nom d'hôte de votre site, c'est-à-dire localhost. Si vous utilisez une URL différente, telle que mycooltestsite.local ou quelque chose, vous devrez définir la constante JETPACK_DEV_DEBUG.

Vous pouvez également activer le mode de développement de Jetpack via un plugin, grâce au filtre jetpack_development_mode:

add_filter( 'jetpack_development_mode', '__return_true' );

À partir de Jetpack v3.9, il existe également un filtre de mode de transfert qui oblige un site à être reconverti en site de transfert plutôt qu'en production: https://developer.jetpack.com/hooks/jetpack_is_staging_site/

add_filter( 'jetpack_is_staging_site', '__return_true' );

La méthode du lien fourni par @TracyRotton ne semble pas fonctionner depuis Jetpack 2.0 et WordPress 3.4.2.

Même en répliquant tous les champs de la base de données, il n'agit pas comme connecté.

Comme la question OP concerne la synchronisation d'un développement et d'un environnement de production, ce n'est peut-être pas possible.

Je n'ai pas testé en profondeur quels modules fonctionnent et lesquels ne fonctionnent pas, mais Jetpack peut croire qu'il est connecté en effectuant la modification suivante dans le fichier /plugins/jetpack/jetpack.php.

A l'intérieur de la classe Jetpack_Data, modifiez la toute première fonction get_access_tokencomme:

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 mettez simplement un return true;au lieu de celui user_tokensque nous pouvons copier de l'intérieur de l'option jetpack_options.

_{PS: la première version de cette réponse a utilisé une autre astuce. Ici, c'est une modification d'une ligne qui capture tout, en théorie ...}

Il est possible de tromper JetPack en copiant les valeurs de champ de base de données d'une installation activée dans votre installation locale.

Sur une installation (distante) avec JetPack connecté, recherchez dans la wp_optionstable les option_namechamps commençant par jetpack_, tels que:

• jetpack_activated
• jetpack_options
• jetpack_nonce_{random_string}
• jetpack_active_modules

Copiez ces champs et valeurs dans votre base de données d'installations locale.

Pour plus de détails sur ce processus, voir: http://www.ravendevelopers.com/node/57

Inspiré par la dernière solution de brasofilo, il existe un moyen encore plus simple, ouvrez simplement jetpack.php, recherchez

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

et remplacez par ceci:

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

Semble être beaucoup plus facile que de jouer avec la base de données et a fonctionné pour moi avec la version Jetpack 2.1.1et la version WordPress3.5

Mais vous devez définir une règle d'ignorance pour ce fichier ou quelque chose comme ça si vous voulez que le plugin fonctionne correctement sur le site en direct, car il vaut mieux être connecté par la vraie manière que de coder en dur l'indicateur actif.

Si vous voulez une fonctionnalité Jetpack complète , votre environnement de développement devra être publiquement interrogeable. Vous pouvez configurer cela en faisant de votre adresse de développeur un sous-domaine, par exemple sandbox.mysite.com, en définissant cet enregistrement DNS pour qu'il pointe vers l'adresse IP où se trouve votre serveur de développement, et en configurant éventuellement votre routeur / pare-feu pour autoriser les demandes du port 80 via à votre machine.

Une autre option consiste à exécuter un environnement de transfert et à l'utiliser pour tout ce qui concerne Jetpack. Les environnements de mise en scène présentent de nombreux avantages, ce serait donc un investissement intéressant de les configurer de toute façon.

Le jetpack_development_modefiltre:

Je veux juste mentionner le jetpack_development_modefiltre.

Vous pouvez simplement utiliser:

add_filter( 'jetpack_development_mode', '__return_true' );

pour exécuter JetPack localement.

Un petit plugin:

Pour éviter d'avoir à modifier le wp-config.phpfichier avec l'astuce habituelle:

define ('JETPACK_DEV_DEBUG', true);

vous pouvez maintenant le contrôler via ce petit 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' );

Vous pouvez le vérifier sur GitHub .

Le correctif sur http://ravendevelopers.com/node/57 NE PEUT PAS fonctionner avec les versions Jetpack supérieures à 2.x. Si cela ne fonctionne pas sur la version 2.x, essayez d'abord d'installer Jetpack sur votre site en direct comme (exemple.com), connectez-le à wordpress.com puis importez les paramètres de votre site en direct vers votre hôte local / exemple qui doit être les mêmes (les paramètres importés d'exemple.com peuvent ne pas fonctionner avec localhost / example2). La chose est ce que vous faites sur votre site en direct, assurez-vous que les paramètres importés sont pour le même site sur votre hôte local.

Hmm, il semble que votre réponse puisse être simplifiée. Adoptez ce changement et je voterai favorablement votre réponse.

Puisque is_active () renvoie true, vous n'avez besoin de changer qu'une seule ligne dans admin_page ():

1.changer la valeur $is_user_connectedentrue

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