Download free
Changelog

Ambikly changelog: what shipped, and what is in it.

Ambikly 1.1.0 and Ambikly Pro 0.0.1 are current. Versions follow major.minor.patch, the schema migrates itself on update, and every line below describes something that shipped.

Requires WordPress 5.4+, PHP 7.4+ Tested up to WordPress 7.1.4 GPLv3, both plugins
Current

Ambikly (Free) v1.1.0

  • Fixed: per-product tax settings were never applied. A product marked non-taxable was taxed anyway, and a product in a non-standard tax class was charged the standard rate — so zero-rated and reduced-rate goods could not be configured at all. Tax is now worked out per line, grouped by each line’s own tax class, with a cart discount shared across lines by value. Stores where every product is standard and taxable are unaffected.
  • Fixed: the account Downloads tab offered a working Download button after the allowance was used up or access had expired, which could only ever fail. It now reads “Limit reached” or “Expired”.
  • Fixed: the plugin declares Requires PHP and Requires at least, so WordPress can refuse activation on an unsupported host instead of letting it fail. A matching runtime check covers a host moved to an older PHP after installation.
  • Fixed: role names were translated during activation, which triggered WordPress 6.7’s “translation loaded too early” notice on a first install. Role names are now stored untranslated, as WordPress core stores its own.
  • Fixed: admin links in the dark theme kept their light-theme colour (2.36:1), and the “New” product badge on the storefront was 2.27:1. Both now meet WCAG AA.
  • Fixed: keyboard focus did not move into a dialog that contains no form fields, leaving keyboard and screen-reader users behind the overlay.
  • Fixed: a 100% coupon, a tax rate above 100%, and repeated variation generation were each accepted when they should not have been.
  • Fixed: several Upgrade Notice entries were long enough to be truncated mid-sentence.
Previous

Ambikly (Free) v1.0.5

  • Fix: all eight block-editor blocks were registered on the server only, so WordPress would render one already present in a page but never offered it in the inserter — no title, no icon, no category. Adding one meant hand-writing <!-- wp:ambikly/mini-cart /--> into the code editor. Each block now appears in the inserter under Widgets, with its own settings panel and a live server-rendered preview in the editor.
  • Docs: the uninstall opt-in was documented as living under “Settings → Advanced”, a tab that no longer exists. It is under Settings → Features & Addons.
  • Docs: coupons were described as supporting category restrictions. They restrict by product, by customer email, and by minimum/maximum spend — not by category.
  • Docs: the email template preview opens in a new tab rather than rendering inline, and the description now says so.
  • Docs: readme rewritten so every capability listed is one the plugin actually ships — variant images, local pickup, Net 7–90 terms, postcode and city tax rules, WP-CLI commands and CSV import/export were all present but undocumented.
Previous

Ambikly (Free) v1.0.4

  • Fix: a manual order created in wp-admin attached to whichever customer record was linked to the logged-in administrator’s own account, not the customer the merchant picked. The chosen customer kept an empty order history, and the admin-linked record had its name and phone overwritten with the buyer’s details.
  • Fix: on Reports, switching “Compare to previous period” on showed nothing at all when the previous period had no activity — a percentage change from zero is undefined, so the card rendered blank and the comparison looked broken. It now says so. (Regression introduced in 1.0.3.)
  • Fix: wp ambikly recompute customer-totals counted orders differently from every screen that displays them — it excluded refunded orders, so a customer with one fully-refunded order was stored as having none while the admin and My Account both showed one. It also reported “0 customer(s)” on runs that had just reset a row.
  • Fix: the “Explore Ambikly Pro” button rendered wp-admin’s dark gray on orange instead of white, and the “Unlock Ambikly Pro” heading rendered near-black on its orange banner. Both were losing a CSS cascade fight to wp-admin’s own unlayered element styles.
  • Fix: in dark mode the selected tab on the Emails screen was effectively invisible (dark orange text on a dark orange fill). Several colors at the darker end of each palette had no dark-mode equivalent at all.
  • Fix: the “Out of stock” and variant-count badges, and the short-description character counter, were below the AA contrast threshold.
  • Fix: invoices showed only their own sequential number, with nothing tying them back to the order. Packing slips have always shown it.
Previous

