Runtime 1.2.3

Runtime 1.2.3 upgrade

For projects that already use the optional Kernel, update Runtime and Kernel
together. Runtime 1.2.3 requires Kernel 1.1.5 or newer because cache metadata and
package discovery now use JSON. Ensure project constraints permit Kernel 1.1.5:

composer update sympress/runtime sympress/kernel --with-all-dependencies

Commit the resolved lockfile and deploy the pair together. Plain WordPress
projects can update Runtime alone; Kernel remains optional.

Runtime now selects warmed read-only caches by meta.json and reports discovery
at discovery-packages.json. Doctor does not execute metadata or create a fallback.
Legacy PHP metadata cannot select an unwritable cache. Explicit kernel-cache
maintenance removes the selected environment's cache/build directories and safe
stale default JSON/PHP discovery after an override. It preserves the unsafe old
generation when Kernel selects its private fallback and validates every target
before deleting any cache.

Classic WordPress document roots and cold read-only releases can select Kernel's
private per-user, per-project cache under the system temporary directory when
the project-local fallback is public or unwritable. Doctor reports that selection
without creating cache directories. Existing roots must belong to the calling
identity and must not be symlinked or group/world writable; external ancestors
must be protected, with the sticky bit on shared writable parents. Maintenance
uses the selected temporary root and preserves the old default cache. Configure
a durable APP_CACHE_DIR when caches must survive temporary-directory cleanup.
Without ext-posix, ownership verification uses a transient tmpfile() / fstat()
probe that is closed immediately; inspection does not persist cache or
configuration writes.

Warm the selected Kernel cache through the application's normal entrypoint as
the PHP-FPM identity before making production files read-only. Composer update
does not run kernel-cache automatically. If the deployment requires a deliberate
clear, run it before warmup:

vendor/bin/runtime kernel-cache

Outbound WordPress HTTP blocking remains explicit opt-in throughout Runtime 1.x.
Production, staging and composer-managed no longer enable
WP_HTTP_BLOCK_EXTERNAL automatically. Existing payment, API and licensing
integrations keep the WordPress default HTTP policy.

Regenerate stock managed sections when upgrading from 1.2.0–1.2.2:

vendor/bin/runtime --no-interaction wpconfig
vendor/bin/runtime doctor --production --webroot=public --json

Customized sections remain preserved. Inspect them for the earlier automatic
WP_HTTP_BLOCK_EXTERNAL=true definition; upgrading the dependency alone does
not rewrite a preserved application configuration.

If caches or deployment dumps from 1.2.0 are still retained, rebuild them to
remove that release's persisted process-value fingerprints. The compiled
fingerprint-free format was introduced in 1.2.1; updating package code alone
does not erase historical artifact bytes.

vendor/bin/runtime flush-env-cache
vendor/bin/runtime dump-env production

Projects that require outbound blocking can enable it explicitly through an
environment value or a predefined constant. Review the complete host list:

WP_HTTP_BLOCK_EXTERNAL=true
WP_ACCESSIBLE_HOSTS=api.wordpress.org,downloads.wordpress.org,api.payments.example

When explicitly enabled, a generated Composer-managed section supplies the exact
core API/download hosts only if the operator has not supplied an override.
Doctor rejects an empty host list, empty entries and global wildcard entries
such as *, ** and *.*. Required integration hosts still need application
acceptance. This policy controls the WordPress HTTP API; other network clients
have their own configuration.

Doctor now names the configuration result
production.wordpress-hardening-switch. A separate
production.wordpress-hardening-activation result is unverified, because
Runtime does not evaluate consumer hook activation. This advisory result does
not alter Runtime preflight's exit status. Exit zero establishes the checked
Runtime configuration; it does not establish application security acceptance.
Runtime does not install or require the private Security package.

The disabled outbound default passes the selected-policy check and marks
production.external-http-hosts as not-applicable. Existing opaque or
customized PHP still requires runtime evidence and yields unknown.