Registration Variations turns an Event Espresso ticket into a product with selectable options — sizes, colors, meal plans — each carrying its own remaining-stock inventory, price modifier, and SKU. It is the practical way to sell ticket-attached merchandise and meal choices without creating a separate ticket for every combination.
\nWhat it adds:
\nFront-of-house point of sale (optional). When Front of House for Event Espresso is installed, a ticket with variations opens a \"Sell options\" modal at the station with per-variation quantity steppers, fed through that app's generic payload contract. The integration is feature-detected and inert when the app is absent.
\nSelf-contained on Event Espresso. All of the variation model — definitions, inventory, pricing, generated questions, and the wp-admin exchange/refund flow — works on a plain Event Espresso install through wp-admin and the standard checkout. Front of House is purely an optional consumer.
\nFor full documentation and design notes, see the docs/ directory included with the plugin.
wp-content/plugins/ and activate it. Activation creates the per-variation stock table.Do I need Front of House for Event Espresso?
\nNo. The variation model, inventory, pricing, generated questions, and admin exchange/refund all work on plain Event Espresso. Front of House adds a point-of-sale selling modal when present.
\nWhich ticket editor is supported?
\nThe variation definitions are edited in the classic ticket editor's advanced details.
\nHow is pricing handled?
\nEach variation carries a price modifier (a positive or negative delta) on the ticket's base price. The charged amount composes with Event Espresso's native surcharges and discounts and is shown as one combined line item.
\nCan two people buy the last unit at the same time?
\nNo. Remaining stock is decremented through an atomic, conditional update, so concurrent registrations cannot oversell a variation.
", "changelog": "0.3.1
\n* Migrate to the shared release pipeline; richer View-details modal (readme.txt sections, tags). No functional change.
0.3.0
\n* Added a color-coded plugin icon (delivered through the update channel) and declared WordPress 7.0 compatibility. No functional change.
0.2.4
\n* Updates are now handled by the Manifest Updater plugin (via the standard \"Update URI\" header) instead of a bundled updater. No functional change.
0.2.3
\n* Security: escape variation label/SKU at the public option-render seam and sanitize them on save (stored-XSS fix).
\n* Fix: SPCO (vanilla EE checkout) purchases of a variation ticket now decrement the variation counter — the chosen key is seeded from the saved answer before the lifecycle commit, closing an oversell gap.
\n* Fix: admin exchange is now retry-safe after a partial failure (resume-aware reprice + idempotent refund), and never double-refunds on retry.
\n* Fix: admin exchange validates the target variation server-side (same ticket, live non-archived key) before running, with a clear message instead of a raw exception.
\n* Fix: fail closed on a shared multi-unit sale line (mirrors the reverse/exchange guards) — prevents a silent mischarge.
0.2.2
\n* Update channel + repository URLs moved to the ee-extensions org. No functional change.
0.2.1
\n* Variation sets per ticket with per-variation inventory, price modifier, and SKU.
\n* Oversell-safe atomic stock counter bound to the registration status lifecycle.
\n* Auto-generated, decorated selection question with server-side required-selection enforcement.
\n* Composed base-plus-modifier pricing as a single combined line item.
\n* wp-admin exchange/refund flow and a variation sales report.
\n* Optional Front of House \"Sell options\" modal with per-variation quantity steppers.