release eea-ticket-classes 0.3.2

eea-ticket-classes.json

@@ -1,13 +1,13 @@
 {
   "name": "Event Espresso 4 Ticket Classes",
   "slug": "eea-ticket-classes",
-  "version": "0.3.1",
+  "version": "0.3.2",
-  "download_url": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-ticket-classes/eea-ticket-classes-0.3.1.zip",
+  "download_url": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-ticket-classes/eea-ticket-classes-0.3.2.zip",
   "homepage": "https://gitea.mulligan.casa/ee-extensions/eea-ticket-classes",
   "requires": "6.4",
   "tested": "7.0",
   "requires_php": "8.1",
-  "last_updated": "2026-06-23 19:59:16",
+  "last_updated": "2026-06-23 20:27:09",
   "icons": {
     "1x": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-ticket-classes/icon-128x128.png",
     "2x": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-ticket-classes/icon-256x256.png"
@@ -25,6 +25,6 @@
     "description": "<p>Ticket Classes adds a free-text <strong>class</strong> field to every Event Espresso ticket — one or more space-separated tokens such as <code>attendee</code>, <code>apparel</code>, or <code>apparel-crew</code> — and layers behavior on top of it so a single label can control how a ticket behaves across registration and point of sale.</p>\n<p><strong>What it does with a ticket's class:</strong></p>\n<ul>\n<li><strong>Conditional registration questions.</strong> A registration question whose admin label ends in <code>-cond</code> is shown only on tickets whose class includes the matching token (for example, an <code>apparel-cond</code> question appears only on <code>apparel</code> tickets). Non-conditional questions are unaffected. This applies both in standard Event Espresso checkout and, when present, at the point of sale.</li>\n<li><strong>Catalog grouping.</strong> Tickets can be grouped into class-based categories so the selling catalog organizes itself by class, with sub-classes (<code>apparel-crew</code>) rolling up under their base class (<code>apparel</code>).</li>\n<li><strong>Class-based ticket scoping.</strong> A selling profile can be limited to tickets whose class matches a configured filter, so a given station or context only offers the relevant tickets. Sub-classes match their base token, and tickets with no class are excluded from a filtered scope (fail-closed).</li>\n</ul>\n<p>The class field itself is added to Event Espresso's ticket model and edited in the advanced ticket details, so it is available to your own templates and queries as well.</p>\n<p><strong>Standalone, with an optional integration.</strong> The ticket-class field and the conditional-question behavior work on a plain Event Espresso install. The catalog grouping, ticket scoping, and per-profile class filtering integrate with <strong>Front of House for Event Espresso</strong> through hooks that are inert when that app is not installed.</p>",
     "installation": "<ol>\n<li>Install and activate Event Espresso.</li>\n<li>Upload this plugin to <code>wp-content/plugins/</code> and activate it. Activation adds the class column to the ticket table.</li>\n<li>Edit a ticket and set its class token(s) in the advanced ticket details.</li>\n<li>(Optional) Name conditional registration questions with a <code>-cond</code> suffix, and — if you use Front of House for Event Espresso — configure per-profile class filters on your selling profiles.</li>\n</ol>",
     "faq": "<p><strong>How do I make a question conditional on a ticket class?</strong></p>\n<p>Give the question an admin label ending in <code>-cond</code>, prefixed with the class token it belongs to (for example <code>apparel-cond</code>). It will then appear only on tickets whose class includes <code>apparel</code>.</p>\n<p><strong>Can a ticket have more than one class?</strong></p>\n<p>Yes. The class field is space-separated, so a ticket can carry several tokens (for example <code>attendee apparel</code>). Sub-classes use a hyphen, like <code>apparel-crew</code>, and match their base token for filtering and grouping.</p>\n<p><strong>Does this require Front of House for Event Espresso?</strong></p>\n<p>No. The class field and conditional registration questions work on plain Event Espresso. Catalog grouping, ticket scoping, and per-profile class filters activate only when Front of House is present.</p>",
-    "changelog": "<p><strong>0.3.1</strong><br />\n* Migrate to the shared release pipeline; richer View-details modal (readme.txt sections, tags). No functional change.</p>\n<p><strong>0.3.0</strong><br />\n* Added a color-coded plugin icon (delivered through the update channel) and declared WordPress 7.0 compatibility. No functional change.</p>\n<p><strong>0.2.4</strong><br />\n* Updates are now handled by the Manifest Updater plugin (via the standard \"Update URI\" header) instead of a bundled updater. No functional change.</p>\n<p><strong>0.2.3</strong><br />\n* Fix: self-hosted updater block fataled on activation — the plugin namespaces add_action/add_filter, so the appended hook + updater class are now called globally-qualified (\\add_action, \\EEA_Ticket_Classes_Updater).</p>\n<p><strong>0.2.2</strong><br />\n* Update channel + repository URLs moved to the ee-extensions org. No functional change.</p>\n<p><strong>0.2.1</strong><br />\n* Ticket class field on the Event Espresso ticket model, edited in advanced ticket details.<br />\n* Class-conditional registration question visibility in standard checkout and at the point of sale.<br />\n* Class-based catalog grouping with sub-class roll-up.<br />\n* Per-selling-profile class filters and class-based ticket scoping for Front of House for Event Espresso.</p>"
+    "changelog": "<p><strong>0.3.2</strong><br />\n* Fix a typo in the activation column-check ($wpdb-&gt;pefix -&gt; $wpdb-&gt;prefix); drop a stale internal docblock (@package/@version).</p>\n<p><strong>0.3.1</strong><br />\n* Migrate to the shared release pipeline; richer View-details modal (readme.txt sections, tags). No functional change.</p>\n<p><strong>0.3.0</strong><br />\n* Added a color-coded plugin icon (delivered through the update channel) and declared WordPress 7.0 compatibility. No functional change.</p>\n<p><strong>0.2.4</strong><br />\n* Updates are now handled by the Manifest Updater plugin (via the standard \"Update URI\" header) instead of a bundled updater. No functional change.</p>\n<p><strong>0.2.3</strong><br />\n* Fix: self-hosted updater block fataled on activation — the plugin namespaces add_action/add_filter, so the appended hook + updater class are now called globally-qualified (\\add_action, \\EEA_Ticket_Classes_Updater).</p>\n<p><strong>0.2.2</strong><br />\n* Update channel + repository URLs moved to the ee-extensions org. No functional change.</p>\n<p><strong>0.2.1</strong><br />\n* Ticket class field on the Event Espresso ticket model, edited in advanced ticket details.<br />\n* Class-conditional registration question visibility in standard checkout and at the point of sale.<br />\n* Class-based catalog grouping with sub-class roll-up.<br />\n* Per-selling-profile class filters and class-based ticket scoping for Front of House for Event Espresso.</p>"
   }
 }