[JanJakes]

Why

Adminer hardcodes /wordpress/wp-content/database/.ht.sqlite, so it can open the wrong database when WordPress uses randomized storage or an explicit DB_PATH.

What changes

Use Playground's runtime database metadata for automatic login and database selection in both Core and Gutenberg sites. Playground records the path after WordPress initializes, preferring DB_PATH over legacy FQDB. Update the database guide accordingly.

How to test this

Platforms: macOS or Windows, using the current head. Local validation ran on Apple Silicon macOS.

Starting state: An initialized Core or Gutenberg site using legacy fixed storage, randomized storage, or an explicit DB_PATH. The latter two require a SQLite integration build with the new storage support; set DB_PATH before WordPress first loads.

1. Click Start dev server, then wp-admin. Create a draft post with a distinctive title.
2. Click DB inspect (Adminer). It should open without credentials and list the site's WordPress tables.
3. Find the draft in wp_posts. Adminer's database path should match the site's configured or generated SQLite path.
4. Repeat for the other launch mode and storage layouts.

What must not have happened: Adminer must not select or create a second database at the old fixed path.

Risks and limitations

No new automated regression test is included; validation relies on the live checks below and Playground's existing metadata contract. Windows was not run locally. The interface is unchanged.

Validation details

Tested WordPress 7.0.1 and bundled Adminer on Electron 43.6.0 in both Core document-root and Gutenberg plugin-mount modes. The latter used a small activation-probe plugin.

Storage cases covered the bundled SQLite plugin, released SQLite integration 3.0.2, and revision 4163f69f3d543ec7d6085bbb0c4e0c36b36c0156 with randomized storage and explicit DB_PATH. The explicit path contained spaces and an apostrophe and overrode a conflicting FQDB. In every case, Adminer selected WordPress's active database and read an option written by WordPress.

An app-level check clicked Start dev server, launched the real server child, and read the saved option through Adminer. Existing Node and Electron suites, lint, and the documentation build passed.

Review outcome

0 [fix here] · 0 [follow-up]. Local review completed across all five dimensions for the final two-file diff: head fbcab67c9025f01e08fe54bc678592cfd19c0801, base 9ee21dd4058bfb879807c54b4373d1c6e5237ce5. No findings. The test omission is intentional; existing suites and lint passed on the reviewed commit.

Related

Playground references: Adminer integration and metadata writer.

• Randomized storage: SQLite integration #502.
• Primary DB_PATH support: SQLite integration #512.
• Part of the compatibility tracking issue: SQLite integration #513.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: WordPress/contributor-toolkit/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 399c5e46-bba5-4383-b73f-5ad21231dcd0

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

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

[zaerl]

Thank you very much 🚢