ReleaseCaller
Corex\Config\Releases\ReleaseCaller · class · Config layer
How the request in hand was signed in, and whether this site lets an Application Password install a release (spec 123, FR-014 and FR-014a; DECISIONS #512). The Releases routes were the screen’s alone: a request needed the nonce of a signed-in admin page. A site whose wp-config.php defines COREX_ALLOW_RELEASE_PUSH as true also lets a command on the owner’s machine use them, signed in with an Application Password over HTTPS. The switch is a constant and not a setting, because a setting could be turned on over REST by the very credential it lets in.
Public API
Section titled “Public API”__construct(bool $pushAllowed, ?Closure $nameOf)
Section titled “__construct(bool $pushAllowed, ?Closure $nameOf)”ofThisSite(): self
Section titled “ofThisSite(): self”pushAllowed(): bool
Section titled “pushAllowed(): bool”applicationPassword(): ?string
Section titled “applicationPassword(): ?string”The name of the Application Password WordPress signed this request in with, or null when it was signed in some other way (a cookie) or not at all.
overHttps(): bool
Section titled “overHttps(): bool”WordPress keeps Application Passwords off plain HTTP unless the site is a local one, and a plugin can lift that with a filter. A release replaces code, so its routes keep the rule.