Kwiro — AI Sales Agent & Chatbot for WooCommerce

1.2.16

• Fix — runtime KWIRO_VERSION constant. The internal KWIRO_VERSION PHP constant was stale at 1.2.13 while the plugin header and wp.org listing were already at 1.2.15. This release re-syncs them. The constant is used as the ?ver= cache-buster on every enqueued JavaScript file (admin connect UI, storefront widget injector, and the sales-event tracker), as the X-Plugin-Ver HTTP header on every cloud API request, and as the kwiro_version option sentinel written on activation, so users on 1.2.15 should upgrade to ensure cached assets and the cloud-side version header reflect the current release. No functional change for shoppers; no behaviour change at runtime. Drop-in upgrade.

1.2.15

• Disclosure update — AI sub-processor + Zero Data Retention. Updated the “Your Data, Your Choice” paragraph and the External services section to disclose OpenRouter, Inc. as the privacy-preserving AI inference gateway that prompts and responses transit, and the Zero Data Retention (ZDR) contractual safeguard that prevents OpenRouter or its upstream model providers from logging, storing, or retaining any of them. Required by WordPress Plugin Directory Guideline 7 (External Services). No code changes; readme-only update aligned with the corresponding kwiro.ai/privacy and kwiro.ai/gdpr revisions. Drop-in upgrade.

1.2.14

• Compat — tested with WordPress 7.0. WP 7.0 became the current stable shortly after 1.2.13 shipped, which made the directory show an “Untested with your version of WordPress” warning on the listing for every WP 7.0 shopper — a measurable drag on install conversion. Smoke-tested 1.2.13 against WP 7.0 (clean install, WP_DEBUG=true): activation clean, no deprecation notices in debug.log, Connect-to-Kwiro one-click link OK, settings page renders, widget injects on the storefront, full sync completes. No code changes — only the Tested up to field and Stable tag advance. Drop-in upgrade.

1.2.13

• WordPress.org review fix — enqueue all JavaScript via wp_enqueue_script. The plugin previously printed six inline <script> blocks via PHP (admin settings UI: grant-consent / disconnect / begin-link buttons and the API-key Show / Copy field; frontend: attribution capture and the widget iframe controller). The WordPress.org Plugins team flagged this in their R kwiro-ai-sales-agent/kwiro/11May26/T2 review because the directory guidelines require all JS to be registered/enqueued via wp_register_script + wp_enqueue_script. Moved every inline block into a standalone file under assets/js/ (admin-connect.js, sales-tracker.js, widget-injector.js), enqueued via the appropriate admin_enqueue_scripts or wp_enqueue_scripts hook, with dynamic config (ajax URL, nonces, widget origin, position side, i18n strings) attached via wp_add_inline_script — the documented best practice for non-string data and the function the reviewer’s email cited. No behavior change for merchants. Drop-in upgrade.
• Pre-submission audit pass — readme accuracy. Did a full audit against the wp.org guidelines + common-issues list before re-submission. Fixed the External services section: corrected endpoint names that no longer matched the code (api/sync/products → api/sync/batch, api/sync/orders → api/sync/sales-event, api/sync/log-event → api/sync/event, api/auth/connect-link → api/auth/begin-link); added the four endpoints that were missing (api/sync/finalize, api/sync/status, api/sync/product/{id} for product deletes, api/health for connection testing, api/auth/link-status); corrected the app.kwiro.ai description (the plugin opens it in a new tab on click — it does not embed it as a WP admin iframe; the legacy AI Sales Dashboard submenu was a v1.0 attempt that never had a working cross-origin session and was already disabled in v1.1). Also fixed the GDPR FAQ — clarified that the plugin sets one strictly-necessary kwiro_conv cookie (24h TTL) for chat→order attribution, which falls under the GDPR Article 5(3) ePrivacy strict-necessity exemption from the consent-banner requirement.
• Dead code removal — deleted includes/class-dashboard-embed.php (the in-admin iframe class referenced above). It was loaded by the autoloader but never instantiated; deleting it keeps the runtime surface tight and aligns the code with the readme description.
• Minor i18n — wp_die() page titles in the activation requirements check are now translatable via esc_html__ (PHP / WP / WC minimum version messages).
• PHPCS + WPCS clean pass. The reviewer’s checklist names PHPCS + WordPress Coding Standards alongside Plugin Check. Ran phpcs –standard=WordPress plus PHPCompatibilityWP (PHP 7.4+) over every PHP file: phpcbf auto-fixed 156 formatting violations (alignment, function-call signature whitespace, inline control structures), then I hand-fixed the remaining 22 (Yoda condition, short ternaries → full ternaries, empty catch blocks with explicit unset($e), missing PHPDoc @param tags, inline comment end-chars). The two unavoidable false positives (file naming class-{name}.php vs class-{full-prefixed-name}.php, and WPCS not knowing about the WC capability manage_woocommerce) are documented + suppressed in a repo-only .phpcs.xml.dist config that ships in the repo but not in the wp.org zip (added to .distignore). Final state: zero errors, zero warnings across all 11 PHP files under both WordPress (full) and PHPCompatibilityWP standards.
• Copy fix — Short Description now reads “~0% hallucination” instead of “0% hallucination” (carried forward from the held 1.2.12). No AI hits absolute zero across non-trivial test sets; the tilde makes the claim honest and defensible. Body of the readme (which already used “~0%”) is unchanged.

