ReleaseMaintenance

Corex\Config\Releases\ReleaseMaintenance · class · Config layer

WordPress’s own maintenance answer, for as long as a site is part one release and part another (spec 107, plan D7; FR-024). WordPress reads .maintenance in the site’s root before it loads any plugin, and answers “briefly unavailable” itself. So no request runs a half-replaced site, and nothing of CoreX has to be working for that to be true. It stops applying by itself ten minutes after the time written in it, which is WordPress’s rule and not ours. The file is PHP that WordPress includes. Ours lets through the one request that carries the installation’s key: the request that finishes the installation on the new release, and the recovery link. Only the key’s hash is in the file. The key is looked for in three places, because a shared host may not hand a request header to PHP (FR-024a): the header as PHP was given it, the header as the web server holds it (getallheaders()), and the address. The first that holds the key opens the gate, and the place it was found in is kept for the request (keyCameFrom()), so an installation’s record says how its key got through. CoreX’s own Maintenance mode is not used. It answers after every plugin has loaded.

Public API

__construct(string $siteRoot)

begin(string $keyHash, int $now): void

Begin answering every request but the keyed one with WordPress’s maintenance page.

end(): void

isOn(): bool

keyCameFrom(): string

Where the gate found the key of this request, when it let it through maintenance; or NOT_NEEDED, when the request came in without it.

file(): string

Where the file is, for the recovery file that removes it when CoreX cannot.