Two lint suppressions shipped with the multisite OIDC work. Both are replaced
by the thing they were standing in for.
settings.php claimed an exemption from the mirrored-test rule because every
call it makes belongs to the WordPress runtime. The six functions stub in a
few lines, so the claim does not hold. SettingsTest.php declares WP_CLI and
the globals over a state holder and includes the real payload per case:
* a single site is written without switching blogs
* every site of a network is written, switch_to_blog paired with restore
* a site whose write does not persist is named by blog id
* every site is still visited before that failure is reported
* a payload that is not a map halts, and so does an absent one
The fourth case is the one worth having: a `break` on the first failure would
pass the other three and silently stop writing.
Neither existing house pattern fits. `eval` suits the tag-less tinker snippet
of web-app-akaunting, `proc_open` the standalone script of web-app-joomla;
this is a tagged file that needs a runtime, so it is stubs plus `include`,
which also avoids the `nocheck: eval` the akaunting test carries.
The installer test's cache-read exemption rested on a cached read serving a
stale call log. Measured, that risk is confined to the suite and sits around
3e-13: the log lives in a fresh TemporaryDirectory per run, mkdtemp verifies
non-existence, and each path is read once. What complying actually costs is
roughly 25 dead entries in an 8192-slot LRU, so the read goes through
utils.cache.files.read_text.
Proven by `make test-unit-php`: 32 tests, 68 assertions. The first version of
this test passed nothing at all -- it sits one directory deeper than the
other PHP tests, so dirname(__DIR__, 6) resolved to tests/ and the include
found no file. Without the test that would have stayed invisible.
The suite drives stubs, so it proves the payload's control flow and not that
WordPress behaves as stubbed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Variant 1 of run 37440146966 leaves the persona on the login page:
Expected substring: "/wp-admin"
Received string: "https://blog.main.infinito.test/wp-login.php"
The rescue bundle shows 62 requests to /wp-login.php, all 200, and not one
OIDC request. Every login asset loads, so the page renders in full and simply
offers no SSO entry point; the flow never reaches Keycloak.
Variant 1 is the Multisite variant, and that is the whole difference. The
plugin reads its configuration with get_option, not get_site_option:
includes/openid-connect-generic-option-settings.php:125
$this->values = (array) get_option( self::OPTION_NAME, $this->default_settings );
The option is therefore per site. The addon stored it once, so a subsite read
an empty openid_connect_generic_settings and rendered a login page without an
OIDC entry point. Variants 0 and 2 are single-site, which is why only #1
failed.
Three shell tasks collapse into one PHP payload, following the pattern
ai-engine-stack-host.yml already uses in this role: the settings ride as
base64 in an env var and the body streams on stdin into `wp eval-file -`.
The payload walks the network with get_sites()/switch_to_blog() instead of
enumerating sites in the shell and passing --url per site, which removes the
nested quoting that broke this task once before (03ed52eea5).
The task that seeded a PHP-serialized empty array is gone: update_option
creates an absent option by itself.
Writing to a site whose option does not persist used to be silent. The
payload now reads each site back and names the blog ids that stayed empty, so
a failed write fails the deploy instead of producing a login page nobody can
use.
The settings carry OIDC.CLIENT.SECRET and the three old tasks had no no_log
at all, so the base64 secret reached every deploy log; the task now masks when
MASK_CREDENTIALS_IN_LOGS is on.
Static only. No deploy has run this.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kevinveenbirkenbachandClaude Opus 5