Page Layouts: Preview in the selector not using current color scheme.

[alaczek]

The Theme team is working on bringing additional color palettes to Varia child themes (see pNEWy-cQp-p2 for details). While testing those, I noticed that when I switched the color palette in the Customizer, those colors were not reflected in the previews in page layout selector.

Steps to reproduce

1. Read pNEWy-cQp-p2 and apply relevant patches to your sandbox.
2. Activate one of Varia child themes (be sure to apply the patch for that theme too).
3. Navigate to Customzier > Colors & Backgrounds and switch to the dark color palette (although this happens with all of them).

4. Save and exit Customizer.
5. Add a new page.
6. Notice how in page layout selector all the previews are using the default color scheme.

What I expected

For the layout previews to use the current color scheme. In contrast, the previews for block patterns are using the selected color palette.

Screenshot / Video

See video: https://cloudup.com/c8fRLK5cP9d

cc @johnHackworth @ianstewart @mendezcode

[simison]

if you need to apply patches to see the problem

Since the issue is from May and color schemes have shipped since then, this probably isn't the case anymore.

This is part of a bigger problem with that UI: just because how that page picker is implemented, previews don't reflect site’s theme either. Previews are static images.

[ianstewart]

I believe @alaczek is referring not the static thumbnail previews but the large editor preview when you've selected a page layout. Like the following example …

On the left is my example site with the Balasana theme active and a dark colour scheme published in the Customizer. On the right is the Add New Page Screen and the preview of one of those Page Layouts.

Fortunately, the Colour Scheme appears to now be loading here. Unfortunately, it appears to be broken-looking with much of the text not displaying correctly.

This appears to be either a theme or template issue.

[ianstewart]

Here's the Editor Styles of the post relative to the front-end of the published page.

It may be an editor style issue in the theme. I'll report it in the themes repo and we can take a look there as well.

[simison]

We're likely re-implementing this view soon so since it's pretty big task, it might make sense to wait a bit.

@ramonjd et co curious for your thoughts!

[ianstewart]

I think the designs I've seen for this don't have the "big preview" so that might just take care of the issue?

[simison]

@ianstewart well all the thumbnails will be new previews. :-)

So in future, the theme that's applied to site, as well theme settings such as colors, will be reflected in thumbnail images.

[ramonjd]

Unfortunately, it appears to be broken-looking with much of the text not displaying correctly.

What's the underlying theme for the above examples?

We're likely re-implementing this view soon so since it's pretty big task, it might make sense to wait a bit.

As far as I understand it, the latest designs for the page picker will show image-based previews (e.g., mshots or otherwise). We're having some success generating the onboarding preview images.

In that case, we'd be taking shots of the original sites and not relying on the demo endpoint, so CSS/JS cross-contamination won't be an issue, at least in the editor.

The demo endpoint will remain on onboarding for now I guess, but there haven't been any reported anomalies with that so far.

[ianstewart]

@ramonjd looks like the underlying theme was Balasana in my comments.

Automattic/themes#2690

[ramonjd]

looks like the underlying theme was Balasana in my comments.

Ah, er I didn't have my reading glasses on 😇 Thanks!

I just wanted to double check the demo endpoint for that theme: https://public-api.wordpress.com/rest/v1/template/demo/balasana/balasana/?language=ko

[davipontesblog]

@p-jackson is this still an issue with the new layout picker launched today?

[p-jackson]

Yes and no. The large preview area no longer exists, so that's no longer a problem. The thumbnails do not however reflect the site's current colour scheme.

The above screenshot is from a site with the Balasana theme and a dark colour scheme enabled in the customiser. However the thumbnails don't have a dark colour scheme (although they are showing what Balasana would look like at least).

After selecting the layout the page is rendered in the editor using the correct colour scheme.

So yes I think some of the issues in this thread are fixed now. The preview no longer looks broken like in some of the screenshots @ianstewart shared. But on the other hand the original issue in the title still exists. The preview does not honour the colour scheme.

