Wondered if anyone knew an easy way around this.
The code behind my local dev version of a WordPress instance and the live version are in sync (as they should be). Problem is this means the “Jetpack” plugin is working on the live version (since it’s a live blog that can connect to WordPress.com) but not on the local dev version.
This means functionality is available on the live version (like the “Subscribe” sidebar widget) but not on the local dev version, thus they’re out of sync.
As of JetPack 2.2.1 there is now a local development/debug mode.
http://jetpack.me/2013/03/28/jetpack-dev-mode-release/
use:
in your wp-config and you should have access to any modules that don’t require a connection to function.
Update, since around v3.3 another local development trigger was added via filter instead of define.
Latest is now here: http://jetpack.me/support/development-mode/
As of Jetpack v3.9 there is also now a staging mode filter that forces a site to be recongized as a staging site rather than production: https://developer.jetpack.com/hooks/jetpack_is_staging_site/
The method in the link provided by @TracyRotton seems not to be working since Jetpack 2.0 and WordPress 3.4.2.
Even replicating all database fields, it doesn’t act as connected.
As the OP question is about syncing a development and a production environments, maybe it is not possible.
I haven’t tested in-depth which modules work and which not, but Jetpack can be tricked into believing it is connected making the following modification in the file
/plugins/jetpack/jetpack.php
.Inside the class
Jetpack_Data
, modify the very first functionget_access_token
like:Or simply put a
return true;
instead of theuser_tokens
that we can copy from inside the optionjetpack_options
.PS: the first version of this answer used another trick. Here, it is a one-line modification that catches all, in theory…
It is possible to trick JetPack by copying the database field values from an activated install into your local install.
On an install (remote) with JetPack connected search the
wp_options
table foroption_name
fields beginning withjetpack_
, such as:jetpack_activated
jetpack_options
jetpack_nonce_{random_string}
jetpack_active_modules
Copy these fields and values into your local installs database.
For more detail on this process see: http://www.ravendevelopers.com/node/57
Inspired by brasofilo’s latest solution, there’s even an easier way, just open jetpack.php, search for
and replace with this:
Seems to be alot easier than playing with the database and worked for me with Jetpack version
2.1.1
and WordPress version3.5
But you should set an ignore rule for this file or something like that if you want to keep the plugin working fine on the live site because it’s better to be connected by the real way than hardcoding the active flag.
If you want full Jetpack functionality, your development environment will need to be publicly queryable. You can set this up by making your dev address a subdomain, e.g. sandbox.mysite.com, setting that DNS record to point to the IP address where your development server is located, and possibly configuring your router/firewall to allow port 80 requests through to your machine.
Another option is to run a staging environment, and use that for anything Jetpack-related. Staging environments have many advantages, so it would be a worthwhile investment to set that up anyway.
The
jetpack_development_mode
filter:I just want to mention the
jetpack_development_mode
filter.You can simply use:
to run JetPack locally.
A tiny plugin:
To avoid having to modify the
wp-config.php
file with the usual trick:you can now control it via this tiny plugin:
You can check it out on GitHub.
The fix on http://ravendevelopers.com/node/57 MIGHT not work with Jetpack versions above 2.x. If it doesn’t work on version 2.x try to install Jetpack on your live site first like (example.com), connect it to wordpress.com and then import the settings from your live site to your localhost/example which must be the same (settings imported from example.com might not work with localhost/example2). Thing is what you do on your live site, make sure the imported settings are for the same site on your localhost.
Hmm, seems like your answer can be simplified. Adopt this change and I’ll up-vote your answer.
Since is_active() returns true, you only need to change one line in admin_page():
1.
change the value$is_user_connected
totrue