=== NoticePilot – Remote Campaign Hub for WordPress Plugin & Theme Authors ===
Contributors: spiderdevs, muaz404
Tags: admin notices, notifications, announcements, a/b testing, plugin analytics
Requires at least: 5.8
Tested up to: 7.0.2
Requires PHP: 7.4
Stable tag: 1.5.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Self-hosted remote campaign hub for plugin and theme authors. Push notices to unlimited sites via a PHP SDK — no SaaS needed.

== Description ==

**NoticePilot is not another admin notice plugin.** It is a **self-hosted remote campaign distribution platform** built specifically for WordPress plugin and theme authors.

If you maintain a WordPress plugin or theme that runs on hundreds or thousands of sites, you need a reliable way to push announcements, update prompts, sale banners, or deprecation warnings to your users — without shipping a new plugin release for every message. NoticePilot solves this with a **hub-to-remote architecture**: you manage campaigns centrally on your own site, and a lightweight PHP SDK bundled in your plugin automatically fetches and displays them on every remote installation.

= Who Is This For? =

NoticePilot is purpose-built for **WordPress plugin and theme developers** who need to communicate with their users across multiple remote installations from a single, self-hosted dashboard. It is **not** a tool for managing or suppressing admin notices on a single site — there are many plugins already serving that purpose.

= What Makes It Different? =

Unlike most admin-notice plugins, NoticePilot is a complete developer communication platform:

* **Hub-to-Remote Architecture** — One central dashboard pushes campaigns to unlimited remote WordPress sites via a REST API. No third-party SaaS, no external dependencies — everything runs on your own WordPress installation.
* **Single-File PHP SDK** — Bundle one PHP file into your plugin or theme. Initialize with a single line of code. The SDK handles fetching, caching, rendering, and dismissal automatically.
* **Privacy-First Analytics** — Track impressions, clicks, and dismissals across all remote sites without collecting personal data. Remote site URLs are MD5-hashed before storage — no IP addresses, usernames, or cookies are ever saved.
* **Audience Targeting** — Deliver the right message to the right users by targeting campaigns based on plan type (free or pro), plugin version (with comparison operators like `<`, `>`, `=`), and WordPress user roles.
* **Campaign Scheduling** — Set start and end dates for time-sensitive campaigns. Expired campaigns are auto-disabled via WP-Cron — no manual clean-up required.
* **Rich HTML Support** — Write full HTML including inline CSS, `<style>` blocks, and custom layouts. Your content renders exactly as authored on every remote site.
* **Smart Dismissal Handling** — Users who dismiss a notice won't see it again for a configurable duration. Dismissals are stored locally on the remote site using a FIFO strategy, keeping only the 20 most recent dismissed IDs.
* **Scalable Analytics Engine** — Raw events roll up into daily summaries via an hourly WP-Cron job with automatic pruning. Built for scale — no unbounded table growth.

= How It Works =

1. **Create a Product** — Each product represents a plugin, theme, or service you maintain. NoticePilot generates a unique REST API endpoint for it automatically.
2. **Add Campaigns** — Write rich HTML content, set optional scheduling and audience-targeting rules, then enable the campaign.
3. **Integrate the SDK** — Download the single-file PHP SDK from your product card, bundle it with your plugin or theme, and initialize it with one line of code. The SDK polls your hub on a configurable schedule and renders active campaigns as WordPress admin notices on remote sites.
4. **Track Performance** — Monitor impressions, clicks, dismissals, and click-through rates from the analytics dashboard. Drill down by product or by individual campaign with daily breakdowns.

= Real-World Use Cases =

* **Plugin authors:** Push update prompts, deprecation warnings, or feature announcements to all users of your plugin — without shipping a new release.
* **Theme authors:** Announce seasonal sales, new theme versions, or compatibility updates directly inside the WordPress admin on every active installation.
* **Agency developers:** Broadcast maintenance windows, policy changes, or onboarding tips across all client sites from a single central hub.
* **Freemium plugins:** Show upgrade prompts exclusively to free-plan users while displaying different messaging to pro users — all without code changes on the remote site.

= A Self-Hosted Alternative =

Plugin authors today face a difficult choice: build a custom notice system from scratch for every product (duplicating effort), or rely on third-party SaaS platforms (adding external dependencies and data-privacy concerns). NoticePilot offers a **self-hosted, privacy-respecting, zero-external-dependency alternative** that runs entirely on your own WordPress installation — giving you full control over your data and your users' experience.