Not sure what sort of priority this should be @simison @autumnfjeld. Feels like a new feature for the pattern toolkit would be needed. It is one of the things that would be needed to make the preview more like the real thing, as was discussed here: p7DVsv-aRA-p2#comment-35255

[davipontesblog]

I'd say let's leave it as a feature request then.

[autumnfjeld]

The preview does not honour the colour scheme.

Not sure what sort of priority this should be @simison @autumnfjeld. Feels like a new feature for the pattern toolkit would be needed. It is one of the things that would be needed to make the preview more like the real thing, as was discussed here: p7DVsv-aRA-p2#comment-35255

@p-jackson @davipontesblog
I have a memory of @andrewserong addressing this, such that the preview to matches the theme. Is this update the same thing that is being discussed here?

[p-jackson]

such that the preview to matches the theme
@autumnfjeld yep the previews reflect the theme, but not the current colour scheme, like what's been selected in the customiser.

Some themes have colour palettes (like the example in the issue description) and some themes just let you pick a colour. The pattern toolkit api has a query parameter to specify the theme, but not one to specify any of these custom colour options.

[andrewserong]

I imagine it should be possible to add an additional param to pass in colour information to then apply to the preview in the template/demo endpoint. I guess the thing to be careful with for then passing into mShots is that the more specific the preview, then the more screenshots that get generated and we lose the benefit of caching between different sites, which could result in a longer load time to display screenshots for each user/site?

[p-jackson]

Was just thinking that. And then with the advent of global styles, does that mean we have to pass the entire jsonified global styles config as a query param? May as well say goodbye to caching at that point.

[andrewserong]

May as well say goodbye to caching at that point.

Exactly. At some point, maybe it'd be worth trying out live previews? Though that then comes with an entirely different set of performance penalties. Ah, trade-offs! 😅

[autumnfjeld]

Thanks for educating me @p-jackson 😊. I hadn't thought about / realized how custom colors (or other site customization) would also impact the thumbnail previews being non-accurate.

[simison]

@andrewserong yeah, the performance hit of live-previews is annoyance here indeed. This will be an issue in core as well so it has to be worked out eventually. Here's one recent discussion about using grid format in Gutenberg: WordPress/gutenberg#20477 (comment)

I would imagine using the live rendering some day again, but as it is today, it's not ready for it. If you folks think the work/complexity required to get thumbnails match for colors isn't worth the effort, that's fair!

The design picker API sorts this out by switching to the site where the template is then rendered, so it includes the theme, any custom CSS from that site, color styles, etc. Would it make sense for patterns API to render patterns preview in the customer site's context?

[andrewserong]

Would it make sense for patterns API to render patterns preview in the customer site's context?

It’s an interesting idea. We guarded the existing code a little bit by only rendering within a known set of sites rather than passing in an arbitrary site, where it might not be guaranteed to work properly (e.g. calling out to Atomic sites is probably a no-go).

Before venturing further into making screenshots unique to the site, we might want to look at the math on number of individual sites x requests to add a new page x number of page layouts on offer, as we could wind up generating a very large number of screenshots and mshots is currently set up to expect a fair bit of caching. So there could be server-performance considerations to take into account there, too.

Definitely interesting ideas worth exploring, though.

[simison]

@andrewserong Right, fair points! Lots of potential complexity with theme switching, Atomic, and whatnot.

At the same time, here we are talking just about 2 options that matter for templates (footer/header color are not relevant in our case) so it's best not to overcomplicate it too early considering global styles. We'll figure it out when the time comes.

For caching we still have most sites having the same defaults initially, and once those are changed, the cached images stay valid for the same site across requests.

At any rate, this is all stuff more for the team to figure out, and I merely wanted to remind to keep things simple. :-)

[andrewserong]

At any rate, this is all stuff more for the team to figure out, and I merely wanted to remind to keep things simple. :-)

Very good point, thanks for clarifying! Yes, in the shorter term it’d be good for us to look into whether we can pass in the selected colour scheme in an extra param in a simple way to cover the main existing case for a site having different colours :)

[inaikem]

Sweeping feature requests for relevance. Looks good, keeping open.