playground.wordpress.net could default to saving data in OPFS instead of MEMFS to avoid losing progress on page refresh.
Refreshing the page would go back to the last ephemeral site – they could be keyed by some boot parameters like WordPress version. Not necessarily by a starter Blueprint because the Query API -> starter Blueprint conversion will evolve over time.
Explicitly running a new Blueprint would create a new site in OPFS, e.g. /ephemeral-2.
We'd need a UI list of ephemeral sites with date created, wp/php version, last used date. We could also use it for a list of "recently opened" Native FS directory handles from IndexedDB. Here's a low-effort mockup – Playground could have a sidebar similar to the site editor, and then it could also use it for the Blueprints builder, file browser, PR loader, etc:
There would be a Query API param to open a specific ephemeral site. Blueprints would be ignored in context of this already created site – a user would see a modal explaining why the Blueprint cannot be run. On acceptance, we'd reset the URL fragment. This would enable GitHub auth etc without losing progress. Also, swapping PHP version, enabling features, etc.
This would be a „Playground web app” feature. Any embedded remote.html frame would remain ephemeral.
adamziel
commented
1 month ago
playground.wordpress.net could default to saving data in OPFS instead of MEMFS to avoid losing progress on page refresh.
Refreshing the page would go back to the last ephemeral site – they could be keyed by some boot parameters like WordPress version. Not necessarily by a starter Blueprint because the Query API -> starter Blueprint conversion will evolve over time.
Explicitly running a new Blueprint would create a new site in OPFS, e.g. /ephemeral-2.
We'd need a UI list of ephemeral sites with date created, wp/php version, last used date. We could also use it for a list of "recently opened" Native FS directory handles from IndexedDB. Here's a low-effort mockup – Playground could have a sidebar similar to the site editor, and then it could also use it for the Blueprints builder, file browser, PR loader, etc:
There would be a Query API param to open a specific ephemeral site. Blueprints would be ignored in context of this already created site – a user would see a modal explaining why the Blueprint cannot be run. On acceptance, we'd reset the URL fragment. This would enable GitHub auth etc without losing progress. Also, swapping PHP version, enabling features, etc.
This would be a „Playground web app” feature. Any embedded
remote.htmlframe would remain ephemeral.