== Installation ==

= Installing the Hub Plugin =

1. Upload the `noticepilot` folder to the `/wp-content/plugins/` directory of your **central management site**.
2. Activate the plugin through the **Plugins** menu in WordPress.
3. Navigate to **NoticePilot** in your WordPress admin sidebar to begin creating products and campaigns.

= Integrating the SDK With Your Plugin or Theme =

Once you have created a product and added campaigns on your hub site, integrate the SDK into your own plugin or theme to start displaying notices on remote sites:

1. In the NoticePilot dashboard, click the **How To Integrate** button on your product card.
2. Click **Download SDK** to download the `class-remote-notice-client.php` file.
3. Copy the file into your plugin or theme (e.g., into an `includes/` subdirectory).
4. Add the following initialization code to your plugin's main file or your theme's `functions.php`:

`
// Load the NoticePilot SDK.
require_once __DIR__ . '/includes/class-remote-notice-client.php';

add_action( 'plugins_loaded', function() {
    Noticepilot_Remote_Notice_Client::init( 'your-product-slug', [
        'api_url'          => 'https://your-hub-site.com/wp-json/noticepilot/v1/content/your-product-slug',
        'schedule'         => 'daily',
        'capability'       => 'manage_options',
        'dismiss_duration' => WEEK_IN_SECONDS,
        'plugin_version'   => '1.0.0',   // enables version targeting
        'is_pro'           => false,     // enables free/pro plan targeting
    ] );
} );
`

Replace `your-product-slug` with the slug shown on your NoticePilot product card, and `your-hub-site.com` with the domain of the site running the NoticePilot hub plugin.

That single call is all you need to start displaying notices. Every other capability — snooze, frequency caps, screen placement, analytics consent, conversion goals, smart triggers, and deactivation feedback — is optional. Each is documented in the **SDK Integration Guide** section below, and the dashboard's **How To Integrate → Add features** panel gives you a copy-paste snippet for every one, pre-filled with your product slug.

Once initialized, the SDK automatically handles fetching, caching, rendering, and dismissing notices — no additional code required.

== SDK Integration Guide ==

This section explains the complete end-to-end workflow for wiring the NoticePilot SDK into your own plugin or theme. Follow these steps in order — they cover everything from creating your first product on the hub through to verifying notices appear on remote sites.

= Step 1 — Set Up the Hub =

Install and activate the NoticePilot plugin on your **central management site** (not on the sites of your customers). This is the one WordPress installation that will act as your private campaign server.

Once activated, navigate to **NoticePilot** in the WordPress admin sidebar. This is where all products and campaigns live.

= Step 2 — Create a Product =

A "Product" is the bridge between the hub and one of your plugins or themes.

1. Click **+ Add New Product**.
2. Enter the name of your plugin or theme (e.g. `Super SEO Form`). NoticePilot automatically generates a URL-safe slug (e.g. `super-seo-form`). This slug is the identifier your SDK will use when polling for campaigns.
3. Toggle **Enable this site** to ON.
4. Click **Save Site**.

Each product gets its own REST API endpoint in the form:

`https://your-hub-site.com/wp-json/noticepilot/v1/content/your-product-slug`

= Step 3 — Add a Campaign =

With your product created, you can add one or more campaigns (notices) to it.

1. Click **+ Add Content** on your product card.
2. Fill in the fields:
   - **Content Title** — Internal reference only (e.g. `Black Friday Sale 2025`).
   - **HTML Content** — The full HTML notice rendered on remote sites. Supports inline styles, `<style>` blocks, and any custom layout.
   - **Enable this offer** — Toggle ON to make the campaign live immediately.
   - **Start / End Date (Optional)** — Schedule the campaign for a specific window. Expired campaigns are auto-disabled by WP-Cron.
3. Click **Save Content**.

You can attach multiple campaigns to a single product. All active and in-schedule campaigns are returned together when the SDK polls the endpoint.

= Step 4 — Download the SDK =

1. On your product card, click the **How To Integrate** button.
2. Click **Download SDK** to download `class-remote-notice-client.php`.

Alternatively, copy the file directly from the `sdk/` directory of the NoticePilot plugin.

= Step 5 — Bundle the SDK Into Your Plugin or Theme =

