Describe the solution you'd like
Currently, Playground always mounts the SQLite integration plugin at /internal/shared/sqlite-database-integration in its virtual filesystem and never writes it to the site directory on disk. This works well for Playground's own use cases, but makes it hard for embedding tools like WordPress Studio to:
- Run WP-CLI commands against stopped sites - standalone
@php-wasm/node instances can't find the plugin because it's never at a discoverable on-disk path. Tools like wp-cli/sqlite-command hardcode checks for wp-content/plugins/ and wp-content/mu-plugins/.
- Export sites as portable archives - if the SQLite plugin isn't on disk, the exported site won't work when deployed to a real server.
Currently, Studio works around this by managing the SQLite plugin itself - downloading, installing, and updating it independently of Playground. This creates duplication and means Studio has to stay in sync with Playground's own copy of the plugin. It would be much cleaner to let Playground own the plugin lifecycle and simply configure where it lands on disk.
Proposed change: Add an option to bootWordPress (or a related API) to configure where the SQLite integration plugin is placed - for example, sqliteIntegrationPluginPath: 'mu-plugins' - so that embedders can ask Playground to write the plugin to wp-content/mu-plugins/sqlite-database-integration on disk. This would make the site self-contained, portable, and compatible with any standard WP-CLI tooling without requiring custom patches.
Describe alternatives you've considered
No response
Additional context
No response
Describe the solution you'd like
Currently, Playground always mounts the SQLite integration plugin at
/internal/shared/sqlite-database-integrationin its virtual filesystem and never writes it to the site directory on disk. This works well for Playground's own use cases, but makes it hard for embedding tools like WordPress Studio to:@php-wasm/nodeinstances can't find the plugin because it's never at a discoverable on-disk path. Tools like wp-cli/sqlite-command hardcode checks forwp-content/plugins/andwp-content/mu-plugins/.Currently, Studio works around this by managing the SQLite plugin itself - downloading, installing, and updating it independently of Playground. This creates duplication and means Studio has to stay in sync with Playground's own copy of the plugin. It would be much cleaner to let Playground own the plugin lifecycle and simply configure where it lands on disk.
Proposed change: Add an option to
bootWordPress(or a related API) to configure where the SQLite integration plugin is placed - for example,sqliteIntegrationPluginPath: 'mu-plugins'- so that embedders can ask Playground to write the plugin towp-content/mu-plugins/sqlite-database-integrationon disk. This would make the site self-contained, portable, and compatible with any standard WP-CLI tooling without requiring custom patches.Describe alternatives you've considered
No response
Additional context
No response