Skip to main content

Flavor Core Plugin - Changelog

[2.9.1] - 2026-06-23 — Correct licensing for newer features & on-demand module installs​

Updated​

  • A newer feature stays correctly licensed even when the Hub's feature list hasn't caught up yet. A brand-new feature (like the new HR module) could temporarily show a "requires Business" lock even on a Business license; the built-in catalogue is now the baseline and the server catalogue layers on top — fixing the lock-out and protecting every future feature.
  • Product setup respects the theme's on-demand module model — installing or updating the theme from the Flavor dashboard downloads the theme core only when the theme supports on-demand installs.

[2.9.0] - 2026-06-15 — License grace period & one-click Backup & Rollback​

Added​

  • License grace period. Premium features, modules and the ERP keep working for a configurable buffer (default 14 days) after a license expires — if you opt in — so you have time to renew without disruption. You'll see pre-expiry warnings on the License screen and the Dashboard. (Requires the matching Flavor Hub update.)
  • Backup & Rollback. A new Flavor → Rollback screen restores any Flavor product — or an individual component — to a previous version in one click, with a confirmation gate and configurable backup retention (keep 1–3 most recent).

Fixed​

  • Security — backup archives are now blocked from direct web access, and component rollback validates restore paths against directory traversal.
  • Internal — Flavor Core now stores its settings in its own database tables (automatic migration, no action needed).

[2.8.0] - 2026-06-08 — Audited AI data access, safer theme/plugin updates & a clearer Debug viewer​

Added​

  • Controlled, audited access to un-masked customer data for AI. Customer personal data stays masked by default for AI assistants. A new opt-in toggle (Flavor → Flavor AI → AI Access) lets administrators receive un-masked data when they need it — and every such access is recorded in the Debug viewer, so you always know who enabled it and who read it.

Fixed​

  • Theme and plugin self-updates are now atomic, like Flavor Core's. Updates extract to a staging area and swap in only once verified, with automatic rollback — an interrupted update can no longer leave your site broken. The 7-day automatic backup-restore safety net was also repaired.
  • The AI Pack is automatically restored after a Flavor Core update, so AI Access never silently goes dormant.
  • Debug viewer improvements — AI-access audit logs are now visible under the "core" filter, client-side startup errors are captured, channel filters work correctly, and a noisy third-party deprecation message no longer floods the log.
  • Security — license keys are no longer written in plain text to the emergency update log, and AI assistants now have a daily request cap on top of the existing per-minute limit.

[2.7.0] - 2026-06-01 — Flavor AI Center & safer self-updates​

Added​

  • Flavor AI Center — a new Flavor → Flavor AI admin page with two areas: AI Content (content & image generation) and AI Access — a new, opt-in, read-only way to let AI assistants (Claude, ChatGPT, and other MCP-compatible tools) securely query your store's catalog, orders, customers, stock, and invoices. Read-only by default, admin-only, with customer personal data masked by default — you stay in control of activation.
  • Safer self-updates — Flavor Core now updates itself using a staged, atomic swap with automatic rollback, so an interrupted or bad update can't leave your site broken.
  • Core Components — install add-on packs (such as the AI Pack) directly from the Flavor Core dashboard.

Fixed​

  • Debug viewer "Live tail" now keeps updating even when the browser window isn't focused, and no longer replays old log entries stamped with today's date.
  • Reliability improvements to the AI connection setup and the update checker.

[2.6.2] - 2026-05-22 — Patch: Shared licensing + integrity base classes for plugin/theme + telemetry re-wire + debug bridge fatal capture​

Stable patch release promoted from v2.6.2-beta.1. Core takes on a significantly larger role this cycle, hosting three shared base classes that the plugin + theme now extend (eliminating ~800 LOC of parallel-implementation drift across the licensing + integrity verification surface), wiring up three previously-dead telemetry paths so the Hub now receives integrity scan results + sentinel flags from licensed customers, and patching the debug bridge to capture WP REST fatals + hard PHP fatals that were previously slipping through. Plus a security hardening on the global flavor_core_is_licensed() helper that closes the loosest license check in the system.

Updated​

  • Tested up to WP 7.0. Header bump only — no code changes required.

