WP-CLI Commands

WP-CLI Commands

Eventonomy registers a wp eventonomy command group for managing events, occurrences, RSVPs, and demo data from the command line. All commands go through the service layer, the same path as the REST API and admin UI.

What You Will Learn

• The full wp eventonomy command surface
• How to read events, occurrences, and RSVPs from the CLI
• How to import events and undo an import
• How to seed and unseed demo data
• How to recompute occurrences manually

The Full Command Surface

wp eventonomy exposes exactly eight subcommands, and wp eventonomy-pro exposes two:

Command	What it does
wp eventonomy events	List events
wp eventonomy occurrences	List an event’s occurrences
wp eventonomy rsvps	List an event’s RSVPs
wp eventonomy recompute_occurrences	Re-materialize occurrences
wp eventonomy import	Import / scan / undo
wp eventonomy orphans	Find and optionally remove orphaned child rows, and unused venue/organizer records
wp eventonomy seed	Load demo data
wp eventonomy unseed	Remove demo data
wp eventonomy-pro payout	Record an organizer payout
wp eventonomy-pro connect-status	Report one organizer’s Stripe Connect state

The CLI is read-only for events. There is no events create, no events delete, and no --force. Creating, editing, and deleting events go through the REST API, the block editor, or the admin screens - all of which run the same service-layer guards. Run wp help eventonomy to see the live list on your own install.

Command Groups

Events

Read-only. events is the whole subcommand - there is no list sub-verb after it.

# List events
wp eventonomy events

# Filter and format
wp eventonomy events --status=published
wp eventonomy events --status=pending --per_page=50 --format=json

Options: --status=<status>, --per_page=<number> (default 20), --format=<table|csv|json|yaml|count> (default table). Columns: id, title, status, next_occurrence_utc.

Occurrences

# List occurrences for an event (--event is required)
wp eventonomy occurrences --event=481
wp eventonomy occurrences --event=481 --format=csv

# Recompute occurrences for one event (or all events if --event is omitted)
wp eventonomy recompute_occurrences --event=481
wp eventonomy recompute_occurrences

Note the underscore in recompute_occurrences. A hyphenated recompute-occurrences is not a registered command and will fail.

RSVPs

# List RSVPs for an event (--event is required)
wp eventonomy rsvps --event=481
wp eventonomy rsvps --event=481 --format=csv

Options: --event=<id> (required), --format=<table|csv|json|yaml|count>. Columns: id, status, guest_email, guests_count.

Importing Events

wp eventonomy import runs the same rails as Eventonomy → Tools → Import: a full-file scan report, a chunked background runner past the synchronous 500-row cap, idempotent re-runs, and per-source undo. Under WP-CLI the job is driven to completion in-process, so there is no request timeout to work around.