1.2.12

• Copy fix — Short Description now reads “~0% hallucination” instead of “0% hallucination”. No AI hits absolute zero across non-trivial test sets; the tilde makes the claim honest and defensible. Body of the readme (which already used “~0%”) is unchanged. No behavior or functional changes. Note: this version was built but never uploaded to wp.org; the copy change is included in 1.2.13.

1.2.11

• WordPress.org submission cleanup — strip diagnostic logging. Removed the temporary kwiro-debug.log file write under wp-content/uploads/, the rest_api_init request-tracker hook, and every [kwiro] … diagnostic line that was added in 1.2.10 to chase the Block Checkout attribution bug. The bug is fixed (1.2.7 + 1.2.8 + 1.2.9), so the diagnostic surface is no longer needed in production. Kept one error_log() call gated behind WP_DEBUG — only fires on actual cloud-POST failures, so support can still see the underlying error message when something goes wrong without writing to a publicly-readable log file. Drop-in upgrade, no behaviour change for working installs.

1.2.10

• Diagnostic logging for Block Checkout attribution debugging. Added a temporary wp-content/uploads/kwiro-debug.log file + rest_api_init checkout-request tracker so we could pin down where Store API attribution was getting lost on real merchant traffic. Helped catch the _update_order_from_request hook firing without extensions populated — fix shipped in 1.2.9. Diagnostic surface is removed in 1.2.11; if you’re upgrading from < 1.2.10 you can skip this version.

1.2.9

• Belt-and-suspenders: cookie-only attribution save on _order_processed. 1.2.8 registered the Store API extension schema and added a cookie fallback inside _update_order_from_request, but headless-Chrome end-to-end testing showed the meta still wasn’t sticking on some WC builds — likely because the order is reconstructed between hook fires on certain stacks. Added a redundant woocommerce_store_api_checkout_order_processed handler that runs cookie-only (doesn’t need $request) and only acts if the upstream handler didn’t already write the meta. Also added error_log() diagnostic lines on every code path so when this is reported next we have a paper trail in wp-content/debug.log (or PHP error log) instead of guessing. Drop-in upgrade.

1.2.8

• Register kwiro_attribution as a Store API extension + add cookie fallback. End-to-end repro showed the storefront fetch interceptor was correctly attaching extensions.kwiro_attribution.conversation_id to the /wc/store/v1/checkout POST body — the JSON sent by the browser had it — but the _kwiro_conversation_id order meta was still empty after place-order. Root cause: WC’s CheckoutSchema strips unregistered extension namespaces from $request[‘extensions’] before woocommerce_store_api_checkout_update_order_from_request fires, so 1.2.7’s hook saw an empty extensions array and returned early. We now register the namespace via ExtendSchema::register_endpoint_data on woocommerce_blocks_loaded. As a belt-and-suspenders safety net (some WC + caching combinations still drop the data even with the schema registered) the hook now also reads the kwiro_conv cookie out of $_COOKIE server-side when the extensions array comes up empty — same UUID validation as the JS write side. Drop-in upgrade.

1.2.7

• Block Checkout attribution actually reaches the order now. Two compounding bugs were swallowing AI-attribution on stores running the WC Block Checkout (the default since WC 8.3): (1) the plugin hooked woocommerce_store_api_checkout_order_processed, which only passes $order — so we had to re-parse php://input to read the request extensions, and that buffer was already consumed on a number of PHP/WC stacks; and (2) the JS captured Date.now() (milliseconds) but PHP compared with time() (seconds), so the attribution window check was working by accident on direct orders and never firing for assisted orders. Switched to woocommerce_store_api_checkout_update_order_from_request (the hook that passes both $order and the WP_REST_Request — clean access to extensions.kwiro_attribution), normalized the JS write to seconds-since-epoch, and added a defensive ms→seconds rescale in PHP for any orders that have legacy values stored. Drop-in upgrade.

