v1.2.6

• Require Symfony DependencyInjection 8.1.8 or newer to preserve environment placeholders reused across container extensions. Library consumers now receive the fix without relying on a development lockfile.
• Report the current release version in the standalone CLI.

See the 1.2.6 upgrade notes.

v1.2.5

• Generate native wp-config.php directly in the WordPress core parent (public/ for a public/wp/ layout), eliminating the default root configuration and forwarding loader. WP-CLI, section editing, setup drift and production diagnostics follow the same target.
• Recover literal salts from previous managed native root configurations without executing PHP; retain the root file for rollback. Customized sections, dynamic salt providers, location-dependent salt code and root symlinks require explicit migration. Literal salt edits, legacy profile layouts and alternate configuration targets remain supported.
• Report the current release version in the standalone CLI.

See the 1.2.5 upgrade notes.

v1.2.4

• Keep compiled environment caches and immutable dumps in OPcache on reads. Invalidate only a mutable cache actually rewritten by this process; unchanged writes do not waste shared memory.
• Include the installed Runtime version in generated MU loader and kernel plugin headers for security inventories.
• Production doctor accepts sealed, readable project-owned immutable caches when run as PHP-FPM. Mutable maintenance, external roots, symlinks and group/world write protection retain their ownership boundaries.
• Verify 8,000 warm OPcache reads without a reset and complete two SSH/MariaDB/FPM deployments with the actual PHP identity.

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.

runtime 1.2.2

Runtime 1.2.2 upgrade

Runtime's Doctor and kernel-cache now select the same generation as Kernel
1.1.4, including its durable private per-user fallback. When the optional Kernel
is installed, Composer requires 1.1.4 or newer. Plain WordPress installations
remain supported without Kernel.
Doctor marks unused kernel cache/build directories and their permissions as
not-applicable when Kernel is absent, including plain WordPress installed directly
in the project root. Unused cache overrides do not cause diagnostic failures.

An unsafe explicit APP_CACHE_DIR fails instead of producing a passing diagnostic
or silently selecting another directory. Implicit fallback selection appears as
kernel.cache-migration; Doctor does not create or migrate anything. A missing
selected cache remains unknown until it is warmed. Previously unsafe implicit
generations remain untouched and must not be reused.

For an external deployment cache, provision an absolute APP_CACHE_DIR and
optional APP_BUILD_DIR outside the webroot. Each root must already exist with
mode 0700 and belong to the PHP-FPM user. Run diagnostics, explicit maintenance
and warmup as that same identity. Symlinks in roots or ancestors, parent traversal,
foreign directory owners and group/world writable directories are rejected before
any deletion. External ancestors must be protected, belong to the calling user or
the system root user, and have the sticky bit if shared writable. Only the selected
environment's kernel directory is cleared;
other environments and sibling asset caches are preserved.

Standalone checks also reject known WordPress core/content and conventional
public cache locations without loading WordPress. Declare a custom server root
with doctor --webroot; Runtime does not inspect the web server configuration.

Doctor checks the calling identity and filesystem namespace. Its readable cache
check does not prove complete warmup or access from a different PHP-FPM UID or
service namespace. Validate the deployed web process separately before traffic
switches. Generic Runtime artifact writes remain confined to the release project.

Validation includes a real Kernel 1.1.4 compiled container, safe external cache and
build roots, fallback warning and read-only diagnostics, unsafe-root failure before
deletion, and preservation of other environments and assets. Hosted release and
consumer acceptance are separate checks.

SymPress Runtime 1.2.1

Compiled environment templates refresh interpolated process values on every warm request without persisting value-derived fingerprints. Production Doctor checks the signing key, trusted proxy handling includes mapped IPv6, and a read-only EnvironmentInspection API exposes the same file/cache precedence safely.

Validation: complete PHP QA, 1381 tests/10091 assertions with real WordPress and database; cold/warm/rotated-template benchmark, documentation contracts and leak/rotation regressions passed.

v1.2.0

• Enable WordPress hardening, disallow unfiltered HTML/uploads and block outbound WordPress HTTP by default in Composer-managed production. Only api.wordpress.org,downloads.wordpress.org are admitted until an operator supplies a complete project-specific allowlist.
• Preserve explicit supported overrides and the native profile; production doctor rejects unsafe hardening, upload, HTML and outbound-HTTP overrides.
• Includes the previously unreleased 1.1.4 interpolation-cache, offline Roots installation and production diagnostics fixes listed below.
• Upgrade note: review API-host needs before deploying. Starter now separates its optional legacy content cleanup from hardening; templates that copy older MU hooks must make the equivalent split before enabling production hardening.

v1.1.3

• Keep probed database status reader-local and out of environment caches so a cold WordPress install cannot retain pre-install status in later diagnostics.
• Reload native ordinary caches after a generated Runtime payload change, preserving explicitly configured flags and existing format-1 deployment dumps.

v1.1.1

• Describe the production and database health flags in diagnostic help, including the requirement for --quick, and identify check as an alias of doctor in command listings.
• Update the README, release guides and maintainer documentation.

v1.1.0

• Support Symfony Console list, help, command-specific help and shell completion without interpreting them as setup steps.
• List every Runtime operation with its own description; retain direct step selection and add explicit run [steps] syntax for command-like custom step names.
• Keep help and command discovery read-only, including before package layout recovery and when setup configuration is invalid.
• Verify command discovery and help through the native WP-CLI bridge.

See the 1.1 upgrade notes.