Consolidate Blueprint builders

[adamziel]

Let's see what can we consolidate in all the existing Blueprint builders. We have:

• A JSON builder
• A block-based builder by @ajitbohra
• A UI-based builder we call Playground Configuration modal
• Another UI-based builder we call Playground Settings
• Yet another UI-based builder we call "Import from GitHub modal"
• A URL-based builder we call "Query API"
• A CLI-args based builder we call "Playground CLI"

Some of them make sense as separate experiences, others don't. For sure we can reuse a lot of UI components between all the UI builders, and we can reuse a lot of the low-level interfaces between the TypeScript-based builders. Let's use this issue as a space to explore and discuss. cc @brandonpayton @dawidurbanski @bgrgicak @dmsnell

[bgrgicak]

I think that Playground settings should be the only official UI builder we focus on.

Settings should include a builder that allows users to visually adjust blueprints and modify JSON if they have more complex needs.

For visual adjustments, there are two approaches we are taking, forms and drag and drop. I'm wondering if we could have a UI that supports both workflows.

The Query API in my mind is just Website state. It shouldn't be a core Blueprint feature, but it's practical, so we need to document it.

[bgrgicak]

Let's also add the step library to the list. It has some interesting concepts like creating custom steps.

[adamziel]

I think that https://github.com/WordPress/wordpress-playground/pull/1731 should be the only official UI builder we focus on.

We'll still need an "Edit Blueprint" button and the Playground Settings modal is not expressive enough for that use-case. The block editor is. We'll likely need to adopt it at one point to enable the full experience, as in run a Blueprint, edit it, upload a plugin zip from a local directory, submit a PR for the Blueprints directory.

The step library makes perfect sense in Gutenberg. Custom steps would be just custom blocks. Step blocks can be composable via patterns. Predefined sites with customizable parts are just partially synced patterns etc.

[bgrgicak]

Correct me if I'm wrong but we currently only run blueprints during the first boot. If you use storage, we won't run blueprints on the second boot.

In that case should a blueprint builder be part of the Add site form and not part of the settings?

[adamziel]

@bgrgicak There's a few different use-cases here:

• The site settings form in the Add site user flow creates a new site. A full builder would be super useful in there, even if by default the user can only see a few basic settings.
• The Fork site/Blueprint workflow, where the Blueprint builder is populated with a Blueprint and then you can iterate on adjusting it.
• The Edit site settings form where we can only adjust the runtime configuration, not the Blueprint. For example, we cannot change the WordPress version anymore.