Declarative Blueprints

Blueprints offer an imperative step-by-step API which is powerful but also complex.

Hypothesis: 99% of Blueprints will only need to declare the necessary ingredients, regardless of the order in which they're applied.

Here's what it could look like:

{
	"landingPage": "/wp-admin/post-new.php",
	"plugins": [ 
		"gutenberg", 
		"classic-editor",
		"https://mysite.com/plugin.zip",
		{ "resource": "url", "https://mysite.com/plugin.zip" }
	],
	"themes": [ "adventurer", "twentytwentyfour" ],
	"activeTheme": "adventurer",
	"login": true,
	"siteOptions": {
		"blogname": "My site!"
	}
}

Let's use this issue to discuss, explore, and iterate on different formats.

Done is

The most important Playground features are covered by the declarative API. In particular:

• Plugins
• Themes
• Site options
• PHP constants
• Importing content
• Importing SQL (? to be determined)
• PHP.ini entries
• Writing a file tree from a URL/filesystem to a directory
• ...anything else?

Open questions

• Should this data format attempt to accept data like posts, custom post types, user meta, and so on? Would that be a feature creep? Or would a rudimentary support be useful, and for more features devs could switch to WXZ, SQL, or PHP code?

Benefits

• Simplicity
• A better foundation for Merging Blueprints in the future

No implementation files or tests are named. Start by reviewing the proposed JSON format, the listed feature coverage, and the open questions; done means the declarative API format and scope are agreed and the important Blueprint features are covered.