Playground apps

[adamziel]

Surfacing this comment from the WebApp redesign issue:

Long-term idea

Once we figure out merging Blueprints (probably quarters away), we could create a "Blueprint" block and easily create complex setups by inserting and configuring a few blocks.

@akirk the macro/variable-based builder you proposed could then be scoped down to creating a partially synced pattern from a few Blueprint steps and calling that a custom, configurable Blueprint step. We could distribute those using the existing block / plugin directories.

Short-term idea

Let's offer a few ways of creating new Playgrounds using templates.

• "Save as a Template" site feature that would enable starting from a specific state. This would technically export the site as a zip and freeze it in time.

• "Add Blueprint" to store Blueprint JSON that would always install fresh plugins versions.

• "Blueprint Gallery"/"Playground apps" to browse a curated set of Playground setups, like:

  • Markdown documentation editor
  • Blueprint Builder (first JSON, then a Gutenberg-based UI builder)
  • A Theme builder
  • WP-CLI terminal
  • Slide Deck builder
  • PR Previewer
  • IDE setup with code editor and SQL admin

Key point: all would be regular Blueprints using regular WordPress plugins. No setup would be Playground specific. You could create the exact same WordPress setup outside of Playground. This way we'll eventually be able to ship those as desktop, mobile, cloud, and frontend apps as well as plugins for, say, VS Code.

cc @jarekmorawski @akirk @bgrgicak @brandonpayton for visibility. I'm not sure if anything here is actionable right now, I just wanted to make sure this discussion is on your radar.

[bgrgicak]

Once we figure out merging Blueprints (probably quarters away)

I did a simple version of this for the puzzle app.

Steps are the "easy" part, we just append extra steps at the end of the list and ensure there are no duplicates.

The challenge is with other properties like phpExtensionBundles or landingPage. This is where we need to decide which blueprint to ignore. For example when merging phpExtensionBundleswe should use the version that has the smallest chance of breaking, or default to one version every time.
I've done something similar for landingPage, if there were multiple options, I would override it to /wp-admin/.

[adamziel]

Once we're able to load specific PHP extensions, we'll initialize a PHP version with all the extensions needed by all the Blueprints in the mix. I don't think we'll ever want to say "do not load extension Y or it will break".

[adamziel]

For landingPage it could either go to /wp-admin/ or we could require specifying a landing page for the combined Blueprint.