Fixed​

  • flavor_core_is_licensed() security hardening. The global helper was previously the loosest license check in the system — it accepted any row with key !== '' AND status === 'active', no expiry verification, no staleness check, no fingerprint check. This made it potentially exploitable by anyone with direct database write access (SQL injection, compromised wp-admin, leaked DB credentials) — set the row and the helper would unlock premium features indefinitely. Now delegates to a hardened helper that mirrors the full LicenseGate semantics: license shape + 30-day staleness (closes the "manually-inserted row with no Hub origin" threat model) + expiry enforcement + fingerprint verification when issued. Backward-compat note: the change makes the check stricter — legacy sites with status=active but missing last_checked or with expired licenses or invalid fingerprints will now show as unlicensed. This is the desired behavior; operators with pre-migration data may need to re-verify their license via the Flavor Core dashboard.

  • Fingerprint payload schema guard — exp now correctly optional for Lifetime licenses. A first-shipped version of this guard (dev.3) rejected fingerprint payloads missing EITHER d (domain) OR exp (expiry) — too strict. Regression surfaced same-day on dev VPS smoke test: Lifetime licenses legitimately ship tokens with empty exp (Hub encodes "no expiry" by omitting the field). Result: every Lifetime-tier customer site saw fingerprint verify fail → "Active" license shown with fresh Last Verified BUT "Fingerprint verification failed. Premium features are locked." Revised guard (dev.4): d (domain) STILL mandatory — every legitimate token must bind to a domain. exp (expiry) OPTIONAL — empty/missing encodes the lifetime semantic. When exp is present, parsed strictly. Signature verification (Ed25519) remains the primary forgery gate; the threat model is unchanged.

  • Debug bridge now captures WP REST fatals + hard PHP fatals. The FLAVOR_DEBUG_BRIDGE define previously read new entries from PHP's error_log file at request end via a tail-mode shutdown handler — but WP REST's dispatch_to_callback() wraps every Throwable from a callback in a try/catch and converts to WP_Error with status 500 before PHP's default error_log writer fires, so the tail reader NEVER saw REST fatals. Hard PHP fatals (E_ERROR, E_PARSE, etc.) sometimes also bypass the tailed file. Result: customer-facing fatal errors silently vanished from the Flavor → Debug viewer, breaking the "single pane of glass" contract. Fix: 2 new capture paths added alongside existing tail-mode, all gated by the same FLAVOR_DEBUG_BRIDGE define so they activate together — a shutdown handler that forwards error_get_last() fatals to the debug log, and a rest_request_after_callbacks filter that intercepts WP_Error responses with status ≥ 500. The bridge now covers three distinct error paths (tail-mode for non-fatal categories, shutdown handler for hard fatals, REST filter for WP-swallowed Throwables) — no more blind spots.

