WordPress Hslg App Api

WordPress Hslg App Api module

Hosts independently deployable HSLG-owned API endpoints and schema operations on WordPress/MariaDB.

Plugin responsibility and entry points

This installable WordPress plugin hosts the HSLG-specific REST API and HSLG MariaDB schema. hslg-app-api.php is the WordPress plugin bootstrap; src/Plugin.php registers services, schema and route hooks. src/controllers/FoundationController.php handles foundation/health/venue-facing routes, while src/controllers/AccountOrderController.php owns account and draft operations. These are separate from WordPress core editorial APIs and do not make wp_users the customer-identity store.

Customer account operations

The account controller registers anonymous registration, email verification, resend, login and recovery endpoints plus bearer-protected me, profile and logout endpoints. Input must be JSON with bounded fields; credentials are accepted only over HTTPS. The server authenticates a bearer token and derives the caller's customer UUID. It never trusts a submitted customer_id for permission. Public registration and recovery responses deliberately avoid confirming email existence. Verification challenges, credential hashes, sessions and throttling are handled by WordPressCustomerAuthRepository.

Email verification still needs to be consolidated into a dedicated module using wp_mail(). The current controller and account repository implement the API foundation. This difference between current code and intended structure must remain visible to reviewers. Do not add a second mail transport inside a controller. Introduce a channel interface before implementing WhatsApp or other providers, and retain independent throttling, message templates and provider failure handling.

Profile record semantics

WordPressCustomerRecordRepository persists approved field changes in an append-only customer-field table. The originating MariaDB write time and record UUID determine the latest value; the customer UUID is stable. The account controller permits one approved field change per request and returns the current profile from server-side reads. Profiles require a verified bearer session. Do not use this latest-field pattern for payment records or account session revocation.

Order and price boundaries

WordPressOrderDraftRepository creates and retrieves server drafts using stable idempotency keys; it does not claim that drafts are paid or submitted to a kitchen. WordPressMenuPriceRepository is a separate input to server-side pricing. The controller rejects invalid shapes, unauthenticated callers and a reused idempotency key with conflicting contents. Stripe payment modules are separate and remain subject to merchant-account configuration, webhooks and reconciliation testing.

Schema and deployment

src/database/SchemaInstaller.php coordinates additive database migrations. WordPress table prefixing must remain site-specific. Schema scripts, indexes and database time defaults require real MariaDB validation; mock tests are not sufficient. The plugin must not alter MariaDB-wide settings or tables owned by unrelated Virtualmin sites. Migration, WordPress activation, API route availability and previous-version rollback are separate release checks.

What to test when changing this plugin

Run PHP foundation tests and account/order contract tests; then exercise registration, expiry, resend throttling, login, profile authorization, cross-account access, idempotency conflict and database migration against a staging WordPress site with MariaDB. Inspect the actual REST namespace and response status without logging bearer secrets. Test mail delivery through WordPress's configured transport and recovery after SMTP failure. Confirm the documentation publisher and visual presenter can update independently without touching this API schema.

Source files in this module

Maintenance and evidence

Check all affected file references and the matching human-readable user/architecture page when source changes. Run the module’s contract or governance checks; staging, payment and native hardware tests remain independent of source inventory coverage.