-
Notifications You must be signed in to change notification settings -
Fork two hundred and forty-seven
New issue
v1 WordPress Boot Protocol
#1390
Conversation
adamziel
commented May 14, 2024
•
edited
Loading
edited
What is this PR doing?
How does it work?
-
Mount resources (stage=before WordPress files) -
Unzip WordPress, if that's requested -
Mount resources (stage=before database setup) -
Setup SQLite, MySQL (TODO), or rely on a mounted database -
Run WordPress installer, if the site isn't installed yet
Testing instructions
-
Confirm all the CI checks work -
Load the latest nightly official WordPress build into Playground: http://localhost:5400/website -server/? php=8.0&wp= http://localhost:5400/plugin -proxy.php? url= https://wordpress.org/nightly-builds/wordpress-latest.zip -
Load the official WordPress 6.5 release into Playground: http://localhost:5400/website -server/? php=8.0&wp= http://localhost:5400/plugin -proxy.php? url= https://wordpress.org/latest.zip -
Confirm Playground CLI still works: Run bun packages/playground/cli/src/cli.ts server --login and confirm it loads an installed WordPress.
Follow-up work
-
Replace manual calls to setupPlatformLevelMuPlugins() in unit tests with bootWordPress() -
Add unit tests to confirm boot works with minified WordPress build, official WordPress release, SQLite, MySQL. Test all the BootOptions and confirm PHP.ini directives are used, constants are created etc. -
Remove the createPhpInstance() argument in favor of using just the PHP class – once Breaking: PHP: Remove NodePHP and WebPHP classes in favor of a single "PHP" class #1457 merges -
Figure out storing debug.log in the configureErrorLogging mu-plugin – right now it's stored in /wordpress/wp-content -
Support more database modes: MySQL and custom where Playground relies on db.php brought in from -
Replace hooks with a Mount data type that would have different implementations, like OPFS, Native FS, and Node FS – explorations started in Breaking: PHP: Remove NodePHP and WebPHP classes in favor of a single "PHP" class #1457 -
Once the API settles, document the usage for developers
|
0ef6ea0
ce3e9e5
…PlatformLevelMuPlugins
|
## What is this PR doing? Ships a `DirectoryHandleMount` class that can be used to mount OPFS using the `php.mount()` method: ```ts await php.mount( php.documentRoot, createDirectoryHandleMountHandler(opfsHandle); ); ``` ### Other changes This PR removes the `Mountable` interface in favor of functional API to simplify the implementation and remove any state management concerns. **Before:** ```ts php.mount(dir, new NodeFSMount(dir)); ``` **After:** ```ts php.mount(dir, createNodeFsMountHandler(dir)); ``` ## What problem is it solving? It enables mounting OPFS and local directory handles in the browser version of Playground using the same abstraction as we use for mounting local directories in Node.js. This, in turn, enables using OPFS mounts in the [boot protocol]( #1390 ) and relying on the same general code paths and abstractions. ## How is the problem addressed? DirectoryHandleMount is not a "real" mount in that it doesn't actually plug in an Emscripten FS implementation into the PHP Emscripten module. Instead, it copies all the OPFS files into Playground MEMFS (or the other way around). After that initial sync, it journals all the MEMFS filesystem operations and replays them in OPFS. This is good enough for the in-browser directory handle, since the underlying files aren't going to change on their own, but for the Local Filesystem directory handle we also have an explicit "Synchronize files" button to bring any local changes back into Playground. Once Emscripten supports asynchronous filesystem operations via wasmfs, we'll be about to get rid of the journal and mount an OPFS implementation to directly delegate writes, reads, etc to the underlying filesystem. ## Testing Instructions Open local Playground and change the storage option to "browser", make some visible changes, refresh Playground a few times, confirm the site still loads and the changes are still around. Close the browser, reopen it, confirm it still works. Them repeat the test with the local directory storage option. Also, confirm the following Playground CLI command works and sets up a site in a local `new-wordpress-site` directory: ```bash bun packages/playground/cli/src/cli.ts server --mount-before-install=`pwd`/new-wordpress-site:/wordpress ```