…lder

Extract every legacy mu-plugin and SQLite preload setup from
index.ts into dedicated files under legacy-wp/:

  * legacy-mu-plugins.ts — setupLegacyPlatformLevelMuPlugins,
    LEGACY_AUTO_LOGIN_BODY, legacy preload env.php, PHP 5.2
    error handler, legacy auto_prepend_file.
  * legacy-sqlite-preload.ts — preloadLegacySqliteIntegration,
    buildLegacySqlitePreload, mysql*/mysqli* stubs, str_*
    polyfills, WP < 3.1 add_action() guard.

Shared helpers live in neutral files at src/ root so legacy-wp/
doesn't import from the parent index.ts:

  * platform-mu-plugins.ts — writeCommonPlatformMuPlugins
    (0-playground.php, sitemap-redirect.php,
    inline-tinymce-content-css.php), called from both paths.
  * sqlite-preload-loader.ts — SQLITE_PRELOAD_LOADER_CLASS,
    referenced by both modern and legacy preload builders.

setupPlatformLevelMuPlugins and preloadSqliteIntegration now
dispatch to the legacy helpers at the top and their bodies carry
no phpMajor / isPhp52 branches. index.ts goes from 1521 lines to
691.

Also drop the WP 5.0–6.1 db.php placeholder.
backportWpPreV62MysqlCheck used to write an empty
wp-content/db.php so install.php step=2's \$mysql_compat check
would fall through its file_exists(WP_CONTENT_DIR . '/db.php')
escape hatch. The placeholder was never needed —
WP_SQLite_DB::db_version() returns '8.0' (per the SQLite plugin's
docstring: "it returns mysql version number, but it means nothing
for SQLite. So it returns the newest mysql version"), which
satisfies install.php's version_compare check directly via the
lazy-\$wpdb loader. With this change no file is ever written to
wp-content on the modern boot path.

Reviewed every patch in legacy-wp/legacy-fixes.ts (and supporting files)
for need, gating tightness, and comment clarity. Net: 4828 → 3637 lines.
Verified WP 1.0–4.9 + PHP 5.2 still boot end-to-end.

Notable changes:
- Drop ensureLegacyAdminAuth — duplicated the auto-login flow already
  provided by legacy-mu-plugins.ts.
- Drop the wp_check_mysql_version no-op — mysql-shims.ts already
  returns '8.0.0' from mysql_get_server_info.
- Drop the dead overrides array in patchWpAdminRelativePaths — the
  generic regex pass already covers every entry.
- Drop duplicate mysql_/mysqli_/str_* stubs from generateDbPhpContent —
  the 0-sqlite.php preload runs first and already defines them.
- Promote `mail` to LEGACY_PHP_DISABLED_NETWORK_FUNCTIONS so it's
  blocked across the whole boot lifecycle, and drop the wp_mail no-op
  in patchWpInstallMailCrash (PHPMailer's SMTP fallback also dies on
  the disabled fsockopen, so it now fails safely with a WP_Error).
- Drop the dead collapseWp1xInstallerSteps helper — install.php is
  never reached during legacy boot, and runPostInstallLegacyFixups
  seeds the admin user via PDO so a manual visit short-circuits to
  "Already Installed".
- Drop the dead `if (!\$_pg_skip_redirect)` redirect branches from all
  three eras of LEGACY_AUTO_LOGIN_BODY — playground_load_mu_plugins
  unconditionally defines PLAYGROUND_SKIP_AUTO_LOGIN_REDIRECT before
  invoking the body in legacy contexts.
- Restrict playground_legacy_set_auth_cookies_early to WP < 2.5; the
  wordpressuser_* cookies it sets are inert on later versions.
- Share legacyAuthCookieBlock(usernameExpr) between
  patchAdminAuthRedirect and patchAdminAjaxAuth; replace their brittle
  wp-settings.php text scans with readOnDiskWpVersion gates.
- Move every WP-version-specific gate out of the patch functions and
  into patchWordPressSourceFiles — the orchestrator now reads the WP
  version once and dispatches each patch only when its range matches.
  The previously needle-only patches (e.g. patchWp10*, patchWp21*,
  patchCheckAdminReferer) get explicit ranges too, so they short-circuit
  at the front door instead of reading files they can't apply to.
- Replace the fragile one-level-nesting regex in patchCheckAdminReferer
  with a reusable balanced-brace helper (replacePhpFunctionBody), reused
  by the "not installed" die() and the do_action('init') rewrite
  extracted out of patchWpSettingsPhp.
- Fix patchWpSettingsPhp bug where settingsChanged was set
  unconditionally inside the error_reporting block, rewriting
  wp-settings on every boot.
- Split the PHP 5.2 vs 5.3+ error-handler boilerplate in
  legacy-mu-plugins.ts into named helpers instead of inline ternaries.
- Trim multi-paragraph "## The bug / ## The fix" docblocks to a single
  why-sentence each, dropping embedded WP source samples and
  indentation diagrams.

Spell out in the top-of-file doc block that the legacy patches run
as plain, idempotent string replacements without parsing PHP, why
this relies on legacy WP releases being frozen, and point at the
boot-smoke suite as the safety net for changes here.

Guards against Playground writing its own db.php, object-cache.php,
advanced-cache.php, or sunrise.php into a user-mounted wp-content.
Studio and similar consumers mount real wp-content directories
into Playground, and a stray Playground-managed drop-in there would
silently take over the user's external site.

Two targeted changes that remove ~2/3 of the per-version wall time:

- Drop waitForWPFrame's 3 s poll granularity down to 500 ms, so the
  loop reflects how fast Playground actually responds instead of
  always burning whole 3 s ticks.
- Replace the two unconditional waitForTimeout(8000) waits after
  post-click (Phase 2) and plugin-activate click (Phase 5) with an
  event-based wait: waitForWPFrame now accepts `excludeUrl` (skip
  the scoped frame while its URL still matches the pre-click value)
  and `contentPredicate` (require specific outcome text before
  returning, so we don't race the intermediate admin shell between
  POST and post-redirect render).

Phase 5 also explicitly waits for any Activate link to become
visible before selecting one — navigateViaUrlBar returns as soon
as plugins.php has any body text, which on slow CI boots can be
just the admin shell before the plugin list is populated.

Local run on 7 representative versions (6.2, 6.1, 6.0, 5.9, 5.8,
4.9, 3.2) goes from ~33 s/version to ~10 s/version, all 5 phases
pass including the ones that flaked under the prior code.

The SQLite integration plugin ships with MySQL 8 strict defaults
(NO_ZERO_DATE + STRICT_TRANS_TABLES + ONLY_FULL_GROUP_BY), but
legacy WordPress (1.0–4.9, contemporary with MySQL 4.1–5.6) was
written against empty or near-empty sql_mode defaults. Three
`patchWp*ZeroDate*` helpers were previously patching every
wp_insert_post() variant that emits '0000-00-00 00:00:00' for
drafts, just to make those INSERTs pass.

Reset the driver's default `active_sql_modes` to `array()` once
during SQLite preload for legacy PHP boots. One regex on the
driver source, two source variants (standard multi-line and the
php52-downgraded single-line form) covered by the same needle.
WP 3.9+ already achieves the same effect at runtime via
wpdb::set_sql_mode(), so the relaxed driver default is a no-op
there and strictly an improvement for WP < 3.9.

Net: -213 lines in legacy-fixes.ts (three patch functions +
their needles), +39 in legacy-sqlite-preload.ts. Smoke test
across WP 1.5 / 2.1 / 2.5 / 2.8 / 3.2 / 3.5 / 4.0 / 4.1 all
pass on PHP 5.2.

Phase 3 (wp-admin dashboard load via URL bar) has been flaking on
shared CI runners for one random modern-WP version per run — 5.5,
5.9, 6.0 across recent runs, always with the same empty-detail
`admin [TIMEOUT]` after the full 120 s navigateViaUrlBar budget.
The iframe gets stuck partway into the first /wp-admin/ load and
never progresses; a fresh URL-bar fill+Enter almost always unsticks
it on the second try.

Retry once on timeout inline. Cheap and keeps real admin failures
visible — the retry only kicks in when the first attempt returned
null, so a genuine admin-page error still reports as the specific
failure mode (ERROR / UNKNOWN) rather than getting retried.

Three provably-dead snippets removed from the legacy boot path:

- PLAYGROUND_SKIP_AUTO_LOGIN_REDIRECT: defined in env.php but never
  read anywhere. LEGACY_AUTO_LOGIN_BODY has no redirect branch that
  would consult it. Delete the define() and collapse the misleading
  docblock to describe what the code actually does.

- waitForAdminFrame(): 47-line helper in the legacy boot smoke test,
  never called. Phase 3 uses navigateViaUrlBar + waitForWPFrame.

- str_contains/str_starts_with/str_ends_with polyfills in the legacy
  SQLite preload: the downgraded v2.2.22-php52 plugin ships identical
  function_exists-guarded polyfills in its own php-polyfills.php, and
  no code between the preload and the lazy-wpdb first touch calls
  str_*. The preload copies were redundant.

playground-wordpress build + lint + 80/80 unit tests stay green.

env.php's playground_legacy_set_auth_cookies_early runs via
auto_prepend_file before every PHP script (including the source-
patched wp-admin/admin.php and wp-admin/admin-ajax.php). For WP <
2.5 it already populates wordpressuser_/wordpresspass_ cookies,
which are identical to the USER_COOKIE/PASS_COOKIE constants
WP 1.5–2.4 reads (both resolve to wordpressuser_\$cookiehash /
wordpresspass_\$cookiehash). So the USER_COOKIE and COOKIEHASH
elseif branches of legacyAuthCookieBlock were re-setting cookies
that were already there.

Keep the HMAC branch (WP 2.5+) and the \$_pg_user=null default;
drop both elseif branches. Smoke test across WP 1.2 / 2.1 / 2.5 /
4.9 / 6.2 unchanged.

The legacy error handler had two builders — buildPhp52ErrorHandler
(named function + \$GLOBALS) and buildModernErrorHandler (closure
wrapped in call_user_func) — chosen by isPhp52. The named-function
form works on every PHP version from 5.2 through 8.x, so the split
is unnecessary.

Drop buildModernErrorHandler and the isPhp52 flag; emit the
named-function form unconditionally. setupLegacyPlatformLevelMuPlugins
no longer needs its phpVersion option.

Neither has anything to do with SQLite; both were sitting at the
tail of buildLegacySqlitePreload for historical reasons.

 * SERVER_PROTOCOL default moves to the legacy auto_prepend_file
   (next to the other \$_SERVER / register_globals polyfills), so
   it's set before preloads run and on every entry point — HTTP
   requests, php.run() fixups, CLI scripts.

 * date.timezone moves into applyLegacyPhpIniOverrides as an ini
   entry, guarded so a caller-supplied value still wins.

No runtime behaviour change on any tested WP version; smoke test
across WP 1.2 / 2.1 / 2.5 / 4.9 / 6.2 still green.

…IMS_PHP

The four connection stubs that legacy WordPress (<3.0) needs for
wpdb::__construct to not bail() on a falsy return were inlined at
the top of buildLegacySqlitePreload, while the rest of the mysql_*
family lived in MYSQL_SHIMS_PHP. Split by historical accident, not
by design.

Move the four connection stubs into MYSQL_SHIMS_PHP at the top
(connection stubs first, then query/result stubs). The preload
emits the same PHP output as before, but there's now one source of
truth in mysql-shims.ts for every mysql_*/mysqli_* shim.

The newly-tagged v3.0.0-rc.3 release ships AUTO_INCREMENT value
management (sqlite-database-integration#367):

  * SHOW TABLE STATUS LIKE returns a real Auto_increment computed
    from sqlite_sequence (was NULL).
  * INSERT … VALUES('0', …) into AUTO_INCREMENT columns is rewritten
    to NULLIF(CAST(… AS INTEGER), 0), so MySQL's "0 advances the
    sequence" semantics work on SQLite.
  * AUTO_INCREMENT = N table option support.

These improvements obviate several legacy-WP source patches we
maintained against v2.2.22's behaviour. Bring them into the legacy
PHP 5.2 boot path by retargeting the offline downgrader at the new
upstream zip and renaming the produced artefact accordingly.

Mechanical: SRC_ZIP/OUT_ZIP in patch-sqlite-for-php52.mjs, the
'v2.2.22-php52' literal in the worker endpoint and CLI handler,
the version union in download.ts, and the resolver entry in
get-sqlite-driver-module-details.ts.

Follow-up: drop the now-redundant patches in legacy-fixes.ts.

WP 1.0's wp-admin/post.php emits `INSERT … VALUES ('0', …)` into the
AUTO_INCREMENT `ID` column. v2.2.22 stored the literal 0; we rewrote
the source to NULL so SQLite would pick the next rowid.

v3.0.0-rc.3's INSERT translator now wraps every AUTO_INCREMENT value
in `NULLIF(CAST(… AS INTEGER), 0)` (unless NO_AUTO_VALUE_ON_ZERO is
active). The 0-literal advances the sequence on its own, so the
source patch is a no-op.

Verified: WP 1.0 boot smoke test still PASS on front / post /
admin / new post phases.

Same story as the WP 1.0 patch one commit back: WP 1.2's
wp-admin/post.php inserts a literal '0' into the AUTO_INCREMENT
ID column, and v3.0.0-rc.3 now NULLIFs it transparently.

Verified: WP 1.2 boot smoke test PASS on all five phases (front,
post, admin, new post, plugin activation).

WP 2.0-2.2 install.php / upgrade-functions.php / admin-db.php
inserts the seed category as `INSERT INTO wp_categories (…, cat_ID,
…) VALUES ('0', …)`. v2.2.22 stored the literal 0 and the resulting
cat_ID=0 / category_parent=0 self-loop hung get_nested_categories()
in an infinite recursion.

v3.0.0-rc.3 NULLIFs zero-valued AUTO_INCREMENT inserts at the SQL
translator layer, so cat_ID becomes the next sequence value as on
MySQL. The rewriting source patch is no longer required.

Verified: WP 2.0 / 2.1 / 2.2 boot smoke tests all PASS on the five
phases (front, post, admin, new post, plugin activation), so
neither the dashboard nor the categories admin recurses any more.

The patch did two things, both now redundant with v3.0.0-rc.3:

1. SHOW TABLE STATUS LIKE 'wp_posts' previously returned
   Auto_increment = NULL on SQLite, so we backfilled with a
   MAX(ID)+1 fallback. v3.0.0-rc.3 reads the value from
   sqlite_sequence and returns the real next-value, so
   $id_result->Auto_increment is populated already.

2. WP 1.5's $postquery INSERT omits `pinged` and `post_content_filtered`,
   which are NOT NULL in the SQLite-built schema. v3.0.0-rc.3's INSERT
   translator fills omitted NOT NULL columns with their IMPLICIT
   DEFAULT under non-strict mode (we already clear active_sql_modes
   via relaxSqliteDriverSqlModes in the legacy preload), so the
   handwritten `''` columns are no longer required.

Verified: WP 1.5 boot smoke test PASS on all five phases.