Overview

Caz Event Manager Pro is a WordPress plugin designed to add event booking and event-management functionality to WooCommerce.

The plugin uses WooCommerce products as events rather than introducing a separate event post type.

This architecture allows an event to use the existing WooCommerce product, cart, checkout, order and customer systems while Caz Event Manager adds the event-specific information and operational tools.

The core relationship is:

WordPress

↓

WooCommerce Product

↓

Caz Event Manager Event Data

↓

WooCommerce Booking

↓

Attendee

↓

Check-In / Attendance

Platform Requirements

Caz Event Manager Pro is designed for:

• WordPress
• WooCommerce
• PHP environments supported by the current WordPress/WooCommerce installation
• A WordPress site capable of running standard WooCommerce plugins

The plugin should be tested against the current WordPress and WooCommerce versions used by the target website.

Event Architecture

An event is a WooCommerce product identified by event metadata.

The primary event marker is:

_caz_is_event

An event product has:

_caz_is_event = yes

Additional event information is stored as product metadata.

The core event metadata includes:

Meta Key	Purpose
_caz_is_event	Identifies the WooCommerce product as a Caz Event
_caz_event_date	Event date/time information
_caz_event_venue	Event venue
_caz_event_capacity	Maximum event capacity

This approach means developers can work with standard WooCommerce product IDs when integrating with Caz Event Manager.

Event Product Detection

An event can be identified using:

get_post_meta($product_id, '_caz_is_event', true)

An event is recognised when the returned value is:

yes

Example:

if ( get_post_meta( $product_id, '_caz_is_event', true ) === 'yes' ) {
    // This WooCommerce product is a Caz Event.
}

Event Fields

Caz Event Manager adds event fields to the WooCommerce product data area.

The event fields include:

• This product is an event
• Event Date
• Venue
• Capacity

The values are stored as WordPress post metadata.

The plugin sanitises event field values before storing them.

WooCommerce Integration

Caz Event Manager builds on WooCommerce rather than replacing it.

A developer can therefore use the standard WooCommerce product and order APIs when working with event data.

For example:

$product = wc_get_product( $event_id );

can be used to retrieve the underlying event product.

Similarly, WooCommerce order APIs are used to retrieve bookings.

This provides compatibility with the existing WooCommerce ecosystem.

Booking Architecture

Bookings are derived from WooCommerce orders containing the relevant event product.

Caz Event Manager examines qualifying WooCommerce orders and their line items to determine the number of places booked for an event.

The booking quantity is taken from the WooCommerce order item.

This means:

One order

does not necessarily equal:

One attendee/place

because an order may contain multiple quantities.

Booking Status

The booking system works with qualifying WooCommerce order statuses.

Processing and completed orders are used when calculating active event bookings.

This means the booking count is derived from WooCommerce order information rather than a separate event-booking database.

Capacity

Event capacity is stored in:

_caz_event_capacity

The capacity can be retrieved using:

$capacity = (int) get_post_meta(
    $event_id,
    '_caz_event_capacity',
    true
);

Capacity is then compared with the current booked quantity.

Booking Calculations

Caz Event Manager provides booking calculations through its booking functionality.

The important values are:

Capacity

Maximum places available.

Booked

Number of places currently booked.

Remaining

Capacity minus booked places.

Conceptually:

Remaining = Capacity - Booked

These values are used by the front-end event display and event-management screens.

Booking Class

The booking functionality is provided through the:

CEM_Bookings

class.

This class is used by other Caz Event Manager components when they need booking information.

For example:

CEM_Bookings::booked( $event_id );

can be used to obtain the current booked quantity.

The plugin also uses booking methods for:

• Remaining places
• Checked-in totals
• Event attendance calculations

Developers extending Caz Event Manager should use the existing booking methods rather than duplicating order-counting logic.

Front-End Event Information

Caz Event Manager adds event information to the WooCommerce product page for products identified as events.

The front-end event information can include:

• Event date
• Venue
• Capacity
• Booked places
• Remaining places

This allows the standard WooCommerce product page to function as the event booking page.

Event Directory Shortcode

The primary public shortcode is:

[caz_events]

The shortcode is registered through the:

CEM_Shortcodes

class.

It queries WooCommerce products identified by:

_caz_is_event = yes

and generates the public event directory.

Developers can therefore create a public event page simply by placing:

[caz_events]

inside a WordPress page.

Shortcode Behaviour

The event directory can display information including:

• Event title
• Capacity
• Booked places
• Remaining places
• Booking link
• Sold-out status

When places remain, the customer can proceed to the underlying WooCommerce product.

When capacity has been reached, the event can be displayed as sold out.

Event Data Flow

The public booking process is therefore:

[caz_events]
       ↓
WooCommerce Event Product
       ↓
Cart
       ↓
Checkout
       ↓
WooCommerce Order
       ↓
Caz Event Manager Booking
       ↓
Attendee

Attendee Architecture

Attendees are derived from WooCommerce orders associated with the event product.

