Adapt Behat tests to SQLite integration plugin v3.0.0

[swissspidy]

Why

The nightly Behat runs started failing on all SQLite jobs, on a commit that had passed a few hours earlier (run 31708330441 green vs. run 31762015299 red, both on 893fbd6). Nothing changed here — SQLite Database Integration v3.0.0 was released on 2026-08-13, and wp-cli-tests always fetches the current stable version from wordpress.org. v3.0.0 replaces the old translation layer with a new MySQL-on-SQLite driver, which changes behaviour in two places we assert on.

What changed

post.feature: the SQLite workaround is now the bug. Passing a date in ISO 8601 format used to be stored verbatim by the old driver (WordPress/sqlite-database-integration#52), so the suite carried a separate @require-sqlite copy of the scenario asserting 2005-01-24T09:52:00.000Z. The new driver normalizes it the way MySQL does, so wp post get --field=post_date now returns 2005-01-24 09:52:00 on both. The two scenarios are merged back into a single untagged one, as the comment on the duplicate anticipated.

site-create.feature: two scenarios marked @skip-sqlite. Establishing a database connection now fails when MULTISITE is defined in wp-config.php while the database is still empty:

WP_SQLite_Information_Schema_Reconstructor->get_wp_create_table_statements()
  → SELECT blog_id FROM wp_blogs
  → SQLSTATE[HY000]: General error: 1 no such table: wp_blogs

The reconstructor checks is_multisite() during db_connect() and queries wp_blogs to collect the schema of every site, but that table does not exist yet during wp core multisite-install. The exception leaves $wpdb->last_error set, so is_blog_installed() takes the dead_db() branch and the command fails with "One or more database tables are unavailable. The database may need to be repaired."

Only these two scenarios hit it, because they define MULTISITE up front. The other multisite scenarios install a single site first and then run wp core multisite-convert, so wp_blogs exists by the time MULTISITE is defined. This one is an upstream bug rather than something to fix here, reported as WordPress/sqlite-database-integration#490 — the scenarios carry a @skip-sqlite tag and a note pointing at it, so the tag can come off once it is resolved.

Testing

Run locally against WordPress 6.9 with the SQLite plugin at v3.0.0: features/post.feature 19/19 and features/site-create.feature 18/18 scenarios passing, and the full suite at 445 passed / 9 failed — all nine failures being scenarios that need network access to wordpress.org and s.w.org, which my sandbox blocks.

Summary by CodeRabbit

• Tests
  • Updated publishing scenarios to remove redundant database-specific coverage.
  • Marked initial multisite site-creation scenarios as unsupported for SQLite and documented the related setup limitation.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: f43ee5dc-7191-49af-a657-a87c7f9f5de0

📥 Commits

Reviewing files that changed from the base of the PR and between 8551c9f and 0dda16f.

📒 Files selected for processing (1)

• features/site-create.feature

🚧 Files skipped from review as they are similar to previous changes (1)

• features/site-create.feature

---

📝 Walkthrough

Walkthrough

Updated feature scenarios for database-specific execution. Removed a MySQL requirement and a duplicate SQLite scenario. Added SQLite skip tags and documentation for two multisite site-creation scenarios.

Changes

Database coverage updates

Layer / File(s)	Summary
Post scenario coverage features/post.feature	The date-update scenario no longer requires MySQL. The duplicate SQLite scenario for explicit edit dates was removed.
Multisite SQLite skips features/site-create.feature	Two multisite site-creation scenarios are skipped on SQLite. The feature documents the related SQLite connection failure.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 0dda1

This PR updates SQLite-specific Behat scenarios to match the integration plugin's current behavior and skips two scenarios blocked by an upstream SQLite issue; no actionable merge-blocking risk remains after normal checks and review.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the adaptation of Behat tests for SQLite Database Integration v3.0.0, which matches the main changes.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/entity-command-failing-tests-1wx6gm

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!