Which user the import runs as. WP-CLI has no logged-in user, so the command resolves one: it honours the standard --user global, and otherwise acts as the site’s first administrator, announcing which - Acting as admin (#1). Pass --user=<id|login|email> to run as someone else.

This matters when approval is required. The importing user’s permissions decide whether imported events publish or go to the moderation queue, so running as an administrator imports them directly, while --user=<a member> correctly sends them for review:

# Imports as the site administrator (default)
wp eventonomy import events.csv

# Imports on behalf of a member - approval still applies to them
wp eventonomy import events.csv --user=jane

# Scan a file first - reports counts and per-row verdicts, imports nothing
wp eventonomy import events.csv --scan

# Import it
wp eventonomy import events.csv

# Watch a background job started from the Tools page
wp eventonomy import --status

# Migrate from The Events Calendar (database source, no file needed)
wp eventonomy import --source=tec --scan
wp eventonomy import --source=tec

# Remove everything a given source created
wp eventonomy import --undo=csv --yes

Options: [<file>], --source=<id> (csv, ics, tec, …; defaults to the file extension), --scan, --status, --undo=<source-id>, --yes. The preview flag is --scan, not --dry-run.

Demo Data

# Load demo events with venues, organizers, capacities, RSVPs and cover images
wp eventonomy seed

# Reseed from scratch (removes previously seeded rows first)
wp eventonomy seed --reset

# Skip the (slow) cover-image sideload
wp eventonomy seed --no-images

# Also apply the recommended default settings and finalize onboarding
wp eventonomy seed --with-settings

# Remove demo data (only rows created by the seeder)
wp eventonomy unseed

seed options: --reset, --images (on by default; pass --no-images to skip the sideload), --with-settings. unseed takes no options.

Demo data is also available from Eventonomy → Tools → Demo data in wp-admin.

Pro Commands

Eventonomy Pro registers its own wp eventonomy-pro group.

Payout (Model A earnings)

# Mark an organizer's booked net earnings as paid out (every currency they are owed in)
wp eventonomy-pro payout <organizer_id>

# Pay out just one currency
wp eventonomy-pro payout 42 --currency=JPY

# Record the bank/PSP reference and a note alongside it
wp eventonomy-pro payout 42 --reference=TRF-2026-0142 --note="Q3 settlement"

Options: <organizer_id> (positional, required, must be greater than 0), --currency=<ISO> (optional; pay just that currency instead of all owed currencies), --reference=<ref> and --note=<note> (both optional, default empty). Reference and note are stored on the payout row, so the ledger can be reconciled against the real transfer later.

Records that an organizer’s booked net earnings were paid (the money itself moves out-of-band; this only marks the commission ledger). A balance is always one currency, so with no --currency the command settles every currency the organizer is owed in and records one payout for each; --currency limits it to that one. Before booking each payout it nets any refund-after-payout debts in the same currency first, so the reported net is booked_net − outstanding_debt; unpaid debt carries to the next payout. Operator-only (runs only under WP-CLI). It is a thin wrapper over the same PayoutService::pay() chokepoint the admin UI and REST route use, so evnm_after_payout fires exactly once per currency whichever surface you go through. Source: eventonomy-pro/includes/Providers/EarningsProvider.php.

Both Pro commands are registered as closures, so wp help eventonomy-pro <sub> prints a bare synopsis with no OPTIONS block. The signatures above are the real ones - they come from the commands’ own usage errors, not from wp help. Free’s eight subcommands are documented command methods, so their wp help output is complete.

Adding Custom Subcommands

Add commands under the same group by calling WP_CLI::add_command on the cli_init action. Always resolve dependencies via evnm(); the CLI is just another surface adapter, same as REST.

add_action( 'cli_init', function () {
    WP_CLI::add_command( 'eventonomy export', function ( $args, $assoc_args ) {
        $events = evnm( \Eventonomy\Contracts\EventRepositoryInterface::class )
            ->query( [ 'status' => 'published', 'per_page' => 1000 ] );
        WP_CLI\Utils\format_items( 'table', $events['items'], [ 'id', 'title', 'start_local' ] );
    } );
} );

Notes

• All commands exit with a non-zero code on error.
• List commands print flat rows, not the REST list envelope. The repository returns the envelope internally and the CLI unwraps items before formatting, so --format=json gives you an array of rows with no total / has_more wrapper. Use the REST API if you need the envelope metadata.
• Seed/unseed only touches rows created by the DemoSeeder. Your real events are never affected by unseed.

Maintenance Commands

wp eventonomy orphans

Finds - and optionally removes - child rows whose event no longer exists.

wp eventonomy orphans                                  # dry run: report only
wp eventonomy orphans --delete                         # remove orphaned RSVPs, occurrences, tickets, meta
wp eventonomy orphans --delete --include-orders        # also remove orphaned ORDERS
wp eventonomy orphans --reassign-events=1              # give ownerless events (author_id 0) to user 1
wp eventonomy orphans --delete --catalog               # also remove UNUSED venue/organizer records that demo data or an import created
wp eventonomy orphans --delete --catalog --catalog-untagged  # also remove unused catalog records of unknown origin

--reassign-events=<user_id> handles the other orphan shape: an event whose author no longer exists, so author_id is 0. Nobody passes the ownership branch of evnm_user_can_manage_event() on such a row, which means the event has no organizer who can edit it, manage its attendees, or see its orders. Reassigning gives it a real owner instead of deleting it.

The delete cascade now fires from EventRepository::delete(), so no new orphans can be created. This command exists for rows orphaned before that fix, by any caller that reached for the repository directly. They matter because every COUNT(*) over rsvps or orders that is not joined back to evnm_events is inflated by them, and orphaned orders detach revenue from the event it belonged to.

Unused venues and organizers

A venue or organizer is a different shape of orphan: it is not a child of an event, it is something events point at. So “orphaned” here means nothing points at it, which the child-row sweep above cannot express.

These records are always reported, and the report names each one’s origin:

Origin	Meaning
demo	The demo seeder created it. Safe to remove.
import:<source>	An importer created it. Safe to remove.
unknown (may be the owner's)	Nothing vouches for it. It may be a venue you added for an event you have not created yet.

--catalog removes only the records with a known origin. Removing the unknown ones needs --catalog-untagged as well, because that is the only flag here that can delete something you created yourself. Read the report before you pass it.

Records left behind by demo loads from before Eventonomy 1.5.0 fall in the unknown group: the seeder had no way to mark what it created back then, so nothing can prove those rows were its. This command is how you clear them.

Two deliberate safeguards:

• It defaults to a dry run. Nothing is written without --delete.
• Orders are retained unless you ask for them. They are financial records, and the GDPR eraser already retains them under a tax exemption - removing them here would contradict that policy. Pass --include-orders only if you have decided that deliberately.
• Unused catalog records of unknown origin are retained unless you add --catalog-untagged, for the same reason: an unused venue is not necessarily a stray one.

wp eventonomy-pro connect-status <user_id> (Pro)

Reports everything about one organizer’s Stripe Connect state in a single place: whether Connect is enabled and fully configured site-wide, the redirect and webhook URLs to register with Stripe, the connected account id, the cached capability flags versus a live refresh from Stripe, and a plain payout-readiness verdict.

wp eventonomy-pro connect-status 42

Use it before debugging a payout that did not transfer: it distinguishes “not connected”, “connected but onboarding unfinished”, and “connected and payout-ready” without guessing from the ledger.

What’s Next?

Learn how to implement the Free↔Pro contract and deep-extend Eventonomy.

Extending →