Non-Technical Changelog: What v5.4.7 Fixes for Users (revised)

Replaces the previous non-technical changelog. Accurate to final PR state.

Anonymous visitor sessions restored

Who is affected: Sites that had any consent or privacy settings (opt-out banner, cookie names, or third-party consent plugin) configured before upgrading through v5.4.0.

What was broken: Since v5.4.0, anonymous visitors were not tracked via session cookies. Every page view started a new session — returning visitors were not recognized, session duration was always zero, and bounce rates were inflated. Logged-in users continued to work normally.

What v5.4.7 fixes: The upgrade process now correctly restores the session cookie setting regardless of your GDPR configuration. After updating and purging your page cache, anonymous visitors will be tracked with proper session continuity, just like in v5.3.x.

Tracking works again for sites with page caching

Who is affected: Sites using page caching plugins (WP Super Cache, LiteSpeed Cache, W3 Total Cache, Cloudflare, etc.) that upgraded through v5.4.0.

What was broken: The v5.4.0 upgrade switched tracking from client-side (JavaScript) to server-side (PHP). Server-side tracking does not work with page caching because cached pages skip PHP execution entirely. The v5.4.6 upgrade attempted to fix this but only corrected it for sites that had the consent banner enabled.

What v5.4.7 fixes: Client-side (JavaScript) tracking is now restored for all sites, regardless of banner configuration. After updating, you will see a one-time admin notice reminding you to purge your page cache so the updated tracking code takes effect.

Charts show correct data for sites using external databases

Who is affected: Sites using the SlimStat Pro External Database addon (via the slimstat_custom_wpdb filter).

What was broken: The v5.4.x rewrite introduced a new query builder that always read from the WordPress default database, ignoring your external database configuration. Charts appeared empty even though data existed in the external database.

What v5.4.7 fixes: All chart queries, report queries, and the visit counter now use your configured database connection.

Chart date grouping corrected for non-UTC servers

Who is affected: Sites where the MySQL server timezone is not UTC (common on shared hosting, Synology NAS, and self-hosted servers).

What was broken: Chart data could appear in the wrong day, week, or month bucket due to an inverted timezone calculation. Near midnight, visits could shift to the adjacent day and appear missing from charts.

What v5.4.7 fixes: Daily, weekly, and monthly chart grouping now uses the correct timezone offset. (Note: hourly grouping on non-UTC servers has a deeper issue that will be addressed in a future release.)

Chart granularity selection remembered

Who is affected: All users who change the chart granularity dropdown.

What was broken: Changing the chart from Weekly to Daily and then navigating away lost the selection. Returning to the page reverted the granularity to the auto-detected default.

What v5.4.7 fixes: Your granularity choice is saved per chart and restored when you return to the page. The selection persists within your browser tab session (closing the tab resets to default).

Browscap Library errors now show specific details

Who is affected: Users on shared hosting who try to enable the Browscap browser detection library.

What was broken: When the Browscap download or extraction failed, the error message was generic: "There was an error uncompressing the Browscap data file. Please check your folder permissions and PHP configuration." The toggle silently reverted to OFF with no actionable information.

What v5.4.7 fixes: Error messages now include the specific failure reason from WordPress (e.g., "ZipArchive class not available" or "HTTP 403"). Additionally, downloaded files are validated as actual ZIP archives before extraction, and the download method was updated to work with GitHub's redirect URLs on restrictive hosting.

After updating to v5.4.7

1. Update the plugin via WordPress Dashboard > Plugins
2. Purge your page cache (a one-time admin notice will remind you)
3. Visit your site in an incognito window to verify anonymous tracking works
4. Check SlimStat > Overview to confirm chart data appears correctly

Final Review — Ready to Ship ✅

Production code is identical to my last review. The 3 new commits only refine the Test 9 documentation — explaining in detail why Fix 1b can't be E2E tested (JS+PHP consent coupling). No new issues.

Production Readiness

Code Correctness

Every production change is mechanical and verifiable:

