Starting the HSLG app

The WordPress App Showcase opens the login view first. A new customer selects registration and completes email-code verification before using an authenticated account. The presentation simulates parts of these journeys; real session persistence in the Capacitor app remains blocked on encrypted native credential storage.

Sign-in troubleshooting

Check that the app has HTTPS connectivity, the API staging flag is enabled intentionally, and the account has verified email. A network error must not be displayed as an incorrect-password error. Do not send passwords to support or copy tokens from device storage.

Who this guide is for

This page describes what a customer is meant to encounter on first opening HSLG and the current distinction between the WordPress presenter and the native application. A new customer should be able to register using an email address and password, receive an email verification code, verify the address, and then sign in. The presenter may simulate parts of the account process; a genuinely signed-in mobile session is not accepted until the server, token vault and phone tests pass.

Before opening the application

Use an up-to-date supported Android or iOS device and a network connection capable of reaching the configured HSLG API over HTTPS. A newly installed testing APK should identify its build version and environment so that observations are not confused with the browser presenter. Do not install an unsigned or unexpectedly re-signed package over the intended HSLG application without first checking its origin. If the server is unavailable, the app should explain the network state rather than silently continue with a fictional account.

Registration journey

From the login screen select registration. Enter the requested email and password. The account API accepts a constrained JSON body and responds with a generic message rather than confirming that a specific email address exists. This deliberately protects account enumeration. A customer should see instructions to check their mailbox and enter the supplied one-time code. The verification flow is to be implemented as one modular email-verification unit, using the WordPress mail transport. WhatsApp and other verification channels are future additions, not active alternatives.

If no email arrives, check the spam folder, whether the address was typed correctly and whether the WordPress mail transport is actually configured. Resend must have a visible cooldown/limit and must not expose the existence of an account. A code may expire or become invalid if replaced by a later code. Never ask a customer to disclose the code or password to venue staff or to customer support.

After a successful verification response, the customer can continue to login. The preferred flow is to save optional profile fields, including the customer's name, after authentication rather than interleaving account creation with unverified identity. Do not claim that an account is verified solely because the app advanced to a next screen; the server must confirm it.

Signing in and session state

Use the verified email address and password. The server returns an HSLG bearer session token only when the credentials and verification state are acceptable. The mobile app must store that token in a reviewed encrypted native vault, not a cookie imported from WordPress, a JavaScript global, browser localStorage or a plain text file. Currently this secure vault is an integration blocker, so live native persistence is not yet a completed feature. The app must not display 'successfully signed in' when saving the token fails.

When the phone resumes or restarts, the app should read the approved vault, validate session state and load only the authenticated customer's details. Expired or revoked tokens require a new login. A network failure is not evidence that a password is wrong. The UI should distinguish invalid credentials, service unavailable, code expired and missing device capability where the implementation can safely determine the difference.

Recovering access

Choose password recovery from the login view. Supply the account email, then follow the email code instructions. The API intentionally returns a generic initial response. Submit a valid one-time recovery code and a replacement password to the completion route. A successful password reset revokes outstanding sessions; the phone should discard its previous saved credential and require new authentication. Do not resend credentials by email or expose the chosen password in logs or crash reports.

If an email account is permanently inaccessible, the app needs an approved human identity-recovery policy before staff can offer an alternative. An ad-hoc venue staff override would bypass account security and is not implemented.

Updating personal details

Open Profile after sign-in. The API permits a customer to update one approved profile field at a time. The server derives customer identity from the bearer session; the phone does not send a customer ID that grants its own access. Each accepted field update adds an immutable customer-field record in MariaDB, and the current display value is selected from the most recent original write timestamp. A submitted edit should remain pending until the API confirms it. On failure, preserve the edit in the form and show what must be retried.

Signing out safely

Choose Sign out from Profile. The client should request server session revocation and clear the native token vault. If the network fails during server logout, the client must not imply the server has definitely revoked the token. It should clear local access and communicate that server revocation status was not confirmed. Shared and public phones should not retain credentials or personally identifiable snapshots after logout.

Reporting a fault

Record the build version, phone/OS or browser, stage of the journey, last action, displayed error, and whether the API was reachable. Include a screenshot only after removing email codes, credentials and other secrets. Report whether the failure occurred in the WordPress demonstration, a source-level test or an actual Capacitor APK. Those environments have different capabilities and cannot be used interchangeably as proof.