Wedding Coordinator

A portfolio-safe WordPress plugin for managing a complete wedding guest journey—from invitation eligibility and conditional RSVP flows through operational logistics, communications, capacity controls, and audit history.

Portfolio note: This repository is adapted from a private production implementation. Couple names, event location, production dates, real airport identifiers, guest data, sender identities, site URLs, and other personal configuration have been removed or generalized.

Why I built it

A wedding RSVP can look like a simple form until different guests need different experiences. In-person guests, livestream guests, waitlisted guests, +1 eligibility, meals, lodging, travel, transport, seating and deadlines all create state that has to stay consistent. I built the system as an operational product rather than a static RSVP form so the guest-facing experience and the admin-side source of truth stay synchronized.

What it does

• Verifies guests publicly by name or phone number.
• Determines invitation type on the server: in person, livestream-only, or waitlist.
• Runs a one-question-at-a-time RSVP journey with conditional branching.
• Enforces +1 eligibility from backend guest configuration.
• Supports versioned RSVP forms and stable question keys.
• Lets administrators edit guest records and invitation status after submission.
• Imports guest lists in bulk with duplicate detection and preview/commit workflow.
• Tracks meals, lodging, flights, transportation, seating and event access.
• Manages waitlist / eligibility transitions and dependent cascades.
• Tracks capacity-sensitive operational assignments.
• Sends wedding-specific communications with configurable sender identity.
• Sends deadline notifications without changing global WordPress mail identity.
• Provides exports, operational dashboards, audit records and schema verification.
• Uses short-lived signed public RSVP sessions rather than exposing authority in browser state.

Architecture

Public RSVP
   |
   v
GuestIdentityService
 name / phone lookup
 signed guest session
   |
   v
Entitlement + Wedding Setup
 backend invitation type
 +1 eligibility
   |
   v
RSVP Journey Service ------> Versioned RSVP Forms
   |                              |
   |                              v
   +--> meals / lodging / flights / notes / well wishes
   |
   v
Operational Services
 transport / seating / access / capacity / cascades
   |
   v
WordPress Admin
 guests / forms / operations / settings / exports / audit

MySQL/MariaDB schema + migration + verification layer under every workflow

Repository structure

wedding-coordinator.php       Plugin bootstrap and shortcode registration
uninstall.php                 Uninstall handling

db/
  schema-1.2.1.sql            Base schema
  patch-1.2.1.sql
  patch-1.2.2.sql
  fks-1.2.1.sql               Referential constraints

includes/
  admin/                      WordPress admin screens
  frontend/                   Public RSVP controller
  services/                   Domain/application services
  class-db.php                Table helpers
  class-migration-runner.php  Additive migration/repair logic
  class-schema-verifier.php   Runtime schema verification
  class-schema-manifest.php   Canonical schema expectations
  class-capabilities.php      Role/capability boundaries
  class-tx.php                Transaction helpers

docs/
  ARCHITECTURE.md
  SECURITY.md
  RSVP-APPLICATION.md
  OPERATIONS.md

screenshots/
  README.md

Product decisions demonstrated

Backend-controlled eligibility

The browser does not decide whether a guest is in-person, livestream-only, waitlisted, or allowed a +1. Those decisions are derived from backend records on every relevant request.

Conditional RSVP rather than one universal form

The public journey adapts to the guest. Declining an in-person invitation can offer livestream; declining livestream can move to well-wishes / registry messaging; waitlisted guests receive a separate flow.

Stable form versions

RSVP forms are versioned so the questionnaire can evolve without invalidating already-collected answers. Stable question keys allow relevant prior answers to carry forward.

Audited state transitions

Operational changes are treated as domain changes, not loose spreadsheet edits. Services coordinate writes, audit snapshots, capacities and dependent cleanup.

Fail-closed identity and access

Ambiguous name matches are rejected and guests can fall back to phone verification. Public sessions are signed and short-lived, and server-side authorization is recomputed from stored guest state.

Portfolio configuration

The original implementation was event-specific. This public version replaces the private configuration with placeholders:

• SettingsService::TZ_EVENT defaults to UTC.
• Airport placeholders are AAA, BBB, and CCC.
• Email sender defaults to Wedding Hosts and the WordPress admin email.
• No production guest, venue, domain, registry, or sender data is included.

For a real deployment, replace the portfolio placeholders with the event's approved configuration and run schema verification before accepting RSVP traffic.

WordPress requirements

• WordPress 6.4+
• PHP 7.4+
• MySQL/MariaDB compatible WordPress database
• Single-site WordPress installation

Basic setup

1. Install the wedding-coordinator plugin directory in wp-content/plugins/.
2. Activate Wedding Coordinator.
3. Allow the activation/migration layer to create or verify the schema.
4. Configure guests, invitation types, +1 eligibility, forms and operational settings in WordPress admin.
5. Place [wedding_portal] on the public RSVP page.
6. Configure the email sender before sending guest communications.

Security

See docs/SECURITY.md. Do not commit real guest exports, production database dumps, private registry links, credentials, mail-service secrets, or WordPress configuration files.

License

GPL-2.0-or-later, matching the plugin header.