Ambikly (Free) v1.0.3

  • Fix: every money figure in the admin was printed without thousands separators — the Dashboard and Reports headline numbers read “$2656383.23” instead of “$2,656,383.23”.
  • Fix: the admin ignored the store’s “Currency position” setting, so a store configured for a right-hand symbol saw it on the left everywhere in wp-admin while the storefront showed it correctly.
  • Fix: report chart axis labels were raw fractions of the largest value (“$2582617.78”); they now round to readable steps and abbreviate (“$2.6M”).
  • Fix: chart gridlines, axis and tick labels were hardcoded light-theme grays and stayed light in dark mode.
  • Fix: on the Products list the Actions column painted over the Status column — the header read “Sta” and every status pill was clipped to a single letter.
  • Fix: Reports stat cards printed “vs previous period” under every figure even with comparison switched off.
  • Fix: the Store Description field’s placeholder promised “Press Enter to save, Ctrl+Enter for new line”; no such handling existed.
  • Fix: order emails, invoices and packing slips used indigo for links and buttons instead of the Ambikly brand color.
  • Fix: shop-grid cards let their buttons float at different heights when product names wrapped to different line counts; long titles also stretched the grid.
  • Fix: the storefront was squeezed into the narrow reading-width container some themes apply to page content, rendering a three-column grid at a third of the available width. It now centres on the viewport, and does nothing on themes that already give it room.
  • Fix: “7066 product(s)” and “3 review(s)” are now properly pluralised and digit-grouped (“7,066 products”, “3 reviews”).
  • Fix: the “Out of stock” button was white text on a faded orange fill (~1.9:1) — the least readable text on the shop grid. It now uses a legible neutral disabled style.
  • Fix: the missing-image placeholder was a 📦 emoji, which renders differently on every operating system. It is now a plain SVG icon.
  • Fix: importing a CSV that omits optional columns — the documented, ordinary case — emitted around 22 PHP warnings per row, which on sites that display errors corrupted the import response and made a successful import report a failure.
  • Fix: a webhook could be saved against an event name Ambikly never emits. It stayed “Active”, logged no deliveries and reported no error. Unknown events are now rejected at save time.
  • Fix: 48 form controls across the Coupon, Company, Category, Order, Tools and digital-product screens had a visible label that was never associated with the field, so screen readers announced them as unnamed. The shared field wrappers now bind label to control automatically.
  • Fix: refunds were capped by the order total rather than by the amount actually captured, so an unpaid bank-transfer or cheque order could be “refunded” — restoring stock and emailing the customer a refund notice for money they had never sent. The Refund button is now disabled on such orders, and the server refuses the request.
  • Fix: the variant grid and the manual-order line-item table had header cells without scope, which is what associates the unlabeled per-variant price and stock inputs with their column.
  • New: nine replacement plugin-directory screenshots taken from a clean store.
Previous

Ambikly (Free) v1.0.2

  • Fix: fatal error on PHP 7.4 whenever an order, product or other record was JSON-encoded or accessed as an array (mixed return types are PHP 8 only). Affects every 1.0.1 site on PHP 7.4.
  • Fix: guest buyers returning from Stripe or PayPal landed on a generic thank-you page — their cart was never cleared and the order-completed event never fired. Both return URLs now carry the order key.
  • Fix: a cart line could reference another product’s variation and, at order time, decrement that other product’s stock.
  • Security: editing a customer linked to a WordPress account no longer lets a Store Manager change that account’s login email (administrators only).
  • Fix: any REST route with an id in the URL could be pointed at a different record by adding an id to the request body (e.g. editing customer A saved customer B).
  • Fix: a checkout billing name containing HTML/script landed unescaped in the order confirmation and admin notification emails.
  • Fix: logging in with items in a guest cart deleted the account’s existing cart instead of merging it.
  • Fix: two simultaneous checkout submissions for the same cart created two orders and decremented stock twice.
  • Fix: an order’s status could be set straight to “Refunded” from the dropdown or API without any refund happening; a refunded order could later be moved to another status.
  • Fix: tax-inclusive pricing charged tax on top of the inclusive price.
  • Fix: digital products created from the quick-add modal, the REST API, CSV import or the sample importer were unpurchasable (“Out of stock”) by default.
  • Fix: bulk-editing variations always failed with a database error; clearing a variation price saved 0 instead of empty.
  • Fix: exporting products to CSV and re-importing the file cleared every SKU.
  • Fix: Stripe refunds issued from the Stripe dashboard were recorded with the cumulative refunded amount; the second partial refund was over-recorded or rejected. Refunds are now idempotent per gateway refund id, so an admin refund echoed back by the gateway webhook is not recorded twice.
  • Fix: cancelling and later reopening an order left stock overstated and B2B credit under-reserved; cancelled or failed orders kept their coupon usage forever.
  • Fix: deleting an order left its refunds, coupon usage and still-working download links behind.
  • Fix: Stripe/PayPal checkouts the buyer never finished held stock indefinitely — they now expire to “Failed” after 24 hours (filter ambikly_pending_gateway_order_ttl).
  • Fix: a missing column on the categories table caused the upgrade routine to drop and recreate the table; columns are now added in place.
  • Fix: paid card orders emailed the customer twice and declined attempts emailed the merchant a “new order”.
  • Fix: variable-product cart lines never recorded which variation was chosen; sold-out variations kept “Add to Cart” enabled; the mobile cart clipped the totals and checkout button off-screen.
  • Fix: logged-in customers’ cart actions failed with a 403 once their nonce went stale mid-session.
  • Fix: a WordPress account checking out with a different billing email created a second, disconnected customer record and broke address prefill.
  • Fix: the “Create an account during checkout” setting had no effect.
  • Fix: duplicate canonical tags and a per-product meta title that never reached <title> on product pages; unstable product sort order across pages; plan-priced digital products sorted as $0.
  • Fix: the setup wizard could create duplicate My Account / Order Received pages when re-run; wizard settings are now saved under the same keys the Settings screen reads.
  • Fix: Install::create_tables() could reset the database version and re-run the full migration on every request.
  • Security: hardened cart/checkout input (quantity ceiling, nested address payloads, client-controlled created_via), added a coupon brute-force throttle, sanitized customer name/phone/email at write time, and stopped a raw database error leaking on duplicate tag/brand slugs.
  • Accessibility: product-editor drawers are keyboard-reachable, every form control has a label, visible focus rings, skip-to-content link, aria-current navigation markers, table header scopes, live region for add-to-cart, reduced-motion support, and contrast fixes throughout the admin and storefront.
  • Add: Settings → Advanced → “Remove all data when the plugin is deleted” (the uninstall opt-in previously had no UI). Removed three Advanced toggles that had no effect.
  • Add: manual orders support coupons; Stripe key format validation; name/SKU length and negative-stock validation with clear errors.
  • Dev: 147 PHPUnit regression tests covering the fixes above; PHP 8.4 deprecation fixes.
