Skip to content
Corex

ReleaseStore

Corex\Config\Releases\ReleaseStore · class · Config layer

The installer’s own place on a site: wp-content/corex-releases/ (spec 107, plan D5). incoming/ packages being received, and packages put there by hand staging/ the release paths of the package being installed, unpacked previous/ the folders the last installation replaced discarded/ what an installation set aside to be deleted when nobody is held off for it state.json the installation in progress log.json what happened: installations, refusals, returns (the last fifty) Beside the folders a release replaces, and none of them: the code that starts an installation is replaced by it, and what it was doing has to be somewhere that is not. Not under uploads/ either, where a backup plugin would copy two releases of code into every backup. And not in the database: a release migrates the tables, and the installer must be able to read its own state before and after.

The place itself, made if it was not there and closed to a web server.

Whether the place has been made. Asking makes nothing.

discardUnused(int $before, string $except): int

Section titled “discardUnused(int $before, string $except): int”

Remove what was received and never installed: every package, and every part of one, in incoming/ that was last written before the time given (spec 107, FR-003).

One of the folders, made if it was not there.

Remove everything one of the folders holds, and leave the folder.

Empty one of the folders by one rename: what it held goes to discarded/, to be deleted by discard(). Deleting a release’s files one by one can take longer than a host lets a request run, and this is asked while visitors are held off.

Delete what was set aside, for as long as there is time. What is left is deleted next time.

fileIn(string $area, string $name): string

Section titled “fileIn(string $area, string $name): string”

Where a file of the given name is kept in one of the folders. A name, never a path: what a package is called comes from an upload, and a name that could climb would let an upload choose where on the site it is written.

The packages in incoming/, by name: uploaded, or put there by hand. It reads and makes nothing. This is asked when the screen opens, and the screen has to open on a host where the place cannot be made, to say so.

Do a piece of an installation while no other request does one (spec 107, FR-023). The lock is asked for and not waited for: a request that finds it held is a second tab, a double press or a retry that came too soon, and is told so. It is a lock on a file, so it goes when its request ends, however that request ends.

The installation in progress, or nothing.

What happened here, oldest first.