誰もがこれを回避する簡単な方法を知っているのだろうかと思いました。
私のローカル開発版WordPressインスタンスと実際のバージョンの背後にあるコードは同期しています(本来あるべきことです)。問題は、これは "Jetpack"プラグインが(WordPress.comに接続できるライブブログなので)ライブバージョンでは動作しているが、ローカルのdevバージョンでは動作していないことを意味します。
つまり、機能はライブバージョン(「購読」サイドバーウィジェットなど)では利用できますが、ローカル開発バージョンでは利用できないため、同期が取れていません。
JetPack 2.2.1現在、ローカル開発/デバッグモードがあります。 http://jetpack.me/2013/03/28/jetpack-dev-mode-release/
つかいます:
define ('JETPACK_DEV_DEBUG', true);
wp-configで、機能するために接続を必要としないモジュールにアクセスする必要があります。
更新。v3.3以降、別のローカル開発トリガーが定義ではなくフィルターを介して追加されたため。
最新版はここにあります: http://jetpack.me/support/development-mode/
サイトのホスト名にピリオドがない場合、つまりlocalhostの場合、開発モードは自動的に有効になります。 mycooltestsite.localなどの別のURLを使用する場合は、JETPACK_DEV_DEBUG定数を定義する必要があります。
Jetpack_development_modeフィルターのおかげで、プラグインを介してJetpackの開発モードを有効にすることもできます。
add_filter( 'jetpack_development_mode', '__return_true' );
Jetpack v3.9では、サイトを本番環境ではなくステージングサイトとして強制的に強制するステージングモードフィルターもあります。 https://developer.jetpack.com/hooks/jetpack_is_staging_site/
add_filter( 'jetpack_is_staging_site', '__return_true' );
@TracyRottonによって提供されたリンクの中のメソッドは、Jetpack 2.0とWordPress 3.4.2以来動いていないようです。
すべてのデータベースフィールドを複製しても、接続されているようには機能しません。
OPの質問は開発環境と本番環境を同期させることに関するものなので、おそらく不可能です。
どのモジュールが動作するのか、どのモジュールが動作しないのかを詳細にテストしていませんが、Jetpackは/plugins/jetpack/jetpack.php
ファイルに次の変更を加えることで接続されていると信じ込むことができます。
クラスJetpack_Data
内で、一番最初の関数get_access_token
を次のように修正します。
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;
}
あるいは、オプションreturn true;
の中からコピーできるuser_tokens
の代わりにjetpack_options
を置くだけです。
PS: 最初のバージョン この答えの/ /は別のトリックを使った。ここでは、理論上、すべてを捕らえる1行の修正です...
アクティブ化されたインストールからローカルインストールにデータベースフィールド値をコピーすることによってJetPackをだますことが可能です。
JetPackが接続されているインストール(リモート)で、wp_options
で始まるoption_name
フィールドをjetpack_
テーブルで検索します。
jetpack_activated
jetpack_options
jetpack_nonce_{random_string}
jetpack_active_modules
これらのフィールドと値をローカルインストールデータベースにコピーします。
このプロセスの詳細については、以下を参照してください。 http://www.ravendevelopers.com/node/57
Brasofiloの最新のソリューションに触発されて、もっと簡単な方法があります、ちょうどjetpack.phpを開いて、
/**
* Is Jetpack active?
*/
public static function is_active() {
return (bool) Jetpack_Data::get_access_token( JETPACK_MASTER_USER );
}
そしてこれに置き換えます。
/**
* Is Jetpack active?
*/
public static function is_active() {
return true;
}
データベースで遊ぶよりもずっと簡単に思えるし、Jetpackバージョン2.1.1
とWordPressバージョン3.5
で私のために働きました
ただし、アクティブフラグをハードコーディングするよりも実際の方法で接続するほうが良いため、実際のサイトでプラグインを正常に機能させたい場合は、このファイルに対して無視規則を設定する必要があります。
full Jetpack機能が必要な場合は、開発環境を一般に問い合わせ可能にする必要があります。あなたのdevアドレスをサブドメインにすることでこれを設定できます。 sandbox.mysite.com、開発用サーバーが置かれているIPアドレスを指すようにそのDNSレコードを設定し、場合によってはポート80要求をユーザーのマシンに許可するようにルーター/ファイアウォールを構成します。
もう1つの選択肢は、ステージング環境を実行し、それをJetpack関連のものすべてに使用することです。ステージング環境には多くの利点があるため、それを設定することは価値のある投資になります。
jetpack_development_mode
フィルタjetpack_development_mode
フィルタについて言及したいだけです。
あなたは単に使用することができます:
add_filter( 'jetpack_development_mode', '__return_true' );
JetPack をローカルで実行する。
通常のトリックでwp-config.php
ファイルを修正する必要を回避するには、次のようにします。
define ('JETPACK_DEV_DEBUG', true);
あなたは今、この小さなプラグインを介してそれを制御することができます:
<?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' );
GitHub で確認できます。