Copy `class-remote-notice-client.php` into your plugin or theme directory. A recommended location is an `includes/` subdirectory:

`your-plugin/
├── your-plugin.php
└── includes/
    └── class-remote-notice-client.php`

The SDK is fully self-contained — no Composer, no external libraries, no additional files required.

= Step 6 — Initialize the SDK =

Add the following code to your plugin's main PHP file (or to your theme's `functions.php`). Replace the placeholder values with your own product slug and hub URL:

`// Load the NoticePilot remote notice SDK.
require_once __DIR__ . '/includes/class-remote-notice-client.php';

add_action( 'plugins_loaded', function() {
    Noticepilot_Remote_Notice_Client::init( 'your-product-slug', [
        'api_url'          => 'https://your-hub-site.com/wp-json/noticepilot/v1/content/your-product-slug',
        'schedule'         => 'daily',
        'capability'       => 'manage_options',
        'dismiss_duration' => WEEK_IN_SECONDS,
    ] );
} );`

**Copy the exact URL from your product card's "How To Integrate" panel** to avoid typos — the slug in `api_url` must match the product slug precisely.

= SDK Configuration Options =

Only `api_url` is required — everything else is optional:

* `api_url` *(required)* — The full REST URL to your product's content endpoint on the hub. Find it in the **How To Integrate** panel on the product card.
* `schedule` *(optional)* — How often the remote site polls the hub for new campaigns. Accepted values: `hourly`, `twicedaily`, or `daily`. Default: `daily`. Use `hourly` for time-sensitive campaigns; use `daily` to reduce server load.
* `capability` *(optional)* — The WordPress capability a user must have to see notices. Default: `manage_options` (administrators only). Change to `edit_posts` to show notices to editors as well.
* `dismiss_duration` *(optional)* — How long (in seconds) a dismissed notice stays hidden before it can reappear. Default: `WEEK_IN_SECONDS`. Pass `0` to make dismissals permanent for that campaign ID.
* `snooze_duration` *(optional)* — Cooldown (in seconds) for the "Remind me later" link on snooze-enabled campaigns. Default: `WEEK_IN_SECONDS`.
* `max_notices` *(optional)* — Maximum number of notices shown at once (frequency cap). Default: `3`.
* `screen_ids` *(optional)* — Array of admin screen IDs where "plugin screens only" campaigns may appear. Default: `[]` (site-wide). Find a screen's ID via `get_current_screen()->id`.
* `require_consent` *(optional)* — When `true`, no analytics beacon fires until you call `grant_consent()`. Default: `false`. Recommended for plugins distributed on WordPress.org (guideline 7).
* `plugin_version` *(optional)* — Your plugin's current version string. Enables version targeting on the hub (`<`, `<=`, `=`, `>=`, `>`).
* `is_pro` *(optional)* — Whether your Pro edition is active. Enables free/pro plan targeting. Default: `false`.
* `deactivation_feedback` *(optional)* — When `true`, shows an optional, skippable deactivation survey (recorded when NoticePilot Pro is active on the hub). Default: `false`.
* `plugin_file` *(optional)* — Your plugin's basename (e.g. `my-plugin/my-plugin.php`), required for the deactivation prompt.

= Step 7 — Target Your Audience =

Targeting is evaluated **on the remote site** — you supply the context through `init()` options and the SDK shows a campaign only when the campaign's rules match. There is no third argument to `init()`; targeting is driven by these config keys:

* **Plan (free/pro)** — pass `'is_pro' => true` when your Pro edition is active. Campaigns set to "free only" or "pro only" on the hub are matched against this.
* **Plugin version** — pass `'plugin_version' => '2.3.1'`. Campaigns with a version rule are matched using `version_compare()`.
* **User role** — no option needed; the SDK reads the current user's roles automatically and matches them against the campaign's role rules.

`Noticepilot_Remote_Notice_Client::init( 'your-product-slug', [
    'api_url'        => 'https://your-hub-site.com/wp-json/noticepilot/v1/content/your-product-slug',
    'plugin_version' => MY_PLUGIN_VERSION,   // e.g. '2.3.1'
    'is_pro'         => my_plugin_is_pro(),  // true when your Pro edition is active
] );`

Campaigns with no targeting rules are shown to every eligible user.

= Step 8 — Add Optional Features =