The attendee-management system does not require a separate attendee post type for standard bookings.

The underlying WooCommerce order remains the transaction record.

Caz Event Manager adds event attendance information to that booking.

Check-In Data

Check-in information is stored against the WooCommerce order for the relevant event.

The check-in metadata uses an event-specific key:

_caz_checked_in_{event_id}

For example, conceptually:

_caz_checked_in_123

where 123 is the event product ID.

A successful check-in stores:

yes

This allows the same order to potentially contain information relating to different event products without using one global check-in flag.

Undo Check-In

Removing a check-in deletes the event-specific check-in metadata from the order.

Conceptually:

delete_post_meta(
    $order_id,
    '_caz_checked_in_' . $event_id
);

This returns the booking to an unchecked-in state.

No-Show Data

No-show information is similarly stored against the order for the specific event.

The metadata pattern is:

_caz_noshow_{event_id}

A no-show can therefore be associated with a particular event booking.

This supports attendance reporting without changing the underlying WooCommerce order status.

Attendance

Attendance can be calculated from the relationship between bookings and check-ins.

The basic calculation is:

Attendance Rate =
Checked In / Booked × 100

The event-management screens use the booking and check-in information to provide attendance statistics.

QR Check-In Architecture

Caz Event Manager includes QR-code functionality for event check-in.

The QR system is designed to identify the customer’s event booking and allow the attendee to be checked in through the scanner.

The QR ticket is associated with a booking rather than functioning as a separate payment mechanism.

The development architecture is:

WooCommerce Booking
       ↓
Event Ticket
       ↓
QR Code / Token
       ↓
Scanner
       ↓
Booking Validation
       ↓
Check-In

Developers extending the scanner should preserve the distinction between:

Ticket identification

and:

WooCommerce payment/order processing.

Mobile Dashboard

The plugin includes a Mobile Dashboard for event-management operations.

The dashboard works from the same underlying event products and booking calculations as the standard administration screens.

It can provide views including:

• All events
• Today’s events
• Upcoming events
• Past events

The dashboard also provides quick access to attendee management and event information.

This means developers should not create a separate event data source for mobile functionality.

The mobile dashboard should use the same event and booking information as the main administration interface.

Staff Role

Caz Event Manager provides a staff-oriented access model through the:

CEM Staff

role.

The purpose is to provide event operational access without requiring every event worker to be a WordPress Administrator.

The role is particularly relevant to:

• Event-day staff
• Check-in staff
• Workshop assistants
• Attendee-management staff

When extending staff functionality, capability checks should be preserved so that event staff do not automatically receive unrelated WordPress administration privileges.

Administration

The main plugin administration area is registered under:

Caz Events

The administration architecture can include areas such as:

• Dashboard
• Events
• Attendees
• Mobile Dashboard
• Communications
• Settings
• Staff
• Tools

Individual components register their own administration interfaces.

Event Cloning

Caz Event Manager includes event cloning functionality.

The event cloner operates on WooCommerce products identified as Caz Events.

The cloned event:

• Remains a WooCommerce product
• Copies relevant product content
• Copies relevant metadata
• Copies product categories
• Copies product tags
• Is created as a draft
• Clears the event date so the new event can be scheduled separately

The clone therefore provides a starting point for creating another event without duplicating the original booking records.

Important Cloning Principle

A cloned event must receive its own product ID.

The new event must not share booking or attendance metadata with the original event.

Developers extending the cloning system should therefore ensure that event-specific information is associated with the new product ID.

Security

Administrative operations should use WordPress capability checks and nonces.

Examples of security mechanisms used by the plugin include:

current_user_can()

and:

check_admin_referer()

Developers adding administrative actions should follow the same approach.

Data Sanitisation

Data received from forms or request parameters should be sanitised before being stored or used.

For example, event field values use WordPress sanitisation functions before being saved.

Developers should follow WordPress standards including:

sanitize_text_field()

wp_unslash()

and appropriate escaping functions when outputting data.

Output Escaping

Data displayed to customers or administrators should be escaped according to its output context.

For example:

esc_html()

for text and:

esc_url()

for URLs.

This is particularly important because event titles, venues and customer information may originate from editable WordPress or WooCommerce data.

Nonce Protection

Administrative actions that modify event or attendance information should use WordPress nonce protection.

This applies particularly to actions such as:

• Clone Event
• Check In
• Undo Check-In
• No Show
• Export actions
• Settings changes

Developers extending these actions should not rely solely on a URL parameter or user capability check.

Extending Caz Event Manager

Developers extending the plugin should work with the existing WordPress and WooCommerce architecture rather than creating parallel event systems.

Recommended principles:

Use the WooCommerce product ID

Treat the event product ID as the primary event identifier.

Use existing event metadata

Use the established event metadata structure where appropriate.

Use CEM_Bookings

Use the existing booking calculations rather than duplicating WooCommerce order queries.

Respect event-specific metadata

