OperationsModeStore
Corex\Config\Operations\OperationsModeStore · class · Config layer
Persists the CoreX operations mode and a bounded change audit log (spec 065). The mode is read on every front-end page, so it lives in a prefixed option WordPress loads with the site’s ({@see LoadedOptions}); the audit log, read only where it is shown, is a short capped list of {time, user, from, to} in an autoload-off option of its own. When no mode has been declared, which is no row or a row holding an empty string, it truthfully falls back to wp_get_environment_type(), so the Overview badge shows a real value from the first load. This is the only boundary that writes a mode. Since spec 101 the log also holds the preview link’s events — created, regenerated, revoked — as rows of their own kind: {time, user, event}. They are part of the same story an operator reads here (“who opened the site to the client, and when”), and they never hold the link itself. Since spec 113 a value set in .env (APP_ENV), locked by the network or held by the corex_app_env option decides the environment first ({@see SiteEnvironment}): it fixes the mode to its own environment, except that Coming soon and Maintenance, which change only what visitors see, stay available and in force under any lock.
Public API
Section titled “Public API”__construct(OperationsMode $modes, ?SiteEnvironment $environment)
Section titled “__construct(OperationsMode $modes, ?SiteEnvironment $environment)”current(): string
Section titled “current(): string”The mode in force: what a lock fixes, else the declared mode, else WordPress’s environment type, where local is development.
lock(): ?SiteEnvironmentAnswer
Section titled “lock(): ?SiteEnvironmentAnswer”The setting that fixes the environment, when one does; null when the owner’s choice decides.
allows(string $mode): bool
Section titled “allows(string $mode): bool”Whether the mode may be chosen: a lock allows its own environment’s mode, Coming soon and Maintenance.
isDeclared(): bool
Section titled “isDeclared(): bool”Whether the operator has explicitly declared a mode (vs. inheriting the environment default).
set(string $mode, int $userId): string
Section titled “set(string $mode, int $userId): string”Persist a new mode and append an audit entry. Returns the normalised mode actually stored. Caller is responsible for the capability + nonce gate. A no-change is not a change. Re-applying the mode already in force writes nothing and logs nothing: the history exists to answer “when did this site go live, and who did it”, and a log containing development → development rows stops being able to. The guard lives here rather than in the controller because the invariant belongs to the log. A controller-side check would protect the one caller that goes through it and leave every other caller — a future CLI command, a migration, a test — free to write a fiction. Declaring the mode the site has merely inherited is a real change and is still recorded: it moves the site from following wp_get_environment_type() to stating its own position, which is exactly the transition an operator later wants to find in this log. Hence the isDeclared() term rather than a bare $from === $to.
record(string $event, int $userId): void
Section titled “record(string $event, int $userId): void”Record something that happened which is not a change of mode. Only the events named above are accepted: the log is a closed vocabulary the screen can render, not a place a caller can write free text into.
timeline(int $limit): array
Section titled “timeline(int $limit): array”Everything in the log, newest first: mode changes and events together. A mode change has an empty event; an event has empty from and to.
history(int $limit): array
Section titled “history(int $limit): array”The mode changes, newest first. Events are not mode changes and are left out, so the callers that ask “when did this site change mode” keep getting exactly that.