Simplify SQLite installation caching

[JanJakes]

SQLite Database Integration 3.1 will introduce randomized database directories, with db-path.php recording the location relative to its own directory. The .sqlite cache snapshot currently looks for .ht.sqlite and .ht.sqlite.php in wp-content/database. With randomized storage paths, that snapshot is never created, so the installation cache is considered invalid, and each scenario repeats wp core install.

Upon a closer look, it turns out the separate SQLite cache snapshot is not needed, because the SQLite database is already part of the WordPress install snapshot. Removing the duplicate .sqlite snapshot with the fixed-filename lookup simplifies the logic and makes SQLite database caching work also with the new randomized storage.

A focused regression scenario checks path preservation and independent databases across a cold installation and two warm restores. It was tested against the merged SQLite plugin code and releases 3.0.2 and 2.2.23.

Related: WordPress/sqlite-database-integration#502 and WordPress/sqlite-database-integration#512.

Summary by CodeRabbit

• Bug Fixes
  • Reusing a cached SQLite installation now starts with the default site name, rather than carrying over a name from a previous use.
  • Installations renamed to “first” and “second” retain their respective site names when the same cached installation is reused.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

🧰 Additional context used

📚 Code guidelines (1)

AGENTS.md — auto-discovered

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: a7091b00-521b-4ede-b611-805b4a91553c

📥 Commits

Reviewing files that changed from the base of the PR and between 3384827 and a9af46b.

📒 Files selected for processing (2)

• features/testing.feature
• src/Context/FeatureContext.php

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The install cache now treats the installation directory as the cache unit. SQLite databases remain within that directory, and a new scenario checks repeated reuse and site names.

Changes

SQLite install-cache reuse

Layer / File(s)	Summary
Cache directory reuse src/Context/FeatureContext.php, features/testing.feature	Cache hits copy the cached installation directory. MySQL/MariaDB cache hits still restore the SQL dump. SQLite sidecar validation, restoration, and export are removed. A new scenario checks repeated reuse and verifies the database file and site names.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~15 minutes

Change: Bug fix

Suggested reviewers: swissspidy

Merge Risk: ⚪ Minimal · up to a9af4

The change simplifies SQLite install caching in the test harness and adds a scenario that checks reuse and site-name isolation. No merge-blocking risk is identified.

Security Architecture Review

Security architecture risk: 🔵 Low · up to a9af4

The change remains within the local test harness and does not establish new remote exposure or increased privileges. Successful restores retain database isolation, but removing the SQLite readiness check allows an incomplete cache directory to be reused after a publication failure.

Retained concerns

• Low · reliability · inferred: An incomplete SQLite cache can survive a failed publication and be accepted by a subsequent matching installation. The directory is created before copying finishes, but directory existence now means ready for reuse. The base's later-written SQLite sidecar rejected this state and triggered cleanup. This weakens failure containment across scenarios, although suite-start cleanup bounds its lifetime.

Security review details

Security Blast Radius

• inferred — The demonstrated exposure is the test runner's temporary installation cache and scenario WordPress fixtures. The inspected caller is a local feature step, not a remote application endpoint. Cross-runner filesystem sharing and isolation are not established.

Trust Boundaries and Controls

• inferred — Cache contents are trusted fixture state copied into an installation. A principal able to replace those contents could already influence restored files at base; the sidecar supplied no authenticated provenance. The PR weakens completion checking, but increased attacker reachability or authority has not been established.

Hardening Proposals

• proposed — Publish a completed snapshot from a staging directory, or use a filename-independent completion marker with cleanup on failure. If overlapping execution is supported, coordinate publication and suite cleanup so readers cannot consume unfinished snapshots.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: simplifying SQLite installation caching.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (1 skipped: 1 …
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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.}

[github-actions]

Hello! 👋

Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this project.

Contributing isn't limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

Here are some useful Composer commands to get you started:

• composer install: Install dependencies.
• composer test: Run the full test suite.
• composer phpcs: Check for code style violations.
• composer phpcbf: Automatically fix code style violations.
• composer phpunit: Run unit tests.
• composer behat: Run behavior-driven tests.

To run a single Behat test, you can use the following command:

# Run all tests in a single file
composer behat features/some-feature.feature

# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123

You can find a list of all available Behat steps in our handbook.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Context/FeatureContext.php	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[swissspidy]

Thanks a lot!