Check-in and no-show information is associated with a specific event ID.

Preserve WooCommerce compatibility

Do not bypass the WooCommerce order and product APIs unnecessarily.

Preserve WordPress security

Use capabilities, nonces, sanitisation and escaping.

Recommended Extension Pattern

A developer adding functionality should generally follow this structure:

New Feature
    ↓
Identify Event Product
    ↓
Read Existing CEM Data
    ↓
Use WooCommerce APIs
    ↓
Perform Feature Operation
    ↓
Store Only Required Additional Data
    ↓
Escape Output

This keeps extensions compatible with the existing architecture.

Avoiding Duplicate Booking Logic

A common development mistake would be to create a second booking calculation.

For example, an extension should not independently query every WooCommerce order and calculate event capacity if the existing booking class already provides the required calculation.

Prefer:

CEM_Bookings::booked( $event_id );

and:

CEM_Bookings::remaining( $event_id );

where appropriate.

This keeps booking numbers consistent throughout the plugin.

Developer File Structure

The plugin is organised into separate PHP components for major areas of functionality.

The architecture includes components for areas such as:

Admin
Event Fields
Bookings
Frontend
Shortcodes
Attendees
Event Cloning
Communications
Mobile Dashboard
Check-In
QR / Scanner

This modular structure allows individual features to be maintained separately rather than placing the entire plugin into one PHP file.

Developer Testing

Before releasing an extension or modification, test the following.

Event creation

• Create a WooCommerce event product.
• Confirm _caz_is_event is set to yes.
• Confirm event date is saved.
• Confirm venue is saved.
• Confirm capacity is saved.

Booking

• Complete a WooCommerce booking.
• Confirm the order is processed correctly.
• Confirm booked quantity is correct.
• Confirm remaining capacity is correct.

Attendees

• Confirm the booking appears in Attendees.
• Confirm customer information is correct.
• Confirm quantity is correct.

Check-in

• Check an attendee in.
• Confirm the check-in status.
• Confirm the checked-in count increases.
• Undo the check-in.
• Confirm the checked-in count decreases.

No-show

• Mark an attendee as a no-show.
• Confirm the event record reflects the status.

QR

• Generate/access the customer’s QR ticket.
• Scan the QR code.
• Confirm the correct booking is identified.
• Confirm the attendee is checked in.

Cloning

• Clone an event.
• Confirm a new product is created.
• Confirm the new product is a draft.
• Confirm the event date is cleared.
• Confirm product categories are preserved.
• Confirm bookings are not copied.

Compatibility Considerations

Because Caz Event Manager extends WooCommerce, developers should avoid making assumptions about WooCommerce’s internal storage where an official WooCommerce API is available.

Use:

wc_get_product()

for products and:

wc_get_orders()

for orders where appropriate.

This is preferable to directly querying WooCommerce database tables.

Developer Documentation Principle

Caz Event Manager Pro should be treated as an extension of WordPress and WooCommerce rather than a separate event platform.

The fundamental architecture is:

WordPress

provides the CMS.

WooCommerce

provides products, customers, cart, checkout and orders.

Caz Event Manager Pro

adds event metadata, capacity management, attendee management, check-in, QR ticketing, event communications and event operations.

Architecture Summary

WordPress
│
├── WooCommerce
│   ├── Products
│   ├── Customers
│   ├── Cart
│   ├── Checkout
│   └── Orders
│
└── Caz Event Manager Pro
    │
    ├── Event Metadata
    │   ├── Event Flag
    │   ├── Date
    │   ├── Venue
    │   └── Capacity
    │
    ├── Booking Calculations
    │
    ├── Event Directory
    │   └── [caz_events]
    │
    ├── Attendees
    │
    ├── Check-In
    │
    ├── QR Tickets / Scanner
    │
    ├── Mobile Dashboard
    │
    ├── Communications
    │
    ├── Staff Access
    │
    └── Event Cloning

Summary for Developers

Caz Event Manager Pro is a WooCommerce event-management extension built around standard WordPress and WooCommerce objects.

The central design decision is that events are WooCommerce products.

Event-specific information is stored using WordPress product metadata, while bookings are derived from WooCommerce orders.

The plugin then builds event-specific functionality around that foundation:

Event Product

→ Capacity

→ WooCommerce Booking

→ Attendee

→ QR Ticket

→ Check-In

→ Attendance

The public-facing event directory is provided through:

[caz_events]

The core booking calculations are provided through CEM_Bookings.

Event-specific metadata includes:

_caz_is_event

_caz_event_date

_caz_event_venue

_caz_event_capacity

Event-specific attendance information uses event-specific order metadata such as:

_caz_checked_in_{event_id}

and:

_caz_noshow_{event_id}

Developers extending Caz Event Manager Pro should build on these existing structures, use WordPress and WooCommerce APIs, preserve capability and nonce checks, sanitise incoming data and escape output.

The goal is to extend the existing event-management architecture without creating a competing booking, product or attendee system.