tixfin-wordpress

WordPress plugin that integrates a Tixfin project directly into a WordPress site: event listings, ticket selection, and guest checkout, calling the Tixfin REST API natively (no iframe, no WooCommerce dependency).

Architecture

• tixfin-wordpress.php — plugin bootstrap.
• includes/class-tixfin-settings.php — Settings > Tixfin admin page (API base URL, project slug, optional discount/voucher bearer tokens, cache TTL).
• includes/class-tixfin-api-client.php — HTTP client to the Tixfin backend. Injects the x-project-slug header on every call, transient-caches GET responses, and is the only place the two server-side secret bearer tokens (discount preview, voucher validate) are used.
• includes/class-tixfin-rest-controller.php — registers tixfin/v1 WP REST routes that the blocks call (same-origin, no CORS setup needed on the backend).
• includes/class-tixfin-blocks.php — registers the two Gutenberg blocks and holds the shared render helpers.
• includes/class-tixfin-shortcodes.php — [tixfin_events] / [tixfin_checkout] fallback for classic themes.
• src/blocks/event-list/ — dynamic block (PHP render.php), editor preview via ServerSideRender.
• src/blocks/ticket-checkout/ — dynamic block; render.php outputs a container div, view.js (vanilla JS, no React at runtime) drives the interactive ticket selector, voucher field, and guest checkout form.

Backend contract this plugin relies on

See the Tixfin backend's OpenAPI spec. Endpoints used:

• GET /events/next, GET /events/{eventId}, GET /tickets/catalog, GET /public/tenant-config, POST /tickets/purchase/guest — public, no auth beyond the x-project-slug header.
• GET /billing/discount-actions/preview, GET /billing/vouchers/validate — bearer-gated; called only from PHP with the site's configured secret token.

POST /tickets/purchase/guest either 302-redirects to a hosted payment page (read via the Location header, wp_remote_request with redirection => 0) or returns a JSON array of tickets directly for zero-amount orders. There is no order-status polling endpoint — ticket delivery is by email, confirmed asynchronously via a signed backend webhook.

Known gaps / not yet implemented: seatmaps, ticket add-ons, bundles, waitlists, per-ticket-type custom form fields, and PayPal/Mollie-specific behavior beyond the generic redirect flow (these either weren't in the reference OpenAPI snapshot or are out of scope for v0.1).

Development

npm install
npm run build   # compiles src/blocks/* into build/blocks/* (committed, so the plugin works without a build step on install)
npm run start   # watch mode

PHP has no build step; classes are loaded via plain require_once (no autoloader/Composer dependency).