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' );
Requires Connection
dans les fichiers de modules (jetpack/modules/*.php
). De cette façon, nous pouvons vérifier ceux qui fonctionneront en mode dev ou non.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 fonctionget_access_token
comme:Ou mettez simplement un
return true;
au lieu de celuiuser_tokens
que nous pouvons copier de l'intérieur de l'optionjetpack_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 ...
la source
force_user_connection()
méthode danspublicize/publicize-jetpack.php
. Même avec cela, cependant, il ne semble toujours pas se comporter exactement comme s'il était réellement connecté. Je n'ai pas fouillé le code de manière approfondie, mais je soupçonne qu'il y a beaucoup plus d'endroits dans le code qui doivent être piratés afin de le faire vraiment s'exécuter exactement comme il le ferait sur un serveur live.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_options
table lesoption_name
champs commençant parjetpack_
, 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
la source
Inspiré par la dernière solution de brasofilo, il existe un moyen encore plus simple, ouvrez simplement jetpack.php, recherchez
et remplacez par ceci:
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.1
et 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.
la source
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.
la source
Le
jetpack_development_mode
filtre:Je veux juste mentionner le
jetpack_development_mode
filtre.Vous pouvez simplement utiliser:
pour exécuter JetPack localement.
Un petit plugin:
Pour éviter d'avoir à modifier le
wp-config.php
fichier avec l'astuce habituelle:vous pouvez maintenant le contrôler via ce petit plugin:
Vous pouvez le vérifier sur GitHub .
la source
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.
la source
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_connected
entrue
la source
is_active
fonctions dans JetPack, c'est pourquoi la solution semble redondante, mais ce n'est pas le cas :)