Each capability below is opt-in. Merge the extra options into your `init()` call, or add the method calls where they belong in your own plugin. Copy-paste versions, pre-filled with your product slug, are under **How To Integrate → Add features** on your product card.

**Analytics consent (WordPress.org guideline 7).** Keep all beacons off until the user opts in, then wire consent to your own opt-in UI (a settings checkbox, an activation screen, etc.). Notices still display; only tracking is gated.

`Noticepilot_Remote_Notice_Client::init( 'your-product-slug', [
    'api_url'         => 'https://your-hub-site.com/wp-json/noticepilot/v1/content/your-product-slug',
    'require_consent' => true,
] );

// When the user opts in / out:
Noticepilot_Remote_Notice_Client::grant_consent( 'your-product-slug' );
Noticepilot_Remote_Notice_Client::revoke_consent( 'your-product-slug' );`

**Snooze & frequency caps.** `max_notices` caps how many notices show at once; `snooze_duration` sets the "Remind me later" cooldown for snooze-enabled campaigns:

`'max_notices'     => 2,
'snooze_duration' => WEEK_IN_SECONDS,`

**Screen placement.** Restrict "plugin screens only" campaigns to specific admin screens:

`'screen_ids' => [ 'dashboard', 'toplevel_page_your-plugin' ],`

**Conversion goals (Pro).** Call `track_goal()` when a user completes a valuable action. The SDK attributes it (last-shown, within the attribution window) to the campaign/variant that site saw, so the hub can report real conversion rate — not just clicks. It respects the same consent gate as other beacons.

`// e.g. right after the user activates your Pro license:
Noticepilot_Remote_Notice_Client::track_goal( 'your-product-slug', 'upgraded_to_pro' );`

**Smart triggers (Pro).** Report a usage count your plugin already tracks (you count it; the SDK just stores the number). On the hub, author a milestone rule — e.g. show the campaign once the metric reaches 100 — and the cached campaign appears the moment it crosses.

`Noticepilot_Remote_Notice_Client::set_metric( 'your-product-slug', 'forms_created', $count );`

