Welcome to the Event Tickets repository on GitHub. Here you can browse the source code and keep track of development.

Event Tickets provides a simple way for visitors to RSVP or purchase tickets to your events. As a standalone plugin, it enables you to add RSVPs or tickets to posts or pages. When paired with The Events Calendar, you can add that same functionality directly to your event listings.

We recommend to stay up to date about everything happening in the project by following @TheEventsCal on Twitter.

If you are not a developer, please use the Event Tickets plugin page on WordPress.org.

• Event Tickets Documentation
• Event Tickets Developer Documentation
• Contributing guide
• Quick tests introduction

To report an issue, please create a new pull request.

This repository is not suitable for support. Please don't use our issue tracker for support requests, but for core Event Tickets issues only. Support can take place through the appropriate channels:

• If you have a problem, you may want to start with the self help guide.
• TheEventsCalendar.com premium support portal for customers who have purchased our premium plugins.
• Our community forum on wp.org which is available for all Event Tickets users.

Support requests on this repository will be closed on sight.

If you have a patch or have stumbled upon an issue with Event Tickets core, you can contribute this back to the code. Please read our contributor guidelines for more information how you can do this.

Work on this repository is planned before it is written, using OpenSpec. This is enforced — every pull request is checked for a plan.

Plans do not live here. A TEC feature routinely spans several repositories, so a spec kept in one of them is invisible from the others. They all live in one shared store instead: the-events-calendar/plans.

npm install -g @fission-ai/openspec
git clone git@github.com:the-events-calendar/plans.git ~/repos/tec-plans
openspec store register ~/repos/tec-plans --id tec-plans
openspec config set defaultStore tec-plans

The clone path is yours to choose. The --id is not — every command refers to the store as tec-plans.

1. Create the change before writing code, named after the ticket in lower case. OpenSpec requires kebab-case and rejects anything else, so the ticket SOFT-1234 becomes the change soft-1234: openspec new change soft-1234 --store tec-plans --description "what this does"
2. Write the proposal, then commit and push it in the plans repo.
3. Branch as usual: feat/SOFT-1234/short-desc.
4. Implement. If the work shows the plan was wrong — it often does — update the change rather than letting the plan and the code drift apart.
5. Open the PR. The template asks for the change ID, and CI checks the plan exists and is still active.

Commands that read or write plans take --store tec-plans: new change, status, instructions, list, show, validate, archive, context and doctor. The openspec store commands manage registrations instead and take --id, which is why the setup block above uses that.

Setting the store as OpenSpec's global default is part of the setup, not an optional extra. The stock OpenSpec skills and the /opsx:* commands know nothing about our store and act on whatever root resolves from the current directory, and this repository has no openspec/ root of its own — so without the default they fail, or land the change in a stray root. The org-wide skills repo's install.sh deliberately does not set it: it serves every StellarWP brand. Confirm with openspec context, which should print Using OpenSpec root: tec-plans. Pass the flag anyway; it is right whether or not the default is set.

This section covers what is specific to working here. The openspec-workflow skill covers the workflow itself — writing a proposal worth reviewing and keeping it current — and its TEC extension, tec-openspec, covers the shared store, the ticket-ID naming, and archiving once (after the last repository merges, not per repo). Install it with:

The below will work only once the stellarwp/skills-se becomes public.

/plugin marketplace add stellarwp/skills-se
/plugin install nexcess-se

PHP tests are Codeception/wp-browser suites run inside Docker by slic, the same runner CI uses.

Event Tickets does not test alone. CI clones the-events-calendar as a sibling directory of event-tickets (plus events-pro for the CT1/FT suites) and points slic at the shared parent. This layout is the thing people get wrong — the suites activate the-events-calendar/the-events-calendar.php by path relative to the plugins directory.

# 1. One parent directory holding every plugin side by side.
mkdir -p ~/plugins && cd ~/plugins
git clone --recursive git@github.com:the-events-calendar/event-tickets.git
git clone --recursive git@github.com:the-events-calendar/the-events-calendar.git
git clone --recursive git@github.com:the-events-calendar/events-pro.git   # ct1_*/ft_*/slr_ecp_* only
git clone https://github.com/stellarwp/slic.git
# => ~/plugins/{event-tickets,the-events-calendar,events-pro,slic}

# 2. Point slic at that parent.
./slic/slic here
./slic/slic build-subdir off
./slic/slic xdebug off

# 3. Install deps for every plugin AND every common, in this order.
./slic/slic use the-events-calendar        && ./slic/slic composer install --no-dev
./slic/slic use the-events-calendar/common && ./slic/slic composer install --no-dev
./slic/slic use events-pro                 && ./slic/slic composer install --no-dev   # if cloned
./slic/slic use event-tickets/common       && ./slic/slic composer install --no-dev
./slic/slic use event-tickets              && ./slic/slic composer install

# 4. Start WordPress and the themes the suites expect.
./slic/slic up wordpress
./slic/slic wp theme install twentytwenty --activate
./slic/slic wp theme install kadence       # square_integration runs on this theme

slic use event-tickets must come last — it selects the plugin whose suites run.

cd ~/plugins && ./slic/slic use event-tickets

./slic/slic run integration                                              # whole suite
./slic/slic run integration tests/integration/RSVP_Tickets_Test.php      # one file
./slic/slic run integration tests/integration/RSVP_Tickets_Test.php:test_ticket_with_stock
./slic/slic run wpunit --filter test_ticket_stock                        # by name

Never run slic run with no suite — WordPress globals leak across suites and everything fails.

Every suite below runs on each PR that touches PHP files. acceptance is commented out of the CI matrix and is not run.

• CI pins WordPress with slic wp core update --force --version=6.8; locally the container's shipped version is fine unless chasing a version-specific failure.
• CI appends --ext DotReporter (compact logs) and installs twentytwentyfour as well; neither matters locally.
• CI runs slic npm install && slic npm run build only for acceptance, which is disabled.
• CI checks out sibling plugins on a matching branch via its smart-checkout action; locally check out the branches you need by hand.