Create an API endpoint for the currently available designs

[ramonjd]

Outcome

To create an endpoint will return a collection of objects containing design metadata (e.g. pretty similar to what’s in available-designs-config.json).

The list of available designs, and the metadata associated with them, should be stored somewhere in the backend. The source site of the templates should be stored alongside the template slug, etc, so that this site can be used for both the Headstart annotations and previewing the template.
Citation: pbxlJb-cH-p2:

Gutenboarding should pull the available designs from the server via an API, instead of them being hard-coded in Calypso.

This will ensure that the backend and frontend have a canonical source of current templates, the linked themes, and source sites, to be used for both Headstarting a new site, and the template/demo endpoint.

With this metadata stored in the backend, we can use it as the basis for writing proper PHP tests for our endpoints, and make sure that nothing breaks.

Master thread: pbAok1-16B-p2

Code

D49406-code

[ramonjd]

I've done this for page-templates/templates.

I'm yet to find an urgent case to deliver available-designs from the backend.

[ramonjd]

Some work to combine/simplify template JSON data has been done over at #40587

[ramonjd]

This task could form the basis of our MVP work, if only to have the endpoint ready.

This hard-coded file should be replaced by an API endpoint. This endpoint can provide translated versions of the theme titles. We will also need to add in a translated theme description, to be used as alt text on the theme preview images in the Design step

pbxlJb-fl-p2#comment-247

[lsl]

Starting with D45534-code ripped from D44864-code.

[ramonjd]

p1593392117122500-slack-CRWCHQGUB

Some related discussion in that thread

[lsl]

Disabled the endpoint and deployed D44864-code as is, simplicity.

[ramonjd]

I think we need to scope out a "design" separately from a "pattern".

Source: p1593392117122500-slack-CRWCHQGUB

@lsl makes a good distinction, which I've only just managed to grok: for the MVP, we're primarily dealing with Gutenboarding "designs".

These "designs" encapsulate extra information, such as "theme" and "fonts" and whether a design is "featured" or "premium" or whatever.

This information is required in the context of Gutenboarding but nowhere else.

E.g.,

	{
			"title": "Reynolds (FSE)",
			"slug": "reynolds-fse",
			"template": "reynolds",
			"theme": "seedlet-blocks",
			"fonts": {
				"headings": "Playfair Display",
				"base": "Fira Sans"
			},
			"categories": [ "featured", "portfolio" ],
			"is_premium": false,
			"is_alpha": true,
			"is_fse": true
		},

Other pattern-based entities do not care about this information.

Should we define a "pattern's" base properties and leave it up to the consuming application to extend them? In other words, should a Gutenboarding design object be a superset of a basic pattern?

For example, Gutenboarding requires reynolds-fse. This might be a general description of a base pattern:

     "title": "Reynolds (FSE)",
     "slug": "reynolds-fse",
     "categories": [ "featured", "portfolio" ],
     "template": "reynolds",

Gutenboarding should therefore know how to extend reynolds-fse with:

			"theme": "seedlet-blocks",
			"fonts": {
				"headings": "Playfair Display",
				"base": "Fira Sans"
			},
			"categories": [ "featured", "portfolio" ],
			"is_premium": false,
			"is_alpha": true,
			"is_fse": true

As far as this task is concerned, we're trying to solve two tasks:

1. To move the source of truth about what a Gutenboarding design is to the backend. The backend will eventually use that source of truth in order to fetch and categorize block HTML.
2. To provide the frontend application with a means to receive a list of available patterns based on an API query. Example only!!! /patterns?category='gutenboarding-design'

The easiest path for now might be to return the exact value of available-designs-config.json, and worry about future requirements, well, in future iterations.

These are just my thoughts... leaving it open to debate.

[lsl]

Some more work on this began in D45748-code, the API portion has now been spun off to D45750-code.

For now I'm working more on D45748-code to nail down more of the internals before implementing more in D45750-code.

D45750-code will likely depend on D45748-code.

D45750-code should result in 2-3 new endpoints to check off this issue (#42922).

[ramonjd]

Look at a way to deliver starter site information to NUX flows: D49406-code

[ramonjd]

Mobile needs this too: pb3aDo-tQ-p2#comment-893

[ramonjd]

D49406-code is ready for review

Future tasks:

• remove the starter sites list in nux-helpers/class-template-helpers and get them from our new class
• call the endpoint in Gutenboarding

@enejb I'm not sure if the endpoint is useful to you, but it's a start. Let us know if it helps as Gutenboarding integration might not happen for a while.

[andrewserong]

D49406-code is working nicely for me, it's exciting seeing this on an endpoint! Just left a few comments/questions about naming, but otherwise LGTM, and I really like the idea of consolidating the starter sites list in this class where it's a bit of a clearer home for it 😀

[ramonjd]

Closed by D49406-code

[lsl]

^^