ee-extensions release bot
31 lines
5.5 KiB
JSON
31 lines
5.5 KiB
JSON
{
|
|
"name": "Event Espresso 4 Ticket Classes",
|
|
"slug": "eea-ticket-classes",
|
|
"version": "0.3.1",
|
|
"download_url": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-ticket-classes/eea-ticket-classes-0.3.1.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",
|
|
"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"
|
|
},
|
|
"author": "Mike Mulligan",
|
|
"author_homepage": "https://gitea.mulligan.casa/mmulligan",
|
|
"tags": [
|
|
"event espresso",
|
|
"tickets",
|
|
"ticket classes",
|
|
"registration questions",
|
|
"front of house"
|
|
],
|
|
"sections": {
|
|
"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>"
|
|
}
|
|
}
|