Explore saving Playground Snapshot as a zip file when saving the post #253
Conversation
|
Please excuse my ignorance but would it be possible to serialize/freeze the current wasm state and resume it vs having to boot from scratch? I suppose it would take more memory? |
It is possible, but booting again would almost always be faster because of the data transfer. The smallest viable heap size is 128MB and a more useful one is 256MB, that's how much data the user would have to download to unfreeze. Also, we'd still have to re-render the relevant wp-admin page as the JavaScript state would be lost and also the last HTTP response generated by PHP would not be included in the heap snapshot. The browser would have to re-request the page anyway and then download any assets, run JS etc. |
|
I just got that to work using media attachments! UX is still very rough and needs a lot more love, but the plumbing seems solid. Each save uploads a new zip file and stores the URL and ID in the block attributes – this way it should still be possible to go back in time using WordPress revisions. On the downside, storing all the exports would take a lot of disk space on the server and most of them won't ever be needed. I'd like to get a better understanding of the workflows this unlocks, e.g. WordPress revisions and git history seem similar so maybe there could a similar flow using Github for storage? Or maybe Playground CLI could have an auto-commit mode every few minutes? I need to switch focus now and won't be driving this to completion in the short to medium term. Feel free to take over. |
…tems (WordPress#253) With this commit, fixing Asyncify issues only requires: 1. Adding a test case that triggers a crash to `packages/php-wasm/node/src/test/php-asyncify.spec.ts` 2. Running: ```bash npm run fix-asyncify ``` The fix-asyncify command: 1. Runs Asyncify test suite that makes PHP trigger an async call through all known code paths. If it works, we're done. If it fails, keep going. 2. Automatically adds any missing C functions to the ASYNCIFY_ONLY list in the Dockerfile 3. Rebuilds PHP 4. Loops to 1 To make it work, this PR: * Converts unhandled Asyncify rejections into catchable errors thrown inside `PHP.run()` * Logs PHP functions at the time of an async call, not at the time of rewinding * Prevents Node.js from exiting or hiding the error message when the WASM module calls exit() ## Follow-up work * Add a documentation page cc @sejas @danielbachhuber
What?
Work in progress. Explores an idea of creating an experience where you’d add a Playground block, configure it as you need (e.g. add a post), navigate to a page, and then press save in the editor and it serializes its state so that people viewing the published post see and continue to use exactly what you saw when you pressed save.
We’d need to either embed a Playground zip export in the post, and that could be a few hundred kilobytes data string, or do a lossy conversion to a Blueprint and include that.
This PR explores the zips export approach. They could be stored either:
This PR doesn't work correctly, but it brings together all the pieces required to make this happen:
This is just a spike to explore the space of possibility. I'm not sure when I'll be able to continue. Feel free to take over.
cc @akirk