Upgrading Burst Statistics
This document covers the upgrade process for Burst Statistics, including automatic database migrations, available hooks, and breaking changes developers should be aware of.
Overview
When Burst Statistics detects a version change (by comparing burst-current-version in the options table against BURST_VERSION), it automatically:
- Fires the
burst_upgrade_beforeaction. - Runs any version-specific PHP upgrade routines (e.g. scheduling DB migrations).
- Re-initialises database tables via
burst_table_init. - Regenerates the frontend JS file.
- Schedules a
burst_upgrade_iterationcron event (60 seconds out) to begin background DB migrations. - Fires the
burst_upgrade_afteraction. - Saves the new version to
burst-current-version.
Database migrations run through the burst_upgrade_iteration worker and are re-scheduled roughly once per minute while work remains. They are also nudged forward whenever an authorized user visits the Burst dashboard (?page=burst). Progress is shown as a non-dismissible notice in the Burst admin UI.
Burst runs the upgrade iteration on cron hooks. If cron is not running for some reason, there is a fallback: when the dashboard is visited, the upgrade will also fire, if any upgrades are still left.
Upgrade progress
While a migration is in progress, a notice is shown in the Burst dashboard:
"An upgrade is running in the background, and is currently at X%. For large databases this process may take a while. Your data will be tracked as usual."
Progress is stored per-migration as WordPress transients (burst_progress_<upgrade_name>) and is visible without page refresh via the tasks/warnings system.
Preventing upgrades
Define the constant BURST_NO_UPGRADE as true before the plugin loads to completely disable all DB upgrade processing:
// In wp-config.php or a must-use plugin:
define( 'BURST_NO_UPGRADE', true );
This prevents all schema migrations from running. Use only in controlled environments (e.g. read-only replicas, staging clones) where you do not want the database modified.
Hooks
burst_upgrade_before
Fires immediately before any upgrade logic runs, after the new DB tables are installed. Receives the previous version string.
Parameters:
| Parameter | Type | Description |
|---|---|---|
$prev_version | string|false | The previously installed version, or false on fresh installs |
Example:
Show code
add_action( 'burst_upgrade_before', function( $prev_version ) {
if ( $prev_version && version_compare( $prev_version, '3.3.0', '<' ) ) {
// Run your own pre-upgrade logic here.
}
} );
burst_upgrade_after
Fires after all upgrade routines have completed and the version option has been updated.
Parameters:
| Parameter | Type | Description |
|---|---|---|
$prev_version | string|false | The previously installed version, or false on fresh installs |
Example:
add_action( 'burst_upgrade_after', function( $prev_version ) {
// Flush your own caches after Burst upgrades.
} );
burst_db_upgrades
Filter the full list of database upgrade tasks. Pro add-ons use this filter to register additional migrations. Tasks with a pro_ prefix are treated as pro-only and processed via burst_upgrade_pro_iteration after all free tasks complete.
Parameters:
| Parameter | Type | Description |
|---|---|---|
$upgrades | array | Associative array of version => string[] pairs, where each string is a migration task identifier |
Example:
Show code
add_filter( 'burst_db_upgrades', function( array $upgrades ): array {
$upgrades['1.0.0'] = [ 'pro_my_custom_migration' ];
return $upgrades;
} );
Task identifiers prefixed with pro_ are run via burst_upgrade_pro_iteration, not the standard burst_upgrade_iteration cron event. Free task identifiers must not start with pro_.
burst_upgrade_iteration (WP-Cron action)
Scheduled single cron event that drives free migration batches. Each run processes one pending migration and reschedules itself (1-minute interval) until all free migrations complete.
burst_upgrade_pro_iteration (WP-Cron action)
Fires after all free migrations complete. Pro add-ons hook into this action to run their own batched DB migrations.
Example:
add_action( 'burst_upgrade_pro_iteration', function() {
// Process your pro migration batch.
} );
burst_tasks
Used internally to inject an upgrade-progress warning into the Burst tasks/notices system. See DB_Upgrade::add_progress_notice().
Database migrations by version
All migrations are idempotent — each is tracked by a WordPress option (burst_db_upgrade_<name>). The option is deleted when the migration completes successfully.
v1.4.2.1
| Migration | Description |
|---|---|
bounces | Corrects bounce flags: clears bounce on sessions with ≥ 2 pageviews and clears bounce where time_on_page > 5000. |
goals_remove_columns | Drops the event and action columns from burst_goals. |
v1.5.2
| Migration | Description |
|---|---|
goals_set_conversion_metric | Sets conversion_metric = 'pageviews' on all goals where the field is NULL or empty. |
v1.5.3
| Migration | Description |
|---|---|
empty_referrer_when_current_domain | Nullifies referrer values in burst_statistics that begin with the site's own home URL. |
strip_domain_names_from_entire_page_url | Strips the home URL prefix from the entire_page_url column. |
drop_user_agent | Drops the user_agent column from burst_statistics. |
Also removes the legacy burst-statistics-endpoint.php file from the web root if present.
v1.7.0
Migrates string-based device/browser/platform/OS values to normalised lookup tables (burst_browsers, burst_browser_versions, burst_platforms, burst_devices).
| Migration | Description |
|---|---|
create_lookup_tables | Populates lookup tables with distinct values from burst_statistics. |
init_lookup_ids | Sets sentinel value 999999 on all *_id columns to track migration progress. |
upgrade_lookup_tables | Batch-updates *_id columns in burst_statistics by joining against lookup tables (100 000 rows per batch). |
upgrade_lookup_tables_drop_columns | Drops the now-redundant browser, browser_version, device_resolution, device, and platform text columns from burst_statistics. |
drop_page_id_column | Drops the old page_id integer column from burst_statistics. |
v1.7.1
| Migration | Description |
|---|---|
rename_entire_page_url_column | Changes the parameters column type to TEXT. |
drop_path_from_parameters_column | Extracts query strings from entire_page_url into parameters, then drops entire_page_url (batched at 50 000 rows). |
v2.0.4
| Migration | Description |
|---|---|
fix_missing_session_ids | No-op cleanup (option deleted immediately; logic was removed). |
clean_orphaned_session_ids | No-op cleanup (option deleted immediately; logic was removed). |
v2.2.3
Removes duplicate rows from burst_goal_statistics to prepare for a UNIQUE constraint (runs inline during check_upgrade, not as a background task).
v2.2.6
| Migration | Description |
|---|---|
add_page_ids | Backfills page_id and page_type columns in burst_statistics by matching stored page URLs against WordPress posts (5 posts per batch). |
v3.1.4
| Migration | Description |
|---|---|
move_referrers_to_sessions | Migrates normalised referrer values (domain only, no protocol, no www.) from the first pageview of each session in burst_statistics to the referrer column in burst_sessions (100 000 sessions per batch). |
v3.1.4.1
| Migration | Description |
|---|---|
fix_trailing_slash_on_referrers | Removes trailing slashes from referrers in burst_sessions that were recorded after 2024-12-21. |
v3.2.0
| Migration | Description |
|---|---|
move_reports_to_new_tables | Migrates the legacy email_reports_mailinglist option into the new burst_reports table structure. Existing entries are grouped by frequency and saved as Report objects. |
v3.3.0
:::caution Breaking change
move_columns_to_sessions drops browser_id, browser_version_id, platform_id, device_id, first_time_visit, and bounce from burst_statistics. These columns are added to burst_sessions and populated before the old columns are removed. See Breaking Changes below.
:::
| Migration | Description |
|---|---|
move_columns_to_sessions | Moves browser_id, browser_version_id, platform_id, device_id, first_time_visit, and bounce from burst_statistics to burst_sessions. Rows in burst_statistics are processed in batches (100 000 rows); sentinel value 9999 on browser_id marks a row as processed. Once all rows are processed, the six columns are dropped from burst_statistics. The burst_sessions table gains corresponding columns (browser_id INT NOT NULL DEFAULT 0, browser_version_id INT NOT NULL DEFAULT 0, platform_id INT NOT NULL DEFAULT 0, device_id INT NOT NULL DEFAULT 0, first_time_visit TINYINT NOT NULL DEFAULT 0, bounce TINYINT DEFAULT 1) with indexes. Triggered for all sites upgrading from versions prior to 3.3.0-beta1. |
v3.4.0
In v3.4.0 the SQL query fingerprinting logic in Query_Data changed: timestamps are now replaced with placeholders so equivalent queries hash to the same value. The burst_query_stats table is truncated on upgrade so that previously stored hashes do not collide with the new fingerprints. A new date_range_days column is also added to burst_query_stats to track the date-range granularity of stored queries.
The Pro geo_ip_database_type option is also corrected on upgrade: previous installs that wrote the option under the wrong key (burst_geo_ip_database_type) are migrated to the canonical geo_ip_database_type key, and the default is set to city.
| Routine | Description |
|---|---|
truncate_query_stats | Truncates the burst_query_stats table when upgrading from a version below 3.4.0, because SQL normalization changed (timestamps are now replaced with placeholders) and old hashes are no longer comparable. Runs inline during check_upgrade, not as a background task. |
reinstall_rest_api_optimizer | Reinstalls the REST API optimizer when upgrading from a version below 3.5.0 so the new get_action/ecommerce/<action> REST endpoint is recognised. Runs inline during check_upgrade. |
geo_ip_database_type_key_fix (Pro) | Corrects the geo_ip_database_type option key (previously written as burst_geo_ip_database_type) and defaults it to city. Runs inline during the Pro DB upgrade routine. |
v3.4.2
Sites upgrading from a version below 3.4.2 will have burst_activation_time set to the oldest statistic timestamp (or, if no statistics exist, to the current time) so downstream age-based logic has a stable anchor.
| Routine | Description |
|---|---|
backfill_activation_time | Sets burst_activation_time from the oldest row in burst_statistics when upgrading from a version below 3.4.2 and the option is not already populated. Runs inline during check_upgrade. |
v3.4.2.1
Pro - BusinessAvailable in the Business tier
The pro_order_foreign_keys migration only runs on sites with the WooCommerce funnel analytics Pro tables installed.
| Migration | Description |
|---|---|
pro_order_foreign_keys (Pro) | Converts burst_orders.statistic_id and burst_order_items.burst_order_id from VARCHAR(255) to INT UNSIGNED NOT NULL so joins between ecommerce tables use indexed integer comparisons. Scheduled when upgrading from a version below 3.4.2.1 and processed via burst_upgrade_pro_iteration. |
Breaking changes
v3.3.0 — columns removed from burst_statistics
:::caution Breaking change
In v3.3.0 the browser_id, browser_version_id, platform_id, device_id, first_time_visit, and bounce columns are migrated to burst_sessions and then dropped from burst_statistics. At the same time, burst_sessions gains these six columns. Any custom queries or third-party code that reads these columns directly from burst_statistics will break after this migration completes.
:::
Migrate affected queries to join burst_sessions on session_id:
Show code
global $wpdb;
$results = $wpdb->get_results(
"SELECT st.page_url, se.browser_id, se.bounce
FROM {$wpdb->prefix}burst_statistics st
INNER JOIN {$wpdb->prefix}burst_sessions se ON st.session_id = se.ID"
);
v3.2.0 — email reports storage format changed
The email_reports_mailinglist option is removed during the move_reports_to_new_tables migration. Code that reads or writes this option directly will no longer work after upgrading to v3.2.0.
v1.7.0 — browser/platform/device columns removed from burst_statistics
The plain-text browser, browser_version, device_resolution, device, and platform columns are dropped from burst_statistics after the lookup-table migration completes. Custom queries must join the corresponding lookup tables (burst_browsers, burst_browser_versions, burst_devices, burst_platforms) instead.
v1.5.3 — user_agent column removed
The user_agent column is permanently removed from burst_statistics when upgrading from versions prior to 1.5.3.
Developer notes
Checking upgrade progress programmatically
$db_upgrade = new \Burst\Admin\DB_Upgrade\DB_Upgrade();
$percentage = $db_upgrade->get_progress( 'all', 'all' ); // 0–100
$is_done = $db_upgrade->progress_complete(); // bool
Option naming convention
Each migration task <name> is tracked by a WordPress option:
burst_db_upgrade_<name>
The option is set to true when a migration is scheduled and deleted (delete_option) when it completes. You can check any specific migration:
$pending = (bool) get_option( 'burst_db_upgrade_move_columns_to_sessions' );
Registering pro migrations
Pro add-ons register their own migrations via the burst_db_upgrades filter (task names must begin with pro_) and process them on the burst_upgrade_pro_iteration action:
Show code
// Register the migration.
add_filter( 'burst_db_upgrades', function( array $upgrades ): array {
$upgrades['1.0.0'][] = 'pro_my_feature_migration';
return $upgrades;
} );
// Schedule the migration flag during the standard upgrade hook.
add_action( 'burst_upgrade_after', function( $prev_version ) {
if ( $prev_version && version_compare( $prev_version, '1.0.0', '<' ) ) {
update_option( 'burst_db_upgrade_pro_my_feature_migration', true, false );
}
} );
// Process the migration batch.
add_action( 'burst_upgrade_pro_iteration', function() {
if ( ! get_option( 'burst_db_upgrade_pro_my_feature_migration' ) ) {
return;
}
// ... run your migration ...
delete_option( 'burst_db_upgrade_pro_my_feature_migration' );
} );