Port r65373 through r65390 from core

README.md

@@ -131,9 +131,9 @@ and what does not flex.
 
 ## Extending
 
-Three interfaces, outermost first:
+Three abstract classes, outermost first:
 
-| Interface | Replaces | Reach for it when |
+| Class | Replaces | Reach for it when |
 |---|---|---|
 | `WP_Secrets_Provider` | Everything — the platform is the system of record | A control panel, Secrets Manager, or an HSM holds the credential |
 | `WP_Secrets_Keyring` | How the root key is wrapped | A KMS holds your keys, but secrets stay in WordPress |
@@ -151,7 +151,7 @@ never become this project's. Read its README before writing one: a key-managemen
 KMS, Google Cloud KMS) is a `WP_Secrets_Keyring` and takes three methods, while a secret store
 (Secrets Manager, Parameter Store) is a `WP_Secrets_Provider` and takes eight. People routinely
 pick the wrong one and pay for it in per-operation API calls. Start from
-[`examples/aws-kms-keyring/`](examples/aws-kms-keyring/) — it is the smaller interface, and it is
+[`examples/aws-kms-keyring/`](examples/aws-kms-keyring/) — it is the smaller class, and it is
 what most hosts are actually after: key custody moves to the KMS and nothing else changes. Two
 `WP_Secrets_Provider` examples ship alongside it, AWS Secrets Manager and HashiCorp Vault KV v2.
 `make test-examples` runs all three against Moto and a Vault dev server.

bin/install-wp-tests.sh

@@ -97,9 +97,29 @@ install_wp() {
 
 	mkdir -p "$WP_CORE_DIR"
 
+	# trunk is core's src/ from the same wordpress-develop tarball as the test suite,
+	# as core runs its own tests. The nightly zip is built about once a day, so a
+	# test suite from trunk can be ahead of it: on 2026-11-10 the suite's mocks
+	# extended classes the nightly still declared as interfaces, and every test
+	# died in the bootstrap. nightly still means the nightly zip, which is what
+	# a site running the nightly actually has.
+	if [ -z "${WP_TESTS_ZIP_URL-}" ] && [[ $WP_VERSION == 'trunk' ]]; then
+		echo "Fetching WordPress from ${DEVELOP_BASE}/archive/refs/heads/trunk.tar.gz (src/)"
+
+		rm -rf "$TMPDIR/wp-develop-core"
+		mkdir -p "$TMPDIR/wp-develop-core"
+		download "${DEVELOP_BASE}/archive/refs/heads/trunk.tar.gz" "$TMPDIR/wp-develop-core.tar.gz"
+		tar --strip-components=1 -zxmf "$TMPDIR/wp-develop-core.tar.gz" -C "$TMPDIR/wp-develop-core"
+		cp -R "$TMPDIR/wp-develop-core/src/." "$WP_CORE_DIR/"
+		rm -rf "$TMPDIR/wp-develop-core" "$TMPDIR/wp-develop-core.tar.gz"
+
+		download "${MIRROR_BASE}/wp-content/db.php" "$WP_CORE_DIR/wp-content/db.php" 2>/dev/null || true
+		return
+	fi
+
 	if [ -n "${WP_TESTS_ZIP_URL-}" ]; then
 		ARCHIVE_URL="$WP_TESTS_ZIP_URL"
-	elif [[ $WP_VERSION == 'nightly' || $WP_VERSION == 'trunk' ]]; then
+	elif [[ $WP_VERSION == 'nightly' ]]; then
 		ARCHIVE_URL="${MIRROR_BASE}/nightly-builds/wordpress-latest.zip"
 	elif [[ $WP_VERSION == 'latest' ]]; then
 		ARCHIVE_URL="${MIRROR_BASE}/latest.tar.gz"

docs/decisions/0017-abstract-classes-for-the-extension-points.md

@@ -48,6 +48,11 @@ and the class docblocks say so.
 
 - A drop-in changes `implements` to `extends`. Nothing else in the contract changes. 7.2 has not
   shipped, so the only drop-ins affected are those written against the beta or this plugin.
+- A drop-in that still uses `implements` is a fatal error on every request, WP-CLI included. It
+  does not fail closed. PHP reports it while compiling the drop-in, before the `try`/`catch`
+  around the `require` can run. Catching it would mean reading the drop-in's source before
+  requiring it, on every request, which isn't worth it for drop-ins written against a beta. The
+  0.5.0 changelog and the 7.2 beta 5 announcement call it out instead.
 - A drop-in class can no longer extend another base class, such as an SDK client. It can still hold
   one and delegate to it, as the examples already do.
 - The conformance suites, `WP_Secrets_Provider_Conformance` and `WP_Secrets_Keyring_Conformance`,

docs/index.md

@@ -55,7 +55,7 @@ directory holds everything longer than that.
 - [`examples.md`](reference/examples.md) — the AWS KMS, AWS Secrets Manager, and Vault drop-ins, and which to start from.
 - [`host-managed-keys.md`](reference/host-managed-keys.md) — a host owning the site key: environment variable, host keyring, or host provider.
 - [`functions.md`](reference/functions.md) — every function, generated from docblocks.
-- [`classes.md`](reference/classes.md) — every class and interface with public constants and methods, generated.
+- [`classes.md`](reference/classes.md) — every class with public constants and methods, generated.
 - [`hooks.md`](reference/hooks.md) — every action and filter, generated.
 - [`wp-cli.md`](reference/wp-cli.md) — every `wp secret` and `wp network-secret` subcommand, generated.
 

docs/reference/ci.md

@@ -132,7 +132,7 @@ person pasted.
 |---|---|---|---|
 | `static` | 8.3 | — | lint + compat + analyse. Gates everything else. |
 | `test` | 7.4, 8.0, 8.3, 8.5; 7.4 | 7.1.x; 6.8 | Single site |
-| `stand-down` | 7.4, 8.5 | trunk | `make test-stand-down`: core serves the API, and the plugin loads none of its own layer |
+| `stand-down` | 7.4, 8.5 | trunk | `make test-stand-down`: core serves the API, and the plugin loads none of its own layer. Core is wordpress-develop trunk's `src/`, from the same tarball as the test suite, not the nightly zip, which can lag a day behind it. |
 | `test-multisite` | 8.3 | 7.1.x | Multisite suite |
 | `smoke` | 7.4, 8.3, 8.5; 8.3 | 7.1.x; nightly | WP-CLI end to end, single site then multisite. The nightly leg runs the commands on core's implementation. |
 | `examples` | 8.3 | 7.1.x | `make test-examples` against Moto (an AWS emulator) and a Vault dev server, both pinned by digest, single site then multisite. Not part of `make ci`. |