ローカルで実行中のJetpack [終了]

誰かがこれについて簡単な方法を知っていたら疑問に思いました。

WordPressインスタンスのローカル開発バージョンとライブバージョンの背後にあるコードは、同期している必要があります。問題は、これは「Jetpack」プラグインが（WordPress.comに接続できるライブブログであるため）ライブバージョンで動作しているが、ローカルの開発バージョンでは動作していないことを意味します。

つまり、機能はライブバージョン（「Subscribe」サイドバーウィジェットなど）で使用できますが、ローカルの開発バージョンでは使用できないため、同期していません。

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_namejetpack_

• 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

ただし、アクティブフラグをハードコーディングするよりも実際の方法で接続する方がよいため、ライブサイトでプラグインを正常に動作させたい場合は、このファイルまたはそのようなものに無視ルールを設定する必要があります

あなたがしたい場合は、完全な Jetpackの機能を、開発環境では、公的照会可能になる必要があります。これを設定するには、devアドレスをサブドメイン（sandbox.mysite.comなど）に設定し、そのDNSレコードを開発サーバーが配置されているIPアドレスを指すように設定します。あなたのマシンに。

別のオプションは、ステージング環境を実行し、それを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で確認できます。

http://ravendevelopers.com/node/57 MIGHT の修正は、2.xより上のJetpackバージョンでは機能しません。バージョン2.xで動作しない場合は、まず（example.com）のようにライブサイトにJetpackをインストールし、wordpress.comに接続してから、ライブサイトからlocalhost / exampleに設定をインポートします。同じ（example.comからインポートされた設定はlocalhost / example2では機能しない可能性があります）。実際のサイトで行うことは、インポートした設定がローカルホスト上の同じサイト用であることを確認してください。

うーん、あなたの答えは簡単にできるようです。この変更を採用すると、あなたの回答に賛成票を投じます。

is_active（）はtrueを返すため、admin_page（）の1行を変更するだけで済みます。

1.値$is_user_connectedを変更する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