Ticket Classes adds a free-text class field to every Event Espresso ticket — one or more space-separated tokens such as attendee, apparel, or apparel-crew — and layers behavior on top of it so a single label can control how a ticket behaves across registration and point of sale.
What it does with a ticket's class:
\n-cond is shown only on tickets whose class includes the matching token (for example, an apparel-cond question appears only on apparel tickets). Non-conditional questions are unaffected. This applies both in standard Event Espresso checkout and, when present, at the point of sale.apparel-crew) rolling up under their base class (apparel).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.
\nStandalone, with an optional integration. 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 Front of House for Event Espresso through hooks that are inert when that app is not installed.
", + "installation": "wp-content/plugins/ and activate it. Activation adds the class column to the ticket table.-cond suffix, and — if you use Front of House for Event Espresso — configure per-profile class filters on your selling profiles.How do I make a question conditional on a ticket class?
\nGive the question an admin label ending in -cond, prefixed with the class token it belongs to (for example apparel-cond). It will then appear only on tickets whose class includes apparel.
Can a ticket have more than one class?
\nYes. The class field is space-separated, so a ticket can carry several tokens (for example attendee apparel). Sub-classes use a hyphen, like apparel-crew, and match their base token for filtering and grouping.
Does this require Front of House for Event Espresso?
\nNo. 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.
", + "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* 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).
0.2.2
\n* Update channel + repository URLs moved to the ee-extensions org. No functional change.
0.2.1
\n* Ticket class field on the Event Espresso ticket model, edited in advanced ticket details.
\n* Class-conditional registration question visibility in standard checkout and at the point of sale.
\n* Class-based catalog grouping with sub-class roll-up.
\n* Per-selling-profile class filters and class-based ticket scoping for Front of House for Event Espresso.