Previous

Ambikly (Free) v1.0.1

  • Fix: two admin links (the setup wizard’s “Add a product” button and the low-stock/out-of-stock email’s “Manage product” link) pointed at an unregistered admin page and returned a 403 instead of opening the product editor.
  • Add: a “Add sample products” tool (Setup Wizard finish step and Tools screen) that creates 5 example products — simple, variable with real variations, digital download, digital with multiple pricing plans, and one on sale.
  • Add: a “Rerun setup wizard” shortcut on the Tools screen.
Previous

Ambikly (Free) v1.0.0

  • First stable release.
Requirements

What each release needs.

PluginVersionRequiresTested up toLicense
Ambikly 1.1.0 WordPress 5.4+, PHP 7.4+ WordPress 7.1.4 GPLv3+
Ambikly Pro 0.0.1 Ambikly (free core) WordPress 6.7 GPLv3+

Ambikly → Tools → System status reports the PHP, WordPress and MySQL versions and the multisite flag alongside these, so one copy of that screen carries the whole picture.

How versions work

Three numbers, and what each one promises.

Versions follow major.minor.patch. A patch release fixes bugs and never changes the schema, hooks or REST responses. A minor release may add tables, columns, routes or hooks — always with an automatic migration — and may deprecate a hook while keeping it working. A major release is the only place a hook, template or REST contract is removed, and the release notes list every one.

  • Patch: bug fixes only, safe to apply on sight
  • Minor: additions plus automatic migrations, deprecations announced
  • Major: the only release that removes anything
  • Each add-on carries its own version and migrates its own tables
How updates reach you

Releases arrive where WordPress expects them.

  1. Free core

    Updates appear on your Plugins screen like any WordPress plugin. Database changes run automatically through versioned migrations on the next page load.

  2. Pro

    With an active license key, Pro updates appear on the same Plugins screen. The key is re-checked once a day; an expired key stops updates but never stops the store.

  3. Add-ons

    Add-ons ship inside Pro and update with it. Each one carries its own version so it can migrate its own tables when needed.

  4. Check what you are running

    Ambikly → Tools → System status shows plugin and database versions, and flags any missing table.

Updating safely

The four-step update we use ourselves.

  1. Back up, or use staging

    Migrations are one-way. Take a database backup, or apply the update on a staging copy first — a staging domain counts as its own activation and can be deactivated afterwards.

  2. Update the free core, then Pro

    Pro checks the core version on load and waits if it is behind. Updating in this order means add-ons never run against a schema they do not expect.

  3. Open System Status

    Confirm both versions, that the schema version matches, and that no table is flagged missing. This is the report to paste if anything looks wrong.

  4. Place a test order

    Use an offline payment method, then refund it. Checkout, emails, invoice and the webhook queue all run in that one order.

FAQ

Release questions.

Why are the version numbers below 1.0?

Because we number honestly. The engine is complete and takes real orders, but the public API surface is still being finalized; 1.0 will mark the point where hook and REST contracts are frozen. Pre-1.0 releases already ship with versioned, automatic migrations, so upgrading is never a manual step.

Do updates change my database?

Only through migrations that run once, on the first page load after the update, inside the version check. Each migration is recorded, so a store that skips several releases applies them in order. System Status shows the schema version alongside the plugin version.

Will an update break my template overrides or hooks?

Release notes call out any template whose markup changed and any hook whose arguments changed. Overrides in your theme’s ambikly/ folder are never overwritten, because they live in your theme, not in the plugin.

Do I update Ambikly or Ambikly Pro first?

The free core first — Pro declares it as a requirement and checks its version on load. If Pro is updated first it waits, shows a notice and activates its add-ons once the core catches up.

Where do release announcements go?

This page is the record. License holders also receive an email for releases that change how license data is used, as the Privacy Policy describes; we do not send marketing mail on every release.

Run the current release.

The free core installs in a minute and migrates itself from any earlier version.

Download free See what Pro adds