1.2.6

• Declare HPOS + Block Checkout compatibility — clears the WooCommerce admin notice “Kwiro is incompatible with currently enabled WooCommerce features.” The plugin only touches orders through the WC CRUD API (wc_get_order, meta accessors, status hooks) and the Block Checkout’s Store API hook is already wired for attribution, so this is purely a declaration — no behavior change. Drop-in upgrade.

1.2.5

• Cash-on-Delivery / Bank Transfer orders now report to Kwiro — sales attribution previously only fired on woocommerce_payment_complete (Stripe / PayPal) or on a manual transition to completed, so COD and BACS orders never reached the dashboard’s Sales page until an admin marked them complete by hand. The tracker now also hooks processing and on-hold status transitions, with the existing _kwiro_tracked order-meta dedup ensuring online-paid orders don’t double-fire. Drop-in upgrade.

1.2.4

• Sync correctly fires sync/finalize on completion — restores the cloud-side hook that builds store_intelligence (which feeds the widget’s “I know all N products” contextual greeting) and runs the final embedding pass. The 1.2.3 inline-loop refactor inadvertently dropped the call to the finalize handler, so freshly-synced stores rendered “I know all 0 products here” on the storefront until the cloud’s hourly enrichment cron caught up. Drop-in upgrade — no DB or credential changes.

1.2.3

• Sync no longer depends on WP-CRON. Manual Sync Now now loops batches inline up to a 25-second AJAX budget, so a typical 100–250 product catalog finishes in a single click without relying on the host’s cron loop. Catalogs larger than the budget still hand off to kwiro_batch_sync for the rest, but if cron never fires the merchant can simply hit Sync Now again — the plugin resumes from the saved offset instead of restarting from zero. Fixes the “Syncing… 50/107” stall reported on dev VPS hosts and any prod host with WP-CRON disabled or rate-limited.

1.2.2

• Recoverable “domain already linked” error — when a domain that was previously connected to Kwiro is re-installing the plugin, the WP admin now shows a clear path forward instead of a dead-end. Fresh installs on a domain that was registered but never claimed by a Kwiro user now succeed automatically (no manual intervention). Domains that are claimed by a Kwiro account show a recoverable warning with the redacted email hint, “Open Kwiro dashboard” / “Try again” / “Contact support” actions, and clear copy guiding the merchant to retrieve their existing API key from Settings → API.
• External Services disclosure — added app.kwiro.ai (the dashboard iframe loaded inside WP admin’s AI Sales Dashboard submenu) so every external host the plugin connects to is listed in the readme’s External services section, per Plugin Directory Guideline 7.
• Widget ↔ plugin postMessage compatibility — bundled widget now dispatches both the v1.2 kwiro_* and legacy v1.1 aisales_* prefixes for resize / add-to-cart / navigate / viewport events. Resolves a real-customer interop bug where opening the widget left the iframe wrapper at the closed-launcher size (chips invisible under the input bar) and add-to-cart silently no-op’d on v1.2 plugin installs.

1.2.1

• Plugin slug rename — ai-sales-assistant → kwiro-ai-sales-agent to match the product name on WordPress.org. Existing v1.1.x installs are migrated automatically on first activation: API key, store ID, public key, sync status, settings, and consent flag carry over without reconfiguration. CRON hooks (aisales_batch_sync → kwiro_batch_sync, weekly sync) are rescheduled in place.
• Internal prefix alignment — aisales_* → kwiro_* across all options, transients, hooks, classes, AJAX action names, JS handles, and HTML element IDs. No user-visible change for fresh installs; v1.1.x upgrades are handled by the migration above.
• Display name — “Kwiro — AI Sales Agent & Chatbot for WooCommerce” (clarifies the product category in the WP admin Plugins list and the wp.org listing).

1.1.4

• WordPress.org submission readiness — explicit user-consent gate before the first connection to api.kwiro.ai (was: silent registration on settings-page open). Plugin now ships with no application/test files, an up-to-date “Tested up to” header, the new Requires Plugins: woocommerce declaration (WP 6.5+), and the External Services disclosure required by Plugin Directory Guideline 7.
• Privacy/Terms links surfaced on the plugin settings screen.
• Disconnect button added — purges the locally stored API key with a single click.

1.1.x and earlier

Pre-publication development versions. Highlights: One-click Connect flow (1.1.0), foreground first-sync (1.1.0), sync history logging (1.1.2), sync pagination + indexing fixes (1.1.1–1.1.3). Full notes available in the GitHub repository.