Wp-calypso: Replace headstarted content on new FSE themes with page templates

[apeatling]

When a new site is created in the test-fse flow, many top level pages with content are also added. Here is an example using Exford:

You can see that this About page is using headstarted content, not a selectable page template because it shows as "Blank" in the sidebar. This should be using the About template instead, and show as selected.

I think we need to go through each page that is created, and replace the headstarted content with a page template as a replacement.

If we don't have a page template, remove the page.

[michaeldcain]

@aidvu: if we generate just the homepage on site creation, will the FSE plugin create the About and Contact pages?

If not, there are already a set of new template sites (a8cht{1-18}) that only use a template-first theme homepage and then selectable page templates for the internal pages. We can run Headstart off of those, but still need to add support for the selectable page template post meta in the Headstart copy method.

[aidvu]

You prolly meant @vindl. Tho it took me a while to figure that out. :laughing:

[michaeldcain]

Hahaha. Sorry Andrija - I don't know what I was thinking. 😬

[michaeldcain]

Patch to add starter template support to Headstart: D36228-code

[michaeldcain]

Patch to update all template-first EN annotations to use simplified content: D36232-code

Non-EN to follow after I merge existing translations.

[michaeldcain]

@p-jackson left a good comment on D36232-code that I think deserves bubbling up for a more public discussion.

Question:

But this change impacts much more than just test-fse. Before if I headstarted my site with Maywood (say through the with-theme flow) then I'd get a menu page. Maybe that's one of the reasons I picked the theme. Feels like this takes us further away from addressing the "my site doesn't look like the theme demo" complaint.

For a visual example, he's asking whether we should give the user a full copy of the demo site (i.e. maywooddemo.wordpress.com/?demo) or one with a matching homepage, and otherwise stripped down starter content (i.e. cainsnuxtest1912055610.wordpress.com)

I intentionally didn't gate the annotations behind the test-fse flow. First, just to curb the proliferation of different possible starter site approaches (vertical content, demo sites, FSE-populated pages), and second, because I think that starter sites need to have a balance of content to keep the homepage true to the screenshot (the only thing most users see in Signup or the template picker and the only thing users get on theme switch), yet the rest of the content generic enough to be applicable to the widest range of users. This is a little bit of a derivation from our "verticalized" approach in previous tests, where we offered these full sites (with food menus or real estate listings) to users that picked a specific vertical.

Ideally, all of those sub-pages that you mention would be selectable templates themselves, and the user could easily add them to their theme (or we could add them for the user), but I'm not sure of what the plan is around adding more page templates.

[iamtakashi]

38029 is somewhat related. If we're not going to give the user a full copy of the demo site, the links (CTA, project thumbnails, etc.) on the homepage templates need to be updated to # so that it doesn't take them to 404.

[davipontesblog]

For a visual example, he's asking whether we should give the user a full copy of the demo site (i.e. maywooddemo.wordpress.com/?demo) or one with a matching homepage, and otherwise stripped down starter content (i.e. cainsnuxtest1912055610.wordpress.com)

To answer this, I tried to step back from what we are working on at the moment, and put myself into the shoes of someone creating a new site, and also thought of what @johnHackworth mentioned about competitor onboarding tools. This goes beyond te scope discussed here but I think it warrants a step back though.

As a user, I see a design, I like it, and I click on it. This is our theme selection (design) step. I might not know what pages are at this point - I just liked the overall feeling of that theme/design perhaps.

It would be great if, as a next step, we now made the user ask themselves this question: What pages do I want on this site? We could provide them with an easy out to just start with:

• A homepage only
• All demo site pages

But as a highlighted option, we now offer this:

• Select your own. This would be really great - we are now teaching them about what they can do with the site here - we are introducing them to the idea of functionality now - we are past design at this point. We can show them options to pick from, and let them know they can add more later: Blog, Contact, About, Services, Team, Menu, Portfolio, etc.

