Запуск Jetpack локально

Метод, предоставленный по ссылке @TracyRotton, похоже, не работает начиная с Jetpack 2.0 и WordPress 3.4.2.

Даже при полном копировании всех полей базы данных, соединение не активируется.

Поскольку исходный вопрос касается синхронизации среды разработки и рабочей среды, возможно, это невозможно.

Я не тестировал глубоко, какие модули работают, а какие нет, но 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'; // <---обход
        if ( $user_id ) {
            if ( !$tokens = Jetpack::get_option( 'user_tokens' ) ) {
                return false;
            }

Или просто вставьте return true; вместо user_tokens, который можно скопировать из опции jetpack_options.

_{Примечание: в первой версии этого ответа использовался другой обходной путь. Здесь представлено однострочное изменение, которое, в теории, охватывает все случаи...}

Можно обмануть 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, найдите

/**
* Активен ли Jetpack?
*/
public static function is_active() {
    return (bool) Jetpack_Data::get_access_token( JETPACK_MASTER_USER );
}

и замените на это:

/**
* Активен ли Jetpack?
*/
public static function is_active() {
    return true;
}

Это кажется намного проще, чем возиться с базой данных, и сработало для меня с Jetpack версии 2.1.1 и WordPress версии 3.5.

Но вам следует установить правило игнорирования для этого файла или что-то подобное, если вы хотите, чтобы плагин продолжал корректно работать на рабочем сайте, потому что лучше подключаться реальным способом, чем жестко прописывать флаг активности.

Если вам нужна полная функциональность Jetpack, ваша среда разработки должна быть доступна для публичных запросов. Это можно настроить, создав субдомен для вашего dev-адреса, например sandbox.mysite.com, указав DNS-запись на IP-адрес вашего сервера разработки и, возможно, настроив маршрутизатор/брандмауэр для разрешения запросов через порт 80 на вашу машину.

Другой вариант — использовать staging-окружение для всех задач, связанных с Jetpack. Staging-окружения имеют множество преимуществ, поэтому их настройка в любом случае будет полезным вложением.

Фильтр 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: Запуск JetPack локально
 * 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 МОЖЕТ не работать с версиями Jetpack выше 2.x. Если оно не работает на версии 2.x, попробуйте сначала установить Jetpack на ваш рабочий сайт (например, example.com), подключить его к wordpress.com, а затем импортировать настройки с рабочего сайта на ваш локальный хост/example, который должен быть идентичным (настройки, импортированные с example.com, могут не работать с localhost/example2). Суть в том, что действия на рабочем сайте должны соответствовать настройкам, импортируемым на локальный хост.

Хм, похоже, ваш ответ можно упростить. Примите это изменение, и я проголосую за ваш ответ.

Поскольку is_active() возвращает true, вам нужно изменить только одну строку в admin_page():

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);
    // ...функция продолжается