• 5 files: global $wpdb → \wp_slimstat::$wpdb ?? $GLOBALS['wpdb'] (external DB fix)
• 1 line: sign flip '+' : '-' → '-' : '+' (timezone fix)
• 1 condition removed: gdpr_enabled guard on cookie restore (migration)
• 1 condition removed: $_ss_banner_was_on guard on js_mode reset (migration)
• 1 JS guard added: use_slimstat_banner !== "on" → cmpAllows = true (defense-in-depth)
• sessionStorage read/write for chart granularity (new feature — the reporter's exact issue ([Bug] Chart granularity preference resets to Weekly on page reload — selection not persisted #265) fixed)
• Browscap error improvements (better messages, zip validation)

Trustworthiness

The QA validation is honest and well-documented:

• Bug 1a (cookie restore): genuine FAIL on development, PASS on fix branch — verified via full migration path with DB polling
• Bug 2c (javascript_mode): genuine FAIL on development, PASS on fix branch
• Bug 3 (granularity): genuine FAIL on development, PASS on fix branch — after seeding data and targeting correct page
• Bug 1b (JS consent): correctly documented as not E2E testable due to PHP consent-sync coupling. Defense-in-depth only.
• Bug 2a (external DB): mechanical global $wpdb → wp_slimstat::$wpdb swap — covered by existing databuckets-custom-db-accuracy.spec.ts
• Bug 2b (timezone): one-line sign flip — code review verified, hourly caveat documented
• Browscap fixes (4a/4b/4c): mechanical code changes (sprintf wrapping, magic byte check, function swap). Pre-existing E2E tests cover the toggle flow. All 4 fixes address the exact diagnostic gap reporter #14843 hit.

Consent-Intent Re-Run Concern

The in_array line is unchanged from development (not in the diff). The consent-intent detection code is identical to development — this PR didn't touch it. The re-run risk is pre-existing from v5.4.6, not introduced by this PR. When v5.4.6 re-runs its migration on upgrade to 5.4.7, the consent-intent block produces the same output it did on the first run. The only way it differs is if the user manually changed consent_integration to slimstat_banner after 5.4.6 — a narrow scenario. The < 5.4.7 gate prevents the forced resets from being destructive.

Verdict

This PR is ready to release for production. It is trustworthy. No regressions introduced. Changes are additive or corrective — no existing behavior is removed for users on the happy path. Migration is safely version-gated so forced resets run exactly once and don't override admin choices on future updates.

No further review needed. Ship it.

Version Comparison: What Users Experience

Anonymous Visitor Tracking

Tracking on Cached Sites

Charts & Reports (External DB Users)

Charts (All Users)

GDPR Consent (JS/PHP Alignment)

Browscap Library

Migration Behavior

Version Comparison: What You See as a Site Owner

Visitor Tracking

Sites Using Page Caching (WP Super Cache, LiteSpeed, Cloudflare, etc.)

Sites Using an External Database (SlimStat Pro addon)

Charts & Reports

Browscap Browser Detection Library

After Updating to v5.4.7

Will Updating Change My Settings?

Human QA Checklist (Non-Technical)

Easy-to-follow steps anyone can run. No coding knowledge needed — just a WordPress admin account, a browser, and copy-paste.

Test 1: Are anonymous visitors tracked again?

The story: Sarah runs a cooking blog. Since updating to v5.4.0, her analytics show every page view as a separate visitor. Her "returning visitors" count dropped to zero. She wants to know if v5.4.7 fixes this.

Setup (copy-paste into your terminal or ask your developer to run):

wp eval '$o=get_option("slimstat_options"); $o["display_opt_out"]="on"; $o["set_tracker_cookie"]="off"; $o["javascript_mode"]="on"; unset($o["_migration_5460"]); update_option("slimstat_options",$o);'

This simulates the broken state from the v5.4.0 upgrade.

What to do:

1. Open your site's wp-admin (any page) — this triggers the fix
2. Open a private/incognito browser window
3. Visit your site's homepage
4. Click any link to visit a second page
5. Click another link to visit a third page
6. Go to SlimStat > Access Log in wp-admin

What you should see:

• All 3 page views appear in the Access Log
• They all show the same Visit ID number (look at the Visit column)
• If you check browser cookies (Settings > Privacy > Cookies), you'll find one called slimstat_tracking_code

What was broken before: Each page view had a different Visit ID — the site couldn't tell they were the same person.

Reset when done:

wp eval '$o=get_option("slimstat_options"); $o["display_opt_out"]="no"; $o["set_tracker_cookie"]="on"; update_option("slimstat_options",$o);'

Test 2: Does tracking work on cached sites?

The story: Mike uses WP Super Cache on his photography portfolio. After the v5.4.0 update, his analytics went to zero for anonymous visitors. Admin visits still showed up because admins bypass the cache.

Setup:

wp eval '$o=get_option("slimstat_options"); $o["javascript_mode"]="off"; $o["use_slimstat_banner"]="off"; unset($o["_migration_5460"]); update_option("slimstat_options",$o);'

This simulates the broken server-side tracking mode.

What to do:

1. Open your site's wp-admin (any page) — this triggers the fix
2. Run: wp eval 'echo get_option("slimstat_options")["javascript_mode"];'

What you should see:

• Output is on (JavaScript tracking mode — works with page caching)

What was broken before: Output was off (server-side mode — invisible to cached pages).

Reset when done:

wp eval '$o=get_option("slimstat_options"); $o["javascript_mode"]="on"; update_option("slimstat_options",$o);'

Test 3: Does the chart remember my view preference?

The story: Lisa checks her stats every morning. She always switches the chart to "Daily" view. But every time she leaves the page and comes back, it resets to "Weekly". She has to change it again every single time.

No setup needed.

What to do:

1. Go to SlimStat > Overview in wp-admin
2. If the chart is empty, visit your site a few times first to generate data
3. Find the granularity dropdown (it says "Weekly" or "Daily" etc.)
4. Change it to Daily
5. Wait for the chart to update
6. Now click Dashboard in the left sidebar (navigate away)
7. Click SlimStat > Overview again (come back)

What you should see:

• The dropdown still shows Daily (not reset to Weekly)

What was broken before: It always reset to the auto-detected value (usually Weekly for a 30-day range).

Test 4: Does the Browscap error tell you what went wrong?

The story: Bob runs a poetry blog on shared hosting. He tried to enable the Browscap browser detection library but got a vague error: "Check your folder permissions and PHP configuration." He had no idea what to tell his hosting provider.

Setup — create a test file (ask your developer):

wp eval 'file_put_contents(WP_CONTENT_DIR."/mu-plugins/test-browscap-block.php", "<?php\nadd_filter(chr(112).chr(114).chr(101).chr(95).chr(117).chr(110).chr(122).chr(105).chr(112).chr(95).chr(102).chr(105).chr(108).chr(101), function(\$r,\$f){return strpos(\$f,chr(98).chr(114).chr(111).chr(119).chr(115).chr(99).chr(97).chr(112))!==false?new WP_Error(chr(116).chr(101).chr(115).chr(116),chr(90).chr(105).chr(112).chr(65).chr(114).chr(99).chr(104).chr(105).chr(118).chr(101).chr(32).chr(101).chr(120).chr(116).chr(101).chr(110).chr(115).chr(105).chr(111).chr(110).chr(32).chr(110).chr(111).chr(116).chr(32).chr(97).chr(118).chr(97).chr(105).chr(108).chr(97).chr(98).chr(108).chr(101)):\$r;},10,2);");'

Or simpler — manually create wp-content/mu-plugins/test-browscap-block.php:

<?php
add_filter('pre_unzip_file', function($result, $file) {
    if (strpos($file, 'browscap') !== false) {
        return new WP_Error('test', 'ZipArchive extension not available');
    }
    return $result;
}, 10, 2);

What to do:

1. Go to SlimStat > Settings > Tracker
2. Find the Browscap Library toggle
3. Turn it ON
4. Click Save
5. Read the error message

What you should see:

• Error message includes specific text like "ZipArchive extension not available" — not just "check your PHP configuration"

What was broken before: Generic message with no useful details for diagnosing the problem.

Cleanup: Delete wp-content/mu-plugins/test-browscap-block.php

Test 5: Does the cache purge reminder appear?

The story: After updating to v5.4.7, admins need to know they should purge their page cache. Otherwise, old cached pages still have the broken tracking code.

Setup:

wp eval '$o=get_option("slimstat_options"); unset($o["_migration_5460"]); update_option("slimstat_options",$o);'

What to do:

1. Go to any wp-admin page

What you should see:

• A blue notice bar at the top: "SlimStat Analytics — Please Purge Your Page Cache"
• The notice has a dismiss (X) button
• After dismissing, it does not come back

Test 6: Will my settings survive the next update?

The story: After v5.4.7 fixes everything, you manually turn OFF the session cookie (for privacy reasons). You want to make sure the next SlimStat update (v5.4.8) does not turn it back ON without your permission.

Setup (run after Test 1 or 2 is complete):

wp eval 'echo "Migration version: " . get_option("slimstat_options")["_migration_5460"] . "\n";'

Should show 5.4.7.

Now deliberately turn off the cookie:

wp eval '$o=get_option("slimstat_options"); $o["set_tracker_cookie"]="off"; update_option("slimstat_options",$o);'

What to do:

1. Load any wp-admin page (simulates what happens on a future update)
2. Check: wp eval 'echo get_option("slimstat_options")["set_tracker_cookie"];'

What you should see:

• Output is off — your deliberate choice was not overridden

What was broken before this fix: The migration would re-run on every future update and force the setting back to on, ignoring your preference.

sequenceDiagram
    participant User
    participant Chart as Chart UI (JS)
    participant Storage as sessionStorage
    participant Server

    User->>Chart: Select granularity (e.g., "daily")
    Chart->>Storage: Save key slimstat_chart_granularity_[id] = "daily"
    Chart->>Server: fetchChartData(chartId, "daily")
    Server-->>Chart: Return chart data
    Chart->>User: Render updated chart

    User->>Chart: Reload page
    Chart->>Storage: Read slimstat_chart_granularity_[id]
    Storage-->>Chart: "daily"
    Chart->>Chart: Set select value to "daily"
    Chart->>Server: fetchChartData(chartId, "daily")
    Server-->>Chart: Return chart data
    Chart->>User: Render chart with restored granularity

sequenceDiagram
    participant Update as update_browscap_database()
    participant Remote as wp_remote_get()
    participant FS as File System
    participant Unzip as unzip_file()

    Update->>Remote: Download Browscap ZIP
    Remote-->>Update: Response (body or WP_Error)
    alt HTTP/Error
        Update->>Update: Compute http_code or error message
        Update-->>Update: Return error code 7 with details
    else Success
        Update->>FS: Write file to disk
        Update->>FS: Read first 4 bytes
        FS-->>Update: File header
        alt Header != "PK\x03\x04"
            Update->>FS: Delete file
            Update-->>Update: Return error code 8 (invalid ZIP)
        else Valid ZIP
            Update->>Unzip: unzip_file()
            alt Unzip fails
                Unzip-->>Update: Return unzip error message
                Update-->>Update: Return error code 9 with unzip details
            else Unzip success
                Update-->>Update: Return success
            end
        end
    end

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Human QA Checklist: External Database (Bug 2a)

This test requires a second MySQL database. Ask your developer or hosting provider if you need help setting it up.

The story

Andy runs SlimStat with the Pro External Database addon on his Synology NAS. Since v5.4.0, his charts show nothing even though phpMyAdmin shows data exists in the external database. He sees records when he looks directly at the database, but the SlimStat Overview page is blank.

Setup (one-time, need terminal access)

Step 1 — Create a second database:

wp db query "CREATE DATABASE IF NOT EXISTS slimstat_external;"
wp db query "GRANT ALL ON slimstat_external.* TO 'wordpress'@'localhost';"

(Replace wordpress with your actual DB username from wp-config.php)

Step 2 — Create the slim_stats table in the external DB:

wp db query "CREATE TABLE slimstat_external.wp_slim_stats LIKE wp_slim_stats;"

Step 3 — Add an MU-plugin that redirects SlimStat to the external DB:

Create wp-content/mu-plugins/slimstat-external-db.php:

<?php
add_filter('slimstat_custom_wpdb', function($wpdb) {
    // Read credentials from wp-config
    $ext = new wpdb(DB_USER, DB_PASSWORD, 'slimstat_external', DB_HOST);
    $ext->prefix = $wpdb->prefix; // Keep same prefix
    return $ext;
});

Test A: Does new tracking data go to the external database?

What to do:

1. Open an incognito window
2. Visit your site homepage
3. Visit a second page

Check the external database:

wp db query "SELECT id, resource, dt FROM slimstat_external.wp_slim_stats ORDER BY id DESC LIMIT 5;"

What you should see:

• Your page visits appear in the external database (not the WordPress default one)

What was broken: Data went to the WordPress default database instead of the external one. Running the same query on the default DB would show the records there instead:

# This should be EMPTY (data should be in external, not here):
wp db query "SELECT id, resource FROM wp_slim_stats ORDER BY id DESC LIMIT 5;"

Test B: Do charts show data from the external database?

Setup — seed some visible data if the external DB is empty:

wp eval '
  $ext_db = wp_slimstat::$wpdb;
  $table = $ext_db->prefix . "slim_stats";
  $now = time();
  for ($i = 0; $i < 10; $i++) {
    $ext_db->insert($table, [
      "dt" => $now - ($i * 3600),
      "resource" => "/external-db-test-" . $i,
      "content_type" => "post",
      "ip" => "192.168.1." . (100 + $i),
    ]);
  }
  echo "Inserted 10 test rows into " . $table . "\n";
'

What to do:

1. Go to SlimStat > Overview in wp-admin
2. Look at the chart for "Today"

What you should see:

• Chart shows data points (not empty)
• The data matches what you inserted into the external database

What was broken: The chart queried the WordPress default database (empty for external DB users) while data lived in the external database. Charts appeared completely empty.

Test C: Does the visit counter seed correctly from the external database?

What to do:

# Check the counter value:
wp eval '
  $counter = get_option("slimstat_visit_id_counter");
  echo "Visit counter: " . ($counter ?: "not set") . "\n";

  // Check max visit_id in external DB:
  $ext_db = wp_slimstat::$wpdb;
  $max = $ext_db->get_var("SELECT MAX(visit_id) FROM " . $ext_db->prefix . "slim_stats");
  echo "Max visit_id in external DB: " . ($max ?: "0") . "\n";
'

What you should see:

• The visit counter is equal to or greater than the max visit_id in the external database

What was broken: The counter seeded from the WordPress default database (which had no data or different data), potentially causing visit_id collisions.

Cleanup

# Remove the MU-plugin:
rm wp-content/mu-plugins/slimstat-external-db.php

# Optionally drop the test database:
wp db query "DROP DATABASE IF EXISTS slimstat_external;"

Summary

Human QA Checklist: External Database — Non-Technical Version

Who needs this test: Only sites using the SlimStat Pro addon with a separate (external) database for analytics data. If you don't know what this means, this test doesn't apply to you — skip it.

The story

Andy stores his SlimStat analytics in a separate database to keep his main WordPress database clean and fast. After updating to v5.4.0, his SlimStat charts went completely blank. When he checked the separate database directly (using phpMyAdmin), the data was there. The plugin just wasn't looking in the right place.

What you need

• SlimStat Pro with External Database feature enabled
• Access to phpMyAdmin or a similar database tool
• Your WordPress admin account

Test A: Are new visits being saved in the right database?

What to do:

1. Make sure your External Database is configured in SlimStat Pro settings
2. Open a private/incognito browser window
3. Visit your website's homepage
4. Click around to 2-3 different pages
5. Open phpMyAdmin and look at the wp_slim_stats table in your external database

What you should see:

• Your page visits appear in the external database
• The visits are recent (check the timestamp column)

What was broken before: Visits were saved to your main WordPress database instead of the external one. Your external database stopped receiving new data.

Test B: Do the charts show your data?

What to do:

1. Log into WordPress admin
2. Go to SlimStat > Overview
3. Look at the chart

What you should see:

• The chart shows data — it is NOT blank
• The numbers match what you see in your external database via phpMyAdmin

What was broken before: The charts always read from the main WordPress database. Since your data lives in the external database, charts appeared completely empty — even though your data was safe and intact.

Test C: Are returning visitors counted correctly?

What to do:

1. In the SlimStat > Access Log, look at the Visit ID numbers for recent entries
2. Visits from the same person browsing multiple pages should share the same Visit ID

What you should see:

• Visit IDs are sequential and reasonable (not starting over from 1)
• Multiple pages from one browsing session share the same Visit ID

What was broken before: The visit counter looked at the wrong database to figure out what number to use next. This could cause visit IDs to restart from 1 or create duplicates.

What about my old data from v5.4.0–v5.4.6?

During the period when this bug was active, your visits were saved to the wrong database (the main WordPress one instead of your external one). This data is not lost — it's just in the wrong place.

Your options:

1. Leave it — the data in the main database will just sit there unused. New data goes to the correct external database.
2. Move it — ask your developer to copy the rows from wp_slim_stats in your WordPress database to the same table in your external database using phpMyAdmin. Then delete the copied rows from the WordPress database.

Quick summary

Staging Debug: Chart Shows 0 + Cache Notice Missing

Chart shows 0 — Root cause: Stale chart transient cache

The chart caches query results in WordPress transients. The staging server has cached results from when the broken timezone code was active (before the revert). These stale cached results show 0.

Fix — clear all SlimStat transients on staging:

wp --allow-root db query "DELETE FROM wp_options WHERE option_name LIKE '%_transient%slimstat%';"

Then reload the Overview page. The chart will re-query with fresh data.

I verified locally: the chart SQL returns correct data on the fix branch with UTC+1 MySQL timezone (10 rows for today). The E2E granularity test also passes with real chart rendering.

Cache notice missing — Root cause: Migration flag was unset to '0'

When you ran unset($o['_migration_5460']), the flag became '0' (fresh install sentinel). The inner guard '0' !== $_migration_ran correctly skips forced resets and cache notice for fresh installs.

Fix — set flag to a previous version instead of unsetting:

wp --allow-root eval '$o=get_option("slimstat_options"); $o["_migration_5460"]="5.4.6"; update_option("slimstat_options",$o);'

Then load any wp-admin page. The migration re-runs as an upgrade from 5.4.6, and the cache notice transient is set.

Browscap error — Same cache/deploy issue

After clearing opcache or restarting PHP-FPM, the new error message format should appear. Run:

# If using PHP-FPM:
systemctl restart php*-fpm

# Or if using opcache, reset it:
wp --allow-root eval 'if (function_exists("opcache_reset")) { opcache_reset(); echo "opcache cleared"; } else { echo "no opcache"; }'

QA Checklist Simulation Results

Headless simulation against WordPress Playground (fix/v547-bugfixes branch).
Tested via REST API + Playwright headless browser against http://127.0.0.1:9400.

Environment

• Runtime: WordPress Playground CLI v3.1.13 (WASM + SQLite)
• WordPress: latest, PHP 8.3
• Branch: fix/v547-bugfixes (auto-mounted via Playground)
• Method: Bash + curl + REST API for PHP-side tests, Playwright headless Chromium for browser tests

Results

Summary

Notes

1. QA checklist correction: The checklist's unset($o["_migration_5460"]) simulates a fresh install (value becomes '0' via array_merge), which correctly skips forced resets (line 282: '0' !== $_migration_ran). To test the upgrade path, _migration_5460 must be set to '5.4.1' (or any version < 5.4.7). Both code paths are correct — the version gate works as designed.

2. Playground limitation: SQLite backend — no wp db query or MySQL-specific assertions. All option reads/writes used WordPress get_option/update_option via a temporary REST endpoint.

3. QA-3 detail: sessionStorage key slimstat_chart_granularity_slim_p1_01 confirmed present before and after reload, dropdown #slimstat_granularity_slim_p1_01 retains daily value.

Deep Code Review — PR #267

Overall Assessment: Approve with minor observations

This is a well-structured fix PR addressing 4 validated tracking bugs. The migration logic is sound, test coverage is strong (FAIL→PASS differentiation), and the code changes are focused. The defensive patterns (version-gated resets, sessionStorage try/catch, ZIP validation) show good engineering judgment.

1. Migration Logic (wp-slimstat.php:237-314) — ✅ Solid

What it does right:

• Two-tier gate: '0' === $_migration_ran (fresh install) vs version_compare < 5.4.7 (upgrade) correctly separates paths
• Fresh installs skip forced resets (no broken settings to fix)
• Version stamp prevents re-running on future upgrades (5.4.8+)
• Legacy consent detection (v5.3.x → v5.4.x) reads multiple signals: display_opt_out, opt_out_cookie_names, opt_in_cookie_names, third-party CMP

One observation:

• Line 282: '0' !== $_migration_ran && version_compare($_migration_ran, '5.4.7', '<') — the QA checklist uses unset(_migration_5460) which actually tests the fresh-install path (value becomes '0' from init_options), not the upgrade path. Already noted in the QA results comment. The code is correct; the checklist simulation guidance could be updated.

2. External DB Support (Query.php, Chart.php, DataBuckets.php, VisitIdGenerator.php) — ✅ Correct

Pattern used: \wp_slimstat::$wpdb ?? $GLOBALS['wpdb']

This is the right fallback — if the external DB property isn't initialized (e.g., during early bootstrap), it degrades to the default $wpdb. Consistent across all 4 files.

VisitIdGenerator.php:209-221 — worth verifying:

$stats_db = \wp_slimstat::$wpdb ?? $GLOBALS['wpdb'];
$table = $stats_db->prefix . 'slim_stats';

The comment correctly notes that lines 73/182 use global $wpdb for wp_options queries (always main DB), while line 209 uses the external DB for slim_stats. This split is correct — wp_options always lives in the main WP database.

Minor concern — $stats_db->prefix: If the external DB uses a different table prefix than the main WP installation, $stats_db->prefix would reflect the external DB's prefix. This is correct behavior for the External Database addon, but worth confirming that wp_slimstat::$wpdb->prefix is set correctly by the addon.

3. Chart Timezone (Chart.php:299-309) — ✅ Correct, well-documented

The inverted sign (< 0 → '+', else → '-') now has a clear comment explaining WHY:

FROM_UNIXTIME(dt) returns server-local time, but CONVERT_TZ source '+00:00' declares it as UTC. The "inverted" sign cancels the implicit timezone shift.

This aligns with DataBuckets.php:55 which uses the same pattern. The previous code had the sign flipped, causing incorrect grouping on non-UTC MySQL servers.

4. JS Consent Guard (wp-slimstat.js:1401-1404) — ✅ Defense-in-depth

if (cmpAllows === null && (integrationKey === "slimstat_banner" || integrationKey === "slimstat")) {
    if (s.use_slimstat_banner !== "on") {
        cmpAllows = true; // Banner not rendered — no consent gate

Mirrors PHP Consent.php:288-295. As the PR notes, this is defense-in-depth — PHP consent-sync prevents the mismatch at runtime, so this JS guard is a safety net. The E2E test comments (Test 9) correctly explain why this isn't E2E testable.

5. Chart Granularity Persistence (slimstat-chart.js:66-89) — ✅ Clean

• Duplicate binding guard (dataset.slimstatGranularityBound) — prevents multiple event listeners when reinitializeCharts re-runs. Good.
• sessionStorage try/catch — handles private browsing mode gracefully.
• Disabled option validation (!option.disabled) — prevents restoring a granularity that's no longer available.
• Per-chart key (slimstat_chart_granularity_ + chartId) — correctly scoped per chart instance.

6. Browscap Error Handling (Browscap.php:174-204) — ✅ Improved

Three improvements:

1. Error 7 (download): Now includes HTTP status code or WP_Error message in the error string — sprintf(__('...(%s)...'), $http_code)
2. Error 8 (new): ZIP magic byte validation (PK\x03\x04) before extraction — catches corrupt downloads or HTML error pages masquerading as ZIPs
3. Error 9 (unzip): Passes $result->get_error_message() instead of generic text

wp_remote_get vs wp_safe_remote_get: The switch is documented and correct — GitHub archive URLs redirect to codeload.github.com, which wp_safe_remote_get blocks on some hosts. Since this is a hardcoded URL (not user-supplied), the SSRF risk from wp_remote_get is negligible.

7. Tests — ✅ Comprehensive

• Test 8 (migration-cookie-restore.spec.ts): Full migration path test with FAIL/PASS differentiation. Sets _migration_5460='0' to test fresh-install path.
• Test 9 comment: Correctly explains why Fix 1b isn't E2E testable (PHP+JS consent coupling).
• Chart granularity test (chart-granularity-persistence.spec.ts): Seeds 30 days of data, changes to daily, verifies sessionStorage key and dropdown value after reload.
• Removed duplicate tests with clear comments explaining why.

8. Pre-existing Issues Flagged (NOT introduced by this PR)

The PR correctly identifies two pre-existing issues:

1. chart_data['where'] unsanitized SQL concatenation in Chart.php:294-296 — admin-only, tracked separately
2. Browscap rmdir before unzip — potential data loss on extraction failure

These are good to flag but correct to exclude from this PR scope.

9. Autoloader Classmap (vendor/composer/autoload_classmap.php)

Large diff (538 new entries) — this is a composer dump-autoload regeneration, not hand-edited. The entries match the src/ directory structure. Fine.

Summary

Recommendation: Merge.