**Deactivation feedback (Pro).** Show an optional, skippable survey when the user deactivates your plugin (it never blocks deactivation; responses appear in the hub's Feedback panel):

`Noticepilot_Remote_Notice_Client::init( 'your-product-slug', [
    'api_url'               => 'https://your-hub-site.com/wp-json/noticepilot/v1/content/your-product-slug',
    'deactivation_feedback' => true,
    'plugin_file'           => 'your-plugin/your-plugin.php',
] );`

= Step 9 — Verify the Integration =

1. **Trigger the first fetch manually:** After adding the initialization code, log in to a remote WordPress admin that has your plugin active. The SDK registers a WP-Cron event on first load (`plugins_loaded`). To force an immediate fetch without waiting for the cron, use WP-CLI on the remote site:

`wp cron event run noticepilot_rnc_fetch_content_your-product-slug`

2. **Check the stored contents option:** In the remote site's database, look for the option `noticepilot_rnc_your-product-slug_contents`. It should contain the JSON-encoded campaign data returned by the hub.

3. **View the notice in the admin:** Navigate to any admin page on the remote site. Active campaigns appear as standard WordPress admin notices at the top of the page. Each notice has a dismiss (✕) button.

4. **Check the analytics:** Go back to your hub site → **NoticePilot → Analytics**. After a page load on the remote site triggers a beacon, you should see an impression logged against your campaign within the hour (after the next rollup cron runs), or immediately after clicking **↻ Refresh Data** on the Analytics page.

= How the SDK Works at Runtime =

Understanding what the SDK does automatically helps you diagnose issues:

1. **Cron registration** — On `plugins_loaded`, the SDK schedules a repeating WP-Cron event (e.g. `noticepilot_rnc_fetch_content_your-product-slug`) on the remote site if one is not already registered.
2. **Remote fetch** — When the cron fires, the SDK sends a `GET` request to the `api_url` endpoint on your hub. The hub checks each campaign's `enabled` flag and schedule, then returns the active ones as JSON.
3. **Local caching** — The fetched campaigns are stored in the remote site's `wp_options` table (key: `noticepilot_rnc_your-product-slug_contents`). Notices are rendered from this local cache on every page load — no live HTTP request is made on each admin page.
4. **Rendering** — On `admin_notices`, the SDK outputs each cached campaign as a standard `.notice` div. Campaign HTML is filtered through `wp_kses()` before output to prevent script injection.
5. **Analytics beacons** — Immediately on render, and on link click or dismiss, the SDK fires a `navigator.sendBeacon()` call to the hub's analytics tracking endpoint. This is fire-and-forget and does not block the page. When `require_consent` is enabled, no beacon fires until `grant_consent()` has been called for the product.
6. **Dismissal** — When a user clicks the ✕ button, an AJAX call stores the campaign ID in `noticepilot_rnc_your-product-slug_dismissed_ids`. Only the 20 most recent IDs are kept. After `dismiss_duration` seconds, the campaign can reappear.
7. **Cron cleanup** — On plugin deactivation (your plugin), the SDK's cron event is automatically unscheduled.

= Developer Notes =

* **Namespace safety** — The SDK class is named `Noticepilot_Remote_Notice_Client`. It checks `class_exists()` before declaring itself, so it is safe to bundle in multiple plugins on the same site without conflicts.
* **No singleton collision** — Each `init()` call is keyed by its product slug. Multiple plugins on the same remote site can each run their own SDK instance independently.
* **Hub availability** — The SDK caches results locally, so if your hub server is temporarily unreachable during a cron run, the last successfully fetched campaigns continue to display until the next successful poll.
* **Detecting the hub** — In your plugin's own code, you can detect whether the hub is installed on the current site with `class_exists( '\NoticePilot\Core' )`. This is useful for offering hub-specific admin links in a bundled UI.
* **Forcing a re-fetch** — To trigger the fetch action programmatically (e.g. after a plugin update), use: `do_action( 'noticepilot_rnc_fetch_content_your-product-slug' );`
* **Available methods** — Beyond `init()`: `enable()` / `disable()` / `is_disabled()` control whether the client runs; `trigger_fetch()` polls the hub immediately; `clear_all()` clears cached campaigns and local state; `grant_consent()` / `revoke_consent()` / `has_consent()` manage analytics consent; and (with NoticePilot Pro on the hub) `track_goal()` records a conversion and `set_metric()` reports a usage value for smart triggers. Every method takes your product slug as its first argument.

== Frequently Asked Questions ==

= How is NoticePilot different from other admin notice plugins? =

Most admin-notice plugins manage, dismiss, or suppress notices on a single WordPress installation. NoticePilot serves an entirely different purpose — it is a **remote campaign distribution platform** for plugin and theme authors. You create and manage campaigns on a central hub site, and a lightweight SDK embedded in your plugin automatically fetches and displays those campaigns across hundreds or thousands of remote installations. It also includes campaign analytics, audience targeting, and scheduling — capabilities not found in typical notice-management plugins.

= Can I use custom HTML and CSS in my campaigns? =

Yes. Campaign content supports full HTML, including inline styles, `<style>` blocks, and custom layouts. Your content renders exactly as written on every remote site.

= Is it safe to store and serve raw HTML campaign content? =

Yes, within its intended use case. Campaign content can only be created by administrators who have the `manage_options` capability, and all form submissions are protected by WordPress nonce verification. HTML is stored without additional sanitization intentionally, to preserve inline CSS and custom styling. NoticePilot is a developer tool designed for trusted authors — not for end-user-generated content.

= Does the plugin collect personal data from remote sites? =

No. Analytics events are recorded using fire-and-forget `navigator.sendBeacon()` calls. Before any data is written to the database, remote site URLs are MD5-hashed server-side. No IP addresses, usernames, cookies, user agents, or other personally identifiable information is ever collected or stored.

= Can I target campaigns to specific users or plan types? =

Yes. Each campaign supports three independent targeting dimensions:

* **Plan type** — Show to all users, free-plan users only, or pro-plan users only.
* **Plugin version** — Target by version number using comparison operators (`<`, `>`, `=`, `<=`, `>=`).
* **WordPress user role** — Restrict visibility to specific roles such as Administrator, Editor, and others.

Leave all targeting fields blank to display the campaign to every eligible user.

= What happens when a user dismisses a notice? =

The notice is hidden for the duration configured via the `dismiss_duration` SDK option. Dismissals are recorded locally on the remote site in `wp_options` using a FIFO cleanup strategy that retains only the 20 most recent dismissed campaign IDs. During each fetch cycle, the SDK also automatically prunes stale IDs for campaigns that no longer exist on the hub.

= Does installing NoticePilot add notices to my own site's dashboard? =

No. NoticePilot does not inject any admin notices into the WordPress dashboard of the site where it is installed. It provides only a management interface under its own admin menu page. Campaign notices are displayed exclusively on **remote sites** — and only when a plugin or theme author explicitly integrates the SDK.

== Screenshots ==

1. **NoticePilot Dashboard** – Centralized hub to manage products, launch campaigns, and configure SDK integrations.
2. **Campaign Analytics** – Track performance, impressions, clicks, and conversion rates across all remote installations.
3. **SDK Integration** – Simple, step-by-step guide to download and initialize the remote notice client SDK.
4. **Add Campaign** – Create HTML campaigns with customized start dates, end dates, and targeting rules.

== Changelog ==

= 1.5.0 =
* **Rebuilt:** The entire admin UI is now a **React + JSX** app (built with @wordpress/scripts) — hero, stats, product cards, and all dialogs are component-based, with modals and form fields as reusable components. Same look (reuses the existing styles); smoother, no full-page reloads.
* **New:** Authenticated REST CRUD (`/noticepilot/v1/admin/…`) replaces the old form-POST handlers for every product/campaign action (create, edit, delete, duplicate, import).
* **New:** Add-on extension point — the campaign modal exposes the `noticepilot.campaignFieldGroups` JS filter (@wordpress/hooks), so NoticePilot Pro injects its A/B, snooze, and trigger fields as React components. Server-side, add-ons still receive their data via the `noticepilot_campaign_data` filter.
* **Removed:** The legacy jQuery admin script and PHP-rendered modals.
* All existing features preserved: templates, live preview, targeting, scheduling, notice styles, placement, import/export, "See More", and the SDK integration guide + download.

= 1.4.1 =
* **Developer:** Added range-aware analytics query methods to the data layer — `Analytics::get_range_totals()`, `get_product_daily()`, and optional date bounds on `get_product_summary()` — powering the enhanced Pro analytics dashboard (date ranges, trend deltas, activity chart). Backward compatible; no schema change.

= 1.4.0 =
* **Change:** The Analytics screen has moved entirely to **NoticePilot Pro**, rebuilt as a modern React dashboard (charts, per-campaign detail, A/B variant comparison, conversions, CSV export). The free hub keeps the analytics data layer (event recording + hourly rollup) and the product/campaign stat ribbon.
* **New:** Opt-in geo (data layer) — a `country_code` column and a cached, filterable resolver (`noticepilot_geoip_lookup`, defaulting to ip-api.com, with CDN-header fast-path). Collected only when the hub owner enables it in Pro's analytics settings and Pro is active (`noticepilot_geo_collection` filter). No per-visitor data.
* **Improvement:** Analytics schema upgraded to 1.2.0 (adds `country_code`); migrates automatically on update.
* **Removed:** The legacy jQuery analytics page, its script, and its CSS.

= 1.3.0 =
* **Change:** A/B testing, conversion goals, smart triggers, and per-campaign snooze are now **NoticePilot Pro** features. The free hub keeps campaign push, scheduling, targeting, templates, live preview, placement, and analytics.
* **New (SDK 1.5.0):** `set_metric()` for usage-milestone smart triggers, plus first-seen tracking for install-age triggers. The SDK runtime ships free; the rules that drive it are authored in Pro.
* **Developer:** New `noticepilot_accept_goal_events` filter — the free hub ignores conversion (goal) events unless an add-on opts in, keeping conversion analytics gated. Snooze and trigger data are exposed to the SDK via the existing `noticepilot_api_content_item` filter.
* The SDK continues to support `snooze_duration` and `max_notices` config options; a campaign only shows a "Remind me later" link when a Pro-authored snooze flag is delivered.

= 1.2.1 =
* **New (SDK 1.4.0):** `Noticepilot_Remote_Notice_Client::track_goal( 'slug', 'goal_key' )` reports a conversion, attributed to the campaign/variant a site last saw. The hub records goal events (and accepts them after a campaign ends). Per-variant CVR and conversion summaries surface in NoticePilot Pro.

= 1.2.0 =
* **New:** Freemius integration and a Free + Pro model. The free hub stays fully functional; the optional **NoticePilot Pro** add-on unlocks A/B testing, per-variant analytics, and deactivation feedback.
* **New:** A/B testing groundwork — campaigns can carry weighted variants (authored in Pro); the SDK splits traffic deterministically and tracks events per variant.
* **New (SDK 1.3.0):** Opt-in deactivation-feedback modal (`deactivation_feedback` + `plugin_file` options) — asks users why they deactivated your plugin (skippable, anonymous) and reports it to your hub.
* **New:** Developer extension points are stable — `noticepilot_campaign_data`, `noticepilot_api_content_item`, `noticepilot_test_site_hashes` filters and the `noticepilot_campaign_modal_fields` action — so add-ons plug in without core changes.
* **Improvement:** An A/B testing upsell appears in the campaign editor when Pro is not active.

= 1.1.0 =
* **New:** Campaign templates — one-click starting points for review requests, BFCM sales, update prompts, deprecation warnings, and feature announcements.
* **New:** Live notice preview — see exactly how a campaign renders as a WordPress admin notice before publishing.
* **New:** Notice styles — choose Info, Success, Warning, or Error styling per campaign.
* **New:** Placement control — restrict a campaign to the integrating plugin's own admin screens (via the SDK `screen_ids` option) instead of site-wide, following WordPress.org guideline 11.
* **New:** "Remind me later" snooze — an optional gentler alternative to permanent dismissal.
* **New:** Import/export campaigns as JSON, and duplicate any campaign in one click.
* **New:** Test sites — exclude your own development/staging URLs from analytics so test traffic never skews campaign numbers.
* **New (SDK 1.2.0):** Analytics consent mode (`require_consent`) with `grant_consent()` / `revoke_consent()` helpers — keeps beacons off until the user opts in, for WordPress.org guideline 7 compliance.
* **New (SDK 1.2.0):** Frequency cap (`max_notices`) and configurable `snooze_duration`.
* **Fix (SDK 1.2.0):** `dismiss_duration` is now honored — dismissed notices reappear after the configured window (previously dismissals were effectively permanent).
* **Improvement:** Analytics schema now records per-variant events and conversion goals, laying the groundwork for A/B testing (NoticePilot Pro). Existing data is migrated automatically on update.
* **Developer:** New extension filters — `noticepilot_campaign_data`, `noticepilot_api_content_item`, `noticepilot_test_site_hashes` — and the `noticepilot_campaign_modal_fields` action for add-ons.

= 1.0.1 =
* **Security:** Sanitized nonce input in the admin form handler.
* **Security:** Replaced inline `<style>` output in the SDK with the proper `wp_add_inline_style()` API.
* **Security:** Replaced inline `<script>` output in the SDK with the proper `wp_add_inline_script()` API.
* **Improvement:** Added an explicit `__return_true` permission callback to the public analytics REST API route to comply with WP REST API guidelines.
* **Improvement:** Added plugin owner to the contributors list.
* **Improvement:** Updated readme tags and short description to better reflect the plugin's developer-focused, remote-distribution use case.

= 1.0.0 =
* Initial public release.
* Multi-product management with support for unlimited campaigns per product.
* Rich HTML campaign editor with full CSS and custom layout support.
* Campaign scheduling with automatic expiration handling via WP-Cron.
* Built-in analytics tracking for impressions, clicks, and dismissals.
* Analytics dashboard with both product-level and campaign-level breakdowns.
* Lightweight single-file PHP SDK for remote site integration, with auto-fetch, transient caching, and dismissal handling.
* Privacy-first analytics — remote site URLs are MD5-hashed before storage; no personal data is collected.

== Upgrade Notice ==

= 1.5.0 =
Major admin UI upgrade with a new React-powered interface, REST API workflows, and improved extensibility for Pro add-ons. Existing campaigns remain fully compatible.

= 1.2.0 =
Introduces the Free + Pro model (Freemius) and SDK 1.3.0 with opt-in deactivation feedback. The free hub is unchanged in behaviour; Pro is an optional add-on. Re-download the SDK to enable deactivation feedback in your plugins.

= 1.1.0 =
Adds campaign templates, live preview, notice styles, placement control, snooze, import/export, test-site exclusion, and SDK 1.2.0 with an analytics consent mode plus a dismiss-duration fix. Re-download the SDK for your plugins to get the new options. Database is upgraded automatically.

= 1.0.1 =
This release includes important security hardening for the admin form handler and the remote SDK. All users are encouraged to upgrade.