If we do this, we are preparing the user to get to know their site even before it's in front of them, and to learn and understand structure unconsciously. Now they understand the idea of what pages are. They now understand that themes = design, pages = functionality. This in itself is a big learning barrier now in onboarding I find.

I think it's worth exploring this idea and see how it helps people learn how to add pages and manage menus (structure once again).

[noahtallen]

will the FSE plugin create the About and Contact pages?

Yes, when FSE loads itself on a site for the first time (and inserts its default header/footer content), about and contact pages are created if pages with the same title do not already exist.

[noahtallen]

I think it's worth exploring this idea

I think you'll be happy to hear that a lot of folks are digging into this concept! At the Luna meetup this week, this idea came up several times and IIRC, it should make it into one of our onboarding flows. If not 0-FSE, then Gutenboarding.

[jordesign]

+1 to @davipontesblog's suggestion of building out pages/functionality steps if/when can.

RE: @iamtakashi's comment 'If we're not going to give the user a full copy of the demo site, the links (CTA, project thumbnails, etc.) on the homepage templates need to be updated to # so that it doesn't take them to 404.'

It seems as though having links from within the content of templates linked with '#' to be replaced by the user seems most future proof? I guess i is still a step further away from matching the Demo site in its entirety.

[jordesign]

I feel like there's a really clear distinction between theme select during onboarding (Picking based on thumbnail and surprised delighted by any vertical content that matches) and theme switching later on (more likely to check the full demo site and expect their site to look like it).

[p-jackson]

Select your own [pages]. This would be really great - we are now teaching them about what they can do with the site here - we are introducing them to the idea of functionality now - we are past design at this point.

100% this!

I think you'll be happy to hear that a lot of folks are digging into this concept!

Exciting 😻

My worry with D36232-code was that it changes the behaviour of with-theme flow, but that's a very small proportion of signups. Signups coming from the theme gallery is only 0.2% (2344b-pb), so it's probably not a blocker.

[iamtakashi]

It seems as though having links from within the content of templates linked with '#' to be replaced by the user seems most future proof?

Sorry for my poor choice of words. Just to be clear, I meant to raise a question to this approach with the stripped-down starter content because I have the same concern.

[michaeldcain]

@iamtakashi @jordesign: I've updated the template sites to use # for all of their internal links. This change is already reflected in D36232-code, but depending on the decision here might require a different diff to merge.

@noahtallen @vindl: are the "recommended" homepage templates in the template picker pulled from a different endpoint than the other templates?

I'm thinking that the best way forward with this issue (and the best way to address some of the user issues re:template naming and screenshot inaccuracies within the template picker) would be to add the homepage templates to the a8ctm1 source site, using a different taxonomy to keep the two groups separate. Then, there'd be a single source of truth for all of the templates, and we could even go back and update the demo sites to use the correct selectable homepage templates.

I have a .zip of the homepage templates and the current selectable page templates with the neutral Maywood theme and a cropped-out header (since they don't match in the template picker use case). I'd be happy to populate the homepage templates into a8ctm1 if we can agree on the approach. /cc @apeatling @ianstewart

[noahtallen]

the "recommended" homepage templates in the template picker pulled from a different endpoint than the other templates

I think everything gets returned in the same response, so not through a different endpoint, IIRC. See D35170-code for details

would be to add the homepage templates to the a8ctm1 source site, using a different taxonomy to keep the two groups separate

I 100% agree. Fleshing out different categories and putting all the templates in a single source using the existing workflow makes a ton of sense to me.

[vindl]

if we generate just the homepage on site creation, will the FSE plugin create the About and Contact pages?

@michaeldcain yes, provided that there are no existing pages with those titles at the time of insertion.

(missed this notification, catching up I noticed that his has already been answered :) )

[ianstewart]

Closing this issue as it's no longer relevant but gratefully as it's essentially resolved with the new Gutenboarding flow. :)