Wp-calypso: FSE: Update Page Content Sections in Edit and Publish view to match Modern Business

[kwight]

While most of our targeted themes are similar, let's try matching styles in modern Business first. Screenshots of the editor vs publish view should match closely and not have major differences.

To create a site with Modern Business:

• Visit WordPress.com/start/onboarding
• Pick any segment besides blog
• For your vertical type pick a business keyword
• Name your site and select "modern" as the style
• If all went well, the themes tab should display "Modern Business" as active

It's possible to run these themes locally as well.

Noted by @mmtr in #34142 :

The header in page content edit doesn't match the look of the published page.

This is what you get on the published view:

But when editing the page, the dash that separates the title from the description is missing, and the site title link is styled differently:

[kwight]

This may all be related to how we're using styles. Currently, we use as few styles as possible in the editor to get what we need; we may need to investigate pulling in the whole theme (Twenty Nineteen) stylesheet for more consistency and less maintenance.

[glendaviesnz]

I tried pulling in the current theme, at this stage just by adding:

$theme = wp_get_theme();
wp_enqueue_style( $theme['TextDomain'] . '-style', get_stylesheet_uri() );

to enqueue_script_and_style in apps/full-site-editing/full-site-editing-plugin/full-site-editing/class-full-site-editing.php. It does make the styling more consistent between editor and published page, but it messes with some of the editor side panel styles for some reason (see below) - will try and work out why.

[glendaviesnz]

So it turns out that pulling in the full current theme to the editor is not a good approach as it risks pulling in styles with loose specificity - above issue is caused by button:hover styles in twentynineteen theme.

There is a wp-content/themes/twentynineteen/style-editor.css file that is already imported into the editor by default to attempt to align theme styles with editor blocks. One approach would be to add the relevant header and footer styles to this file. But going to see if there is a way to do something similar from FSE end so that theme doesn't need to have any awareness of FSE.

[kwight]

There is a wp-content/themes/twentynineteen/style-editor.css file that is already imported into the editor by default to attempt to align theme styles with editor blocks.

Ah, this what I thought I had checked myself, but doubted because of what I was seeing – thanks for confirming. We might as well keep adding styles to the blocks then (eg. https://github.com/Automattic/wp-calypso/blob/master/apps/full-site-editing/full-site-editing-plugin/full-site-editing/blocks/site-description/style.scss). (You're right, we shouldn't add any FSE-specific code to the theme itself.)

[glendaviesnz]

Had another look at this, and I may be viewing it the wrong way, but it seems like adding this styling direct to the fse blocks is essentially hard-coding the block styles to the twentynineteen theme - which we may be happy with in the short term.

Is another approach to link in a site.css file from the theme - the theme doesn't need to know about individual fse blocks, but to be used by the fse plugin just needs to expose a site.css file?

For example, Twentynineteen already has separate site scss which is imported by the main theme style.css. So we can just add a site.scss file to top level of theme with:

@import "sass/variables-site/variables-site";
@import "sass/mixins/mixins-master";
@import "sass/site/site";

Then add the following to the fse plugin enqueue_script_and_style method:

wp_enqueue_style( 'fse-theme-site-style', get_stylesheet_directory_uri() . '/site.css' );

Have tried this locally, and this pulls in the correct styles to add the dash separator and correct title color when editing the page, and doesn't affect any of the other editor button styles, etc.

[glendaviesnz]

34387 is a related issue which deals with styling of template parts editing views.

[rodrigoi]

I briefly looked into this something like this to fix #34102 and the key here is to expand the _Editor Styles_ (every theme can set their own special editor styles) and add the missing classes, but I didn't find a clean way to do it. I didn't find hooks or actions to refresh the styles, and given the way they are set on the editor initialization, I think it'll be really difficult to implement.

In this case, I think this is a _no-op_. Gutenberg is not a WYSIWYG editor, and having it behave that way is an unrealistic expectation.

[glendaviesnz]

Have split off the template parts editor view to a separate issue #34387, as it is much more complicated. The page content edit view essentially renders the page header content so should be relatively easy to get styling closer to the front-end, but the template parts view currently renders each of the editable blocks, so going to be a much more difficult to match to the front-end.

[glendaviesnz]

Have gone around in circles a bit exploring solutions for this. It would be an easy/quick fix to just add some additional styles each of the fse block scss files - but this essentially hard codes the styles to the current twentynineteen theme we are working against so not scalable/maintainable.

The only alternative i can see to this is to add additional styles into the themes own style-editor.scss. As @rodrigoi found there is now way to hook into these externally - but even if there was there would be a maintenance issue with keeping FSE overrides consistent with theme styles. However adding additional styles to the theme style-editor.scss then means the theme needs to be aware of FSE - what do people feel is the lesser of the evils to pursue here?

[gwwar]

this essentially hard codes the styles to the current twentynineteen theme we are working against so not scalable/maintainable.

For our first iteration this is 💯okay, this is a nice problem to have later if we can get a good flow going here. cc @apeatling

Overall, if we need different styling for our different child themes, it may make more sense to enqueue the editor styles with the child themes. Let's chat with @iamtakashi and @michaeldcain to point us in the right direction.

[iamtakashi]

The header layout is different in each theme that will support FSE (Twenty Nineteen, Its child business themes, and Template-first themes that we're currently working on). And how we could achieve 1:1 editing experience with those themes is something we need to discuss. I suspect CSS alone may not enough to achieve as we cannot put blocks side by side without column block.

[glendaviesnz]

This will be partly fixed by #34396 - but is also reliant on #34423 for some of the footer styling

[iamtakashi]

I suspect CSS alone may not enough to achieve as we cannot put blocks side by side without column block.

Just to be clear, what I'm concerning is the inconsistency between the template parts editing and the front of the site. It would've been better to post my concern here #34387. My apologies.

[gwwar]

No worries @iamtakashi, we weren't sure until we tried, since the CSS specificity can get curiously high in some places.

the inconsistency between the template parts editing and the front of the site

With a handful of targeted themes, this is doable to mostly match the editor and published views.

This requires registering editor styles (used in the edit view) in each theme.

https://developer.wordpress.org/block-editor/developers/themes/theme-support/#editor-styles

[apeatling]

We can't fix this with CSS alone, we will need to use columns to get closer. I also disagree with this statement:

In this case, I think this is a no-op. Gutenberg is not a WYSIWYG editor, and having it behave that way is an unrealistic expectation.

We should be getting as close as possible, with the right combination of styles and blocks you can get incredibly close to WYSIWYG.

[apeatling]

As an example of how it can be close to WYSIWYG, here's a theme I recreated using Kioken blocks in Gutenberg, both in Gutenberg, and on the front end:

In Gutenberg:

On the front end:

These headers are relatively simple, so we should be able to make this work. The tricky part is the navigation block, because that is expecting CSS styles to make it work.

[apeatling]

In order to support the styles in https://github.com/Automattic/wp-calypso/issues/34387 we'll need to update the default header content to:

If I can find where we set this I can create a PR.

[apeatling]

Here's a PR with the updated default content: https://github.com/Automattic/wp-calypso/pull/34568

[apeatling]

Working on headers in:

https://github.com/Automattic/themes/pull/1057
https://github.com/Automattic/themes/pull/1058
https://github.com/Automattic/themes/pull/1059
https://github.com/Automattic/themes/pull/1061

[apeatling]

Closing this one as done, and referenced next steps in: https://github.com/Automattic/wp-calypso/issues/34387#issuecomment-512581504