Jetpack läuft lokal [geschlossen]

Ich frage mich, ob jemand einen einfachen Weg kennt, um das zu umgehen.

Der Code hinter meiner lokalen Dev-Version einer WordPress-Instanz und die Live-Version sind synchron (wie sie sein sollten). Das Problem ist, dass das "Jetpack" -Plugin an der Live-Version arbeitet (da es sich um ein Live-Blog handelt, das eine Verbindung zu WordPress.com herstellen kann), jedoch nicht an der lokalen Dev-Version.

Dies bedeutet, dass Funktionen in der Live-Version verfügbar sind (wie im Sidebar-Widget "Abonnieren"), jedoch nicht in der lokalen Dev-Version, sodass sie nicht synchron sind.

Ab JetPack 2.2.1 gibt es jetzt einen lokalen Entwicklungs- / Debug-Modus. http://jetpack.me/2013/03/28/jetpack-dev-mode-release/

verwenden:

define ('JETPACK_DEV_DEBUG', true);

in deiner wp-config und du solltest Zugriff auf alle Module haben, die keine Verbindung benötigen, um zu funktionieren.

Update, da ab v3.3 ein weiterer lokaler Entwicklungstrigger per Filter anstelle von define hinzugefügt wurde.

Das Neueste ist jetzt hier: http://jetpack.me/support/development-mode/

Der Entwicklungsmodus wird automatisch aktiviert, wenn der Hostname Ihrer Site keinen Punkt enthält, dh localhost. Wenn Sie eine andere URL verwenden, z. B. mycooltestsite.local oder so, müssen Sie die JETPACK_DEV_DEBUG-Konstante definieren.

Dank des Filters jetpack_development_mode können Sie den Entwicklungsmodus von Jetpack auch über ein Plugin aktivieren:

add_filter( 'jetpack_development_mode', '__return_true' );

Seit Jetpack v3.9 gibt es auch einen Staging-Modus-Filter, mit dem eine Site nicht mehr als Produktions-Site, sondern als Staging-Site erkannt wird: https://developer.jetpack.com/hooks/jetpack_is_staging_site/

add_filter( 'jetpack_is_staging_site', '__return_true' );

Die Methode in dem von @TracyRotton bereitgestellten Link scheint seit Jetpack 2.0 und WordPress 3.4.2 nicht mehr zu funktionieren.

Selbst wenn alle Datenbankfelder repliziert werden, handelt es sich nicht um eine Verbindung.

Da es sich bei der OP-Frage um die Synchronisierung einer Entwicklungs- und einer Produktionsumgebung handelt, ist dies möglicherweise nicht möglich.

Ich habe nicht ausführlich getestet, welche Module funktionieren und welche nicht, aber Jetpack kann zu der Annahme verleitet werden, dass es verbunden ist, und die folgende Änderung in der Datei vorgenommen /plugins/jetpack/jetpack.php.

Jetpack_DataÄndern Sie in der Klasse die allererste Funktion get_access_tokenwie folgt:

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;
            }

Oder setzen Sie einfach ein return true;anstelle des, das user_tokenswir aus der Option heraus kopieren können jetpack_options.

_{PS: Die erste Version dieser Antwort verwendete einen anderen Trick. Hier ist es eine einzeilige Modifikation, die theoretisch alles erfasst ...}

JetPack kann ausgetrickst werden, indem die Datenbankfeldwerte aus einer aktivierten Installation in Ihre lokale Installation kopiert werden.

Durchsuchen Sie bei einer Installation (remote) mit verbundenem JetPack die wp_optionsTabelle nach option_nameFeldern, die mit beginnen jetpack_, z.

• jetpack_activated
• jetpack_options
• jetpack_nonce_{random_string}
• jetpack_active_modules

Kopieren Sie diese Felder und Werte in Ihre lokale Installationsdatenbank.

Weitere Informationen zu diesem Vorgang finden Sie unter: http://www.ravendevelopers.com/node/57

Inspiriert von der neuesten Lösung von brasofilo gibt es noch einen einfacheren Weg, einfach jetpack.php öffnen und suchen

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

und ersetzen Sie mit diesem:

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

Scheint viel einfacher zu sein als mit der Datenbank zu spielen und hat bei mir mit der Jetpack-Version 2.1.1und der WordPress-Version gearbeitet3.5

Sie sollten jedoch eine Ignorierregel für diese Datei oder ähnliches festlegen, wenn das Plugin auf der Live-Site weiterhin einwandfrei funktionieren soll, da es besser ist, auf echte Weise verbunden zu sein, als das aktive Flag fest zu codieren.

Wenn Sie die volle Jetpack-Funktionalität wünschen , muss Ihre Entwicklungsumgebung öffentlich abfragbar sein. Sie können dies einrichten, indem Sie Ihre Entwickleradresse zu einer Unterdomäne machen, z. B. sandbox.mysite.com, diesen DNS-Eintrag so einstellen, dass er auf die IP-Adresse verweist, unter der sich Ihr Entwicklungsserver befindet, und möglicherweise Ihren Router / Ihre Firewall so konfigurieren, dass Port 80-Anforderungen durchgelassen werden zu Ihrer Maschine.

Eine andere Möglichkeit besteht darin, eine Staging-Umgebung auszuführen und diese für alles zu verwenden, was mit Jetpack zu tun hat. Staging-Umgebungen haben viele Vorteile, daher wäre es eine lohnende Investition, sie trotzdem einzurichten.

Der jetpack_development_modeFilter:

Ich möchte nur den jetpack_development_modeFilter erwähnen .

Sie können einfach verwenden:

add_filter( 'jetpack_development_mode', '__return_true' );

laufen JetPack vor Ort.

Ein kleines Plugin:

So vermeiden Sie, dass Sie die wp-config.phpDatei mit dem üblichen Trick ändern müssen :

define ('JETPACK_DEV_DEBUG', true);

Sie können es jetzt über dieses kleine Plugin steuern:

<?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' );

Sie können es auf GitHub ausprobieren .

Das Update unter http://ravendevelopers.com/node/57 funktioniert möglicherweise nicht mit Jetpack-Versionen über 2.x. Wenn es mit Version 2.x nicht funktioniert, versuchen Sie zunächst, Jetpack auf Ihrer Live-Site wie (example.com) zu installieren, verbinden Sie es mit wordpress.com und importieren Sie dann die Einstellungen von Ihrer Live-Site auf Ihren localhost / example, der sein muss das gleiche (Einstellungen, die von example.com importiert wurden, funktionieren möglicherweise nicht mit localhost / example2). Stellen Sie sicher, dass die importierten Einstellungen für dieselbe Site auf Ihrem lokalen Host gelten.

Hmm, scheint, als könnte deine Antwort vereinfacht werden. Nehmen Sie diese Änderung an und ich stimme Ihrer Antwort zu.

Da is_active () true zurückgibt, müssen Sie nur eine Zeile in admin_page () ändern:

1.Ändern Sie den Wert $is_user_connectedintrue

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