Internal​

  • Shared base classes for licensing + integrity verification (F186). Plugin's LicenseGate (~528 LOC) and theme's Flavor_License_Gate (~429 LOC) were ~75% duplicate implementations of the same state-resolution + manifest-fetch algorithm. Same for the SHA256 + Ed25519 integrity verifiers (~395 LOC plugin / ~387 LOC theme — near-byte-identical). Both pairs collapse into thin subclasses of new abstract base classes living in Core (Flavor_Core_License_Gate_Base ~370 LOC, Flavor_Core_Integrity_Verifier_Base ~470 LOC). Plus a new Flavor_Core_Products_Registry for per-product metadata, a consolidated flavor_core_get_domain() helper, and centralized Ed25519 public keys (previously inlined in 7 production files — now owned by Core with 2 new global helpers). Total code reduction across all 3 products: ~800 LOC. Public surface preserved exactly — every existing call site (35 of them across plugin + theme) keeps working unchanged. The F80 expiry enforcement + F169/F183 grace-period logic now live ONCE in the base, eliminating the parallel-implementation drift class that historically caused same-day mirror fixes (F183 had to mirror F169 in May).

  • Telemetry paths now actually fire (F184/F187). Three Layer-2/3/4 telemetry paths previously diagnosed as "dead in production" — Layer-2 integrity scan (IntegrityVerifier::verify() cron handler), Layer-3 sentinel flag reporter (flags were being written locally but no client ever shipped them to Hub), Layer-4 server manifest refresh (Hub couldn't push tier-mapping updates to existing customers) — now all fire from the twice-daily Flavor_Core_License_Client::verify() cycle via a new run_post_verify_telemetry() orchestrator. Per-helper try/catch envelopes keep verify() functional regardless of telemetry failures. Sentinel flags use single-shot semantics (read + delete) so each flag occurrence reaches Hub exactly once per write. Plus Layer-3 sentinel sites in the plugin (5 sites + 1 bonus discovered during sweep) all rewired to read the canonical license-data location post the F77c migration. Flavor_Core_Data_Store::get() gained a $bypass_cache parameter that preserves the F133 defense-in-depth semantic (callers can defeat memory-cache poisoning attacks by forcing a fresh authoritative DB read) without contaminating the in-process cache.

[2.6.1] - 2026-05-15 — Patch: Plugin & theme component version display fix​

A focused single-fix patch. The Plugin Components panel on the Flavor Core dashboard now correctly displays each component's own version (e.g. Core Business Logic v1.0.14) instead of inheriting the parent plugin's version string. Affects display only — the underlying installed versions on disk were always correct, but the dashboard had an internal version-tracking record that was being silently overwritten on every page load by a legacy migration that pre-dated per-component versioning. Resolved at both the display layer (correctly reads the component's own version) and the data layer (migration that was overwriting per-component versions is now removed; existing customer installs auto-heal on the next page load after update).

Fixed​

  • Plugin & theme component version display. The Plugin Components panel previously showed component versions like v9.3.0-beta.9 or v7.2.0-beta.4 (the parent plugin / theme version) instead of the actual component version like v1.0.14. Display fix combined with internal cleanup so the dashboard always shows the true per-component version going forward.

[2.6.0] — 2026-05-08 — Minor: Dev release channel + admin reliability fixes​

Adds an optional Dev release channel for advanced users participating in early-access internal builds, plus several update-flow reliability improvements that surfaced during the beta validation cycle.

Added​

  • Dev release channel (opt-in for advanced users). A third release stream alongside Stable and Beta, intended for internal-team iterations and select partners. Activation requires three things in agreement: (1) a define('FLAVOR_DEV_CHANNEL', true) line in your wp-config.php, (2) Dev Access enabled on your license at the Flavor Hub admin (contact support), and (3) the Dev option selected in Flavor → Update Channels. Without all three, the option doesn't even appear in the UI — no clutter for typical customers. Dev releases are always lower-version than the corresponding stable/beta and never reach customers without the explicit opt-in. Pairs with Hub v1.5.0+. See Release Channels for the full opt-in flow.

Fixed​

  • Update flow correctly detects new dev iterations. Standard semantic version comparison ranks pre-release versions like 1.0.0-dev.1 lower than the corresponding 1.0.0 release, which broke the very first stable→dev transition: a site on stable would not see the dev build offered as an update. Now the update manager treats dev iterations as available updates when the operator has opted into the dev channel — preserving standard semver ordering for all other channel transitions.

  • No more "Downloading components..." progress bar after dev installs. Dev releases ship as full bundles (all components included), so the per-component download flow that runs after a normal update was both unnecessary and counter-productive on dev installs. Now skipped automatically when the installed version carries a -dev.N suffix.

  • Admin assets now load reliably on the Flavor Core admin pages even on slug collisions. Hardcoded WordPress admin hook suffix was replaced with a runtime-captured value on the top-level menu (the same fix landed on the Settings submenu in a previous release; this completes coverage). Edge case: if another plugin already registered a conflicting slug, WordPress would append "-2" and our admin assets would silently fail to enqueue.

  • Dev Access flag now syncs correctly between Hub and the local cache. Caught during beta validation: the Hub correctly returned the new license dev_enabled flag, but the local license client wasn't reading the new field — so Dev Access stayed effectively disabled even when granted. Three-line parity fix; the Settings UI now reflects the granted flag immediately. (Reminder for future field additions: a new license field needs four sync points — schema default + activate response + verify response + Settings reader.)

[2.5.0] - 2026-05-05 — Minor: Unified debug logging + WordPress notice bridge + post-update warning suppression​

A focused minor release improving how Flavor's logging system integrates with WordPress and the theme's Debug Bar. All visible behavior changes are gated behind FLAVOR_DEBUG — production sites without it are unaffected. Pairs with Theme v7.1.0+.

Added​

  • Unified logging bridge for the Debug Bar. Flavor Core's logger now supports observer subscriptions, which the theme uses to surface logged events at warning level or higher in the per-request Errors tab of the Debug Bar — alongside what already shows there. The full log history at Flavor → Debug is unchanged. Net result: when developing with FLAVOR_DEBUG enabled, you see logger writes and PHP warnings in one place without switching between the JSON log file and the bar.
  • WordPress internal-API misuse notices captured by Flavor logging. When WordPress fires a _doing_it_wrong() notice (e.g. a plugin calling a translation function too early), it now also lands in wp-content/flavor-logs/ and — combined with the bridge above — in the Debug Bar Errors tab. Previously these warnings only surfaced in wp-content/debug.log and Query Monitor, which managed hosts often hide. Visible only with FLAVOR_DEBUG enabled.

Fixed​

  • No more 36-module false-positive warning storm during the post-update component-install window. When a Flavor product update completed via Flavor → Updates, Flavor Core marked the install as "done" the instant the main ZIP was unpacked — but the per-component download phase still runs asynchronously for ~30–60 seconds afterwards, fetching ~36 module/gateway class files from the Hub. During that window, any concurrent request (admin pages, REST API calls, cron) would find those files missing and trigger a wave of _doing_it_wrong() notices in the admin. The "in progress" marker now persists for the full 10-minute install window before expiring naturally, so post-update concurrent requests stay quiet while files arrive. Genuine post-update errors are still captured in the JSON log file the whole time. Visible improvement: noticeably cleaner admin experience right after running a Flavor update.

[2.4.0] - 2026-05-04 — Minor: Single licensing layer + encrypted data store + Update Channel selector​

Minor release pairing with Plugin v9.2.0 and Theme v7.0.0. Flavor Core is now the single licensing layer for the entire ecosystem (theme + plugin become read-only consumers), sensitive data moves to a dedicated encrypted database table, plus the full Release Channels Settings page for opting into beta builds.

Added​

  • Settings page with Update Channel selector. New Flavor → Settings submenu lets the site admin choose Stable or Beta updates per-site. Beta is locked behind a per-license access flag granted by the Flavor team — the admin sees the option only after we enable it server-side. Includes a yellow warning banner + acknowledgment checkbox for the stable→beta transition, plus a Subscription State table showing the selected channel, effective channel (downgrades to Stable silently if Hub gate is closed), Hub-side beta access pill, per-license beta status, and a timestamp of the last channel switch.
  • Channel-aware update calls. All Hub interactions (license activation, verify, product update checks, component downloads) now declare the site's chosen channel, so beta-eligible sites pull beta builds automatically.
  • Refresh from Hub button. Forces an immediate license-state refresh without waiting for the twice-daily background check — useful right after the Flavor team grants Beta Access.
  • Save feedback + live state update. Channel save now shows a WordPress-style success notice and updates the Subscription State table inline without a page reload.
  • Centralized licensing — Flavor Core becomes the single licensing layer. The theme and plugin previously each ran their own license manager + fingerprint files in parallel with Flavor Core. Now retired — Flavor Core is the single source of truth. A one-shot migration runs automatically on first admin load: legacy theme + plugin license stores are copied into Flavor Core's encrypted store and the legacy files are removed. No customer action required — your active license stays active.
  • Encrypted data store for sensitive license data. Sensitive cached data (license keys, fingerprint tokens, update metadata) moves from the standard WordPress options table to a dedicated encrypted table at AES-256-GCM, with key derivation that handles AUTH_KEY copies between sites correctly. Non-sensitive markers stay in the options table. Migration is automatic and idempotent.

Fixed​

  • Settings page beta-acknowledgment no longer re-prompts when the channel is already set to Beta. Going back from beta to stable never requires acknowledgment.
  • Settings page assets enqueue repaired across two iterations — works correctly regardless of admin menu slug collisions on customer installs.
  • Settings save now busts update transients so a stable→beta switch immediately reflects on the Dashboard (was previously stale for up to 12 hours).
  • License activation now captures Beta Access flag immediately — no longer waits for the next verify cycle to enable the Beta radio.
  • JS form-submit acknowledgment rule aligned with the underlying state machine — closes a "Save was enabled but submit refused" UX dissonance.
  • Hub HTTP failures now log to the unified Debug Viewer at core.licensing.hub channel — diagnosis path for "verify isn't picking up my new beta access flag" reports.
  • Save no-op handling — saving the same channel value no longer surfaces as a false error.
  • Module class missing log spam closed for the WP Updates path. Updating Theme/Plugin/Core via WordPress Dashboard → Updates briefly showed false-positive warnings during the install gap; now suppressed via the same mechanism the Flavor dashboard's "Install All Products" flow uses.

[2.3.0-beta.1] — Beta release (superseded by v2.4.0 stable)​

This beta was the validation cycle for the v2.4.0 release above. See the v2.4.0 entry for the full feature list.

[2.2.1] - 2026-04-28 — Critical: Install All Products fix + Debug ZIP fix​

Critical patch addressing a bug in the "Install All Products" button that silently produced a half-installed system. Plus the Debug Viewer Download ZIP server-error fix and a cross-product update-window signal extension.

Fixed​

  • "Install All Products" now correctly activates plugins and downloads all components (CRITICAL). Previously, clicking Install All Products in the Flavor dashboard would install both products but leave the plugin inactive, with no components downloaded for either product — yet still show a misleading "All Done!" message before reloading. Manual recovery required clicking each product's individual install button. Post-fix, the bulk button now uses the same proven 3-step flow as the individual install buttons (download → activate → install components per product). New users who use Install All Products on a fresh install will now have a fully working site on first try. Existing customers unaffected if they used individual install buttons.
  • Debug Viewer "Download ZIP" no longer fails with a 500 error. Clicking Download ZIP in Flavor → Debug previously returned a server error because a required helper wasn't loaded in the REST context. The viewer now loads the helper on demand and the ZIP export works as expected.
  • Cleaner debug log during component install. The cross-product update-in-progress signal now persists through the whole component install cascade — not just the first phase — so the theme's debug log no longer surfaces transient "module not found" warnings mid-install. Pairs with Theme v5.1.1 and Plugin v9.1.1.

[2.2.0] - 2026-04-27 — Trust-chain hardening, Logger redaction, Debug viewer extensions​

Sibling release supporting the Theme v5.1.0 / Plugin v9.1.0 security work. The fingerprint verifier now fails closed when crypto isn't available (no more silent-bypass on hosts with libsodium disabled), the unified Logger is more defensive about secrets accidentally embedded in log messages, and the Flavor → Debug viewer gains Debug Bar settings + System Information sections. Requires Theme v5.1+ for Debug Bar settings sync.

Added​

  • Logger now defensively redacts secrets in log message text. Previously only structured context fields were redacted; now the message text itself is scanned for sensitive-key patterns (in JSON, URL-encoded, or printf shapes) and values automatically replaced with [REDACTED]. Closes a class of accidental secret leaks in third-party gateway logs that concatenated raw bodies into messages.
  • Fingerprint verifier fails closed when libsodium is unavailable. Modern PHP ships libsodium by default; the rare host with it disabled now correctly refuses to verify rather than silently accepting any signature.

Updated​

  • Debug viewer Settings tab now controls Debug Bar. Toggle the storefront overlay, position, and individual panels (Overview, Shop Info, Product Info, Cart Info, Query Info, API Info, State Info) directly from the same Settings page. Visible only when the Theme is active.
  • Debug viewer Diagnostics tab adds System Information. PHP / WP / MySQL / Theme / Plugin versions, memory limits, max execution time, and WP_DEBUG / SAVEQUERIES flags are now visible at the top of the Diagnostics tab for support and troubleshooting.

Fixed​

  • Cleaner admin notices during Flavor Core updates. During a Flavor Core update, the brief window where modules' class files are being replaced no longer triggers a flood of "module not found" warnings — the Update Manager now exposes a cross-product "in progress" signal that the Theme honours.

[2.1.0] - 2026-04-24 — Unified Debug Viewer & Self-update for Flavor Core​

Two major additions: a brand-new Debug Viewer that replaces the scattered debug tooling with a single, modern admin UI; and self-update support so Flavor Core can now update itself through the dashboard just like any managed product. Fully backward-compatible.

Added​

  • New: Debug Viewer. A centralized log viewer is now available at Flavor → Debug in the admin. Browse errors and warnings from your site, filter by severity and source, follow live activity, view expanded details for each entry, and download logs as a ZIP for support cases. An optional capture mode also records PHP errors from anywhere on the site. A built-in Diagnostics tab reports the current debug state and lets you write test entries to verify logging works end-to-end. Activate by adding define('FLAVOR_DEBUG', true); to your wp-config.php.
  • Self-update for Flavor Core. Flavor Core can now update itself through the Flavor → Dashboard page, exactly like the theme and plugin. A new status card shows the current Core version and a one-click update button when a new version is available. No dedicated license required — Core reuses any active Flavor license on the site.

Notes​

  • The legacy Debug Logs admin page has been retired — the new Debug Viewer replaces it entirely.
  • Documentation and developer references have been extensively updated (Debug System guide, architecture reference, knowledge base).

[2.0.0] - 2026-04-22 — Full source-code protection​

Major release: Flavor Core's internal code is now fully ionCube-encoded in production builds, matching the same encryption rollout shipped in theme v5.0.0 and plugin v9.0.0. Only the WordPress-required entry file stays readable; everything else — licensing, update manager, debug logger — is protected.

Breaking​

  • Full source-code encryption. All Flavor Core internal files are now ionCube-encoded. Requires ionCube Loader 14+ on your server — already a requirement for the licensing system.

[1.2.0] - 2026-04-22 — Debug Logs System​

Introduces a centralized debug logging system for the entire Flavor ecosystem (theme + plugin + core). One switch enables all logging, one admin page (Flavor → Debug Logs) for browsing, filtering, and managing log files.

Added​

  • Debug Logs admin page. A new Flavor → Debug Logs menu gives you a single place to browse the ecosystem's logs, filter by severity or source, search, prune old files (30-day auto-retention), and clear everything. Log files are stored safely in wp-content/flavor-logs/ with public access blocked. Enable with define('FLAVOR_DEBUG', true); in wp-config.php.

[1.1.1] - 2026-04-21 — Post-update stability fix​

Critical patch release that pairs with Theme v4.5.1 + Plugin v8.3.1. Fixes cases where storefront routes (single product page, shop archives) would break after a Core-managed update until the admin manually re-saved Permalinks.

Updated​

  • Debug log viewer is now dev-only. The log viewer is off in production unless explicitly enabled — no database writes for log entries when disabled. Enable with define('FLAVOR_CORE_DEBUG', true); in wp-config.php.

Fixed​

  • Storefront no longer breaks after a product update. After every Core-managed update, caches, OpCache, and WordPress rewrite rules are now automatically refreshed — no manual Permalinks re-save required.

[1.1.0] - 2026-04-20 — Update Manager & one-click product updates​

Complete rewrite of the update system. Flavor Core now fully manages updates for the theme, plugin, and all their components from a single place — the Flavor → Dashboard page — with safe pre-update backups, one-click installation, and accurate update badges.

Added​

  • One-click product updates. Update the theme, plugin, and individual components directly from Flavor → Dashboard with a progress overlay showing each step. A scheduled background check runs automatically so update badges appear as soon as new versions are available.

Updated​

  • Automatic pre-update backups. Before every update, the full product directory is backed up to wp-content/flavor-backup/ (as a compressed ZIP). If the backup fails, the update is aborted — your site is never left in a broken state.
  • Update badge in admin menu. The Flavor menu now shows a count badge when product updates are available.
  • Per-component version tracking. Each component carries its own version, so update badges appear only for components that actually changed.

Fixed​

  • WordPress Dashboard no longer shows stale update prompts for the theme and plugin — all updates are now managed exclusively from Flavor → Dashboard.
  • "Ghost" component update notifications removed — cases where the dashboard falsely reported dozens of updates immediately after install are resolved.
  • Updates no longer overwrite new files with old ones in a narrow race condition that could occur during the update sequence.
Full Version History

For the complete changelog including all previous versions, contact our support team.

Last updated on