Statpress error notices
Lihua reports that the MySQL logs are being filled with errors like this:
2016-08-08 10:04:01 2484 [Warning] WSREP: RBR event 1 Query apply warning: 1, 2418946 2016-08-08 10:04:01 2484 [Warning] WSREP: Ignoring error for TO isolated action: source: 979aa79c-5b14-11e6-a676-562fdf30f4a1 version: 3 local: 0 state: APPLYING flags: 65 conn_id: 53642 trx_id: -1 seqnos (l: 23380, g: 2418946, s: 2418945, d: 2418945, ts: 259621867740026) 2016-08-08 10:04:22 2484 [ERROR] Slave SQL: Error 'Unknown column 'realpost' in 'field list'' on query. Default database: 'commons_wp'. Query: 'INSERT INTO `wp_695_statpress` (`date`, `time`, `ip`, `urlrequested`, `agent`, `referrer`, `search`, `os`, `browser`, `searchengine`, `spider`, `feed`, `user`, `timestamp`, `language`, `country`, `realpost`, `post_title`) VALUES (20160808, '09:04:22', '184.108.40.206', '', '', '', '', '', '', '', '', '', NULL, 1470647062, '', '', 1, '[Page]: Home')', Error_code: 1054
Ray, I have a vague memory of debugging this in the past. Do you recall? It looks like statpress is basically abandoned, so we can probably fix it right in the plugin.
#1 Updated by Raymond Hoh about 3 years ago
The plugin dev on the wp.org forums suggests deactivating and reactivating the plugin to update the DB schema upgrade.
I manually deactivating and reactivated StatPress Visitors for site ID 695 and there was the following notice:
Settings activated: Statpress Vistors database updated
Hopefully that fixes the problem. Not sure why this doesn't happen transparently.
Is the error message posted by Lihua only specific to site ID 695? Or are there more sites affected by this?
#2 Updated by Boone Gorges about 3 years ago
Thanks, Ray. I don't have access to the full logs, but I'm assuming it's not limited to that one site.
Does Statpress set a flag after the update is complete? Can you write a script that I can run (wp eval-file) at deployment to loop through all sites using statpress and run the upgrade routine where necessary? Or perhaps there can be some automated detection of whether the upgrade has taken place, with the update being run if the DB is found to be out of date? (Not sure if the latter is safe.)
#3 Updated by Raymond Hoh about 3 years ago
Here's a quick script for wp-cli.
Couldn't use StatPress' built-in DB function since it uses a constant to set the DB table prefix.
$site_ids variable, I installed the Plugin Activation Status plugin (not in Git), activated it on the development server and copied the site IDs. Dev server should use the most recent DB data, so we should be safe here right?
#4 Updated by Boone Gorges about 3 years ago
- Status changed from New to Resolved
- Target version set to Not tracked
For the $site_ids variable, I installed the Plugin Activation Status plugin (not in Git), activated it on the development server and copied the site IDs. Dev server should use the most recent DB data, so we should be safe here right?
Dev server uses DB data from the last sync, which was on Friday of last week. Close enough :-D
I just ran the routine and it appears to have worked. At least, it succeeded in changing the schema on some out-of-date tables. I assume this means that the notices will no longer appear. Let's mark resolved.