Many of you will be familiar with the Jetpack plugin. I use Jetpack’s Stats module — previously the WordPress.com Stats plugin — to record and display this site’s page views.
Several Jetpack modules including the Stats module require a connection to an account at WordPress.com where your self-hosted WordPress site is given a unique ID. This unique ID is associated with the site’s domain name. If you change an already connected site’s domain name and reconnect it to your WordPress.com account it is given a new unique ID.
Herein lies the source of a problem I had recently which resulted in the apparent loss of all this site’s stats.
I keep a local copy of this site populated with data imported from the production database. The local domain name is of course different. I use imac.to as a virtual host running under the local server environment. Recently, I accidentally connected this local site through Jetpack to my WordPress.com account and thought no more of it until later when I noticed the stats for the production site appeared only for the last few days effectively losing over 3 years worth of stats.
A little further investigation and I noticed that I had two domains listed at WordPress.com: www.tech-otaku.com and imac.to, each with a different ID. However many times I disconnected/reconnected www.tech-otaku.com through Jetpack it always pointed to the new ID associated with the imac.to domain name.
While awaiting an answer to this problem from either the WordPress.org and WordPress.com forums I found I was able to force Jetpack to connect to the original ID by editing the jetpack_options field of the wp_options table. The jetpack_options field contains a string which represents an array where each element is an option.
This is the more easily readable version with the blog’s unique ID highlighted:
Array ( [version] => 1.2.2:1332311041 [old_version] => 1.2.2:1332311041 [id] => 12345678 [public] => 1 [fallback_no_verify_ssl_certs] => 0 [time_diff] => 0 [blog_token] => Jpy8pOFqud16UpZvYo7Qe7FWHXDFEphWUyxiyBubmiOwLUTYQCzcJDIlXorqIkRfh [user_tokens] => Array (  => ppgKB6WIRhMUBS7mCl93eZjvz4Xjmy6L6vuvKLeRVa6Rihm9oVi9ifjvATd48XyjAhR ) [master_user] => 4 )
However, using phpMyAdmin or similar MySQL client the contents of the jetpack_options field looks like this:
The part of this string that refers to the blog’s unique ID is s:2:"id";i:12345678;. Changing the new unique ID of 12345678 to the blog’s original unique ID resulted in the recovery of all the missing stats. However, when subsequently disconnecting/reconnecting Jetpack the unique ID reverted back to the new one.
It took some cunning by the folks at WordPress.com to ultimately fix the issue and they had some advice on how to avoid the issue in the future. Jetpack now has a Development Mode which when enabled doesn’t allow Jetpack to connect to WordPress.com. To enable Development Mode on a localhost installation simply add the following highlighted lines to the WordPress wp-config.php file:
/** The Database Collate type. Don't change this if in doubt. */ define('DB_COLLATE', ''); /** Enable Jetpack Development Mode */ define('JETPACK_DEV_DEBUG', true); /**#@+
As a footnote, the site’s unique ID is also stored in the stats_options field of the wp_options table. These are the configuration options for Jetpack’s Stats module and the site’s unique ID — known here as blog_id — appears unaffected by the issue described above. It is produced here merely for information.
Array ( [admin_bar] => 1 [roles] => Array (  => administrator ) [count_roles] => Array ( ) [blog_id] => 12345678 [do_not_track] => 1 [hide_smile] => 1 [host] => www.tech-otaku.com [path] => / [wp_me] => 1 [footer] => 1 [dismiss_jetpack_nag] => [version] => 9 [error] => [key_check] => [api_key] => abcdef123456 )