feat: make analytics opt-in via a settings checkbox

[tomasstark]

This PR makes analytics opt-in: a new "Enable analytics" checkbox on the plugin settings screen, off by default. Only when checked does the plugin pass analyticsEnabled: true to the SDK or register the batch-buffer delivery machinery.

Context

Analytics was implicitly always on: whenever CAP ran, Plugin::init() passed a hardcoded analyticsEnabled: true to the SDK, and (with the WP queue enabled) buffered and delivered events. Merchants had no control. This PR gives them the switch and defaults it to off.

Key Changes

• Settings — new option supertab_connect_analytics_enabled with is_analytics_enabled() / set_analytics_enabled(), mirroring the CAP pair; cleared by Settings::delete() and on uninstall.
• Settings screen — "Enable analytics" checkbox inside the CAP section (hidden with it when CAP is off). Saved on the same form branch as CAP; reset to off when the API key is cleared.
• Plugin::init() — the misnamed $analytics_enabled local (it actually gated bot protection) is renamed $bot_protection_active; a real $analytics_enabled = $bot_protection_active && is_analytics_enabled() now gates the batch-buffer dispatcher, and the SDK receives the derived flag instead of hardcoded true. With analytics off there is no queue registration, no flush schedule, and the SDK builds its noop transport. CAP behavior is unchanged by the toggle.
• Status self-report — eventReporting in /.well-known/supertab/status now also requires the opt-in, so the backend prober sees the truth on analytics-off sites (found in review; enforcement reporting unchanged).

Verification

• composer test — 116/116 passing (213 assertions); lint, phpcs (WordPress-VIP-Go), phpstan (level 5) clean.
• wp-env smoke: default (option absent) → GPTBot request buffers no analytics row; option on → row buffered as before; Playwright round-trip of the settings screen (checkbox renders in the CAP section, saves both ways, hides with the CAP toggle); status endpoint reports eventReporting: false until opted in.

[Copilot]

Pull request overview

This PR makes Supertab Connect analytics explicitly opt-in by adding a persisted “Enable analytics” setting (default off) and wiring it through initialization and the status self-report so analytics batching/dispatch and SDK analytics transport only activate after the merchant opts in.

Changes:

• Add a new stored setting (supertab_connect_analytics_enabled) with getter/setter, and ensure it’s removed on delete/uninstall.
• Add an “Enable analytics” checkbox to the settings UI and save/reset it alongside CAP settings.
• Gate SDK analyticsEnabled, queue dispatcher registration, and /.well-known/supertab/status eventReporting on both CAP being active and analytics opt-in.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
uninstall.php	Deletes the new analytics opt-in option during uninstall cleanup.
tests/StatusHandlerTest.php	Updates and adds tests to ensure eventReporting requires analytics opt-in.
tests/SettingsTest.php	Adds tests for analytics opt-in default, persistence, and deletion behavior.
templates/settings.php	Adds the “Enable analytics” checkbox within the CAP section of the settings UI.
src/class-status-handler.php	Updates status payload to report eventReporting only when opted in.
src/class-settings.php	Adds OPTION_ANALYTICS_ENABLED plus is_analytics_enabled() / set_analytics_enabled(), and deletes the option in delete().
src/class-plugin.php	Derives analytics_enabled from CAP-active + opt-in, and passes it to the SDK; only registers analytics dispatcher when enabled.
src/admin/class-settings-page.php	Reads/saves analytics_enabled from form submission and passes it into the template data.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

🎉 This PR is included in version 1.3.0-beta.11 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