WP 6.3-beta3 front-page template shows static page on initial loading

[wpsoul]

Description

As I understand, we have now two options in FSE themes: home.html template and front-page.html. If theme has home.html template, then Settings - reading option is used on front page of site. If front-page, then settings - reading is ignored and only front-page is used

In 6.3 beta, if theme uses front-page.html and if I visit /wp-admin/site-editor.php I see empty screen. And it looks like now it uses settings - reading setup which has no sense, because on Frontend side, front-page template is used.

Step-by-step reproduction instructions

1. Install any theme which has front-page.html (for example, Greenshift)
2. Set static page in settings - reading
3. Visit /wp-admin/site-editor.php
4. I expect to see front-page template. Instead of this, I see empty screen or screen of static page

Screenshots, screen recording, code snippet

No response

Environment info

• 6.3 beta 3 version of WP

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[annezazu]

Nearly positive this is a duplicate of #52266 on second glance. Can you confirm @wpsoul ?

[wpsoul]

Not exactly. That ticket describes workflow when Home template is existed (for example in 2023 theme), but my scenario is about Frontpage. If I have next in theme, options in Settings - reading must be ignored and I must have Front Page template when I open site editor. This way it worked in 6.2

[annezazu]

@ramonjd in case you can take a look!

[ramonjd]

Nearly positive this is a duplicate of #52266 on second glance.

Yeah, despite the very misleading title, that PR was a little different in that it related specifically to the pages list.

I've tested the steps described in this issue on WordPress 6.3-beta3-5619 with both Gutenberg 16.2 activated and deactivated and can reproduce using the Greenshift theme. Checked a few others. Porcupine works.

Greenshift has a lot of block validation errors:

So when I remove most of those blocks from the front page template, it loads

emptytheme, 2023, 2022 load well. I tested by both:

• Creating a front-page template via the Site Editor template management page, and
• Creating a front-page.html in my theme directory

[wpsoul]

I retested on latest beta build. Error with wrong front page template is gone. I found validation errors, but it looks like bug from core. Custom image size now is rendered also in style tag. I see this bug not only in theme, but in many patterns, for example

[wpsoul]

Found where this block. It's in Woocommerce pattern which is called "Testimonial Single"

[ramonjd]

Nice sleuthing @wpsoul

The styles were introduced in #51545 here

I think it should have added a deprecation cc @ajlende

Here's the template: https://github.com/woocommerce/woocommerce-blocks/blob/trunk/patterns/testimonials-single.php

Running this through 6.3 Beta:

Content generated by save function:

<figure class="wp-block-image alignleft size-large is-resized has-custom-border is-style-rounded"><img src="https://s.w.org/images/core/5.8/portrait.jpg" alt="" style="border-radius:100%;width:164px;height:164px" width="164" height="164"/></figure>

Content retrieved from post body:

<figure class="wp-block-image alignleft size-large is-resized has-custom-border is-style-rounded"><img src="https://s.w.org/images/core/5.8/portrait.jpg" alt="" style="border-radius:100%" width="164" height="164"/></figure>

[jordesign]

@ramonjd Just looping back to this one - as notes in #51545 suggest this is a different issue?

[ramonjd]

Thanks @jordesign

Confirmed, what I said above was bunk.

Explanation here:

This is part of edit, not save, so it shouldn't affect block deprecations. In a follow-up #52286, @draganescu added styles to save, but he did add a deprecation for them.

[draganescu]

@ramonjd is thre anything wrong with #52286? Once the content is migrated do the errors persist? I did add a deprecation wihich does not include the style. Maybe I forgiot to do something (I am constantly unsure about deprecations).

[ramonjd]

@ramonjd is thre anything wrong with #52286? Once the content is migrated do the errors persist? I did add a deprecation wihich does not include the style. Maybe I forgiot to do something (I am constantly unsure about deprecations

Thanks for the ping! I didn't have time to debug any of the deprecations, so I couldn't tell where it was coming from. I just leapt to a conclusion that the latest style additions were related.

I'll try to test again. Deprecations turn my brain to mashed potato.

[ramonjd]

@draganescu

So I think #52286 did introduce the validation error despite the deprecation.

To test, add a v6 image block to a post via the code editor and save:

<!-- wp:image {"align":"left","width":164,"height":164,"sizeSlug":"large","style":{"border":{"radius":"100%"}},"className":"is-style-rounded"} -->
<figure class="wp-block-image alignleft size-large is-resized has-custom-border is-style-rounded"><img src="https://s.w.org/images/core/5.8/portrait.jpg" alt="" style="border-radius:100%" width="164" height="164"/></figure>
<!-- /wp:image -->

You'll see the deprecation warning.

Block validation: Block validation failed for `core/image` ({name: 'core/image', icon: {…}, keywords: Array(3), attributes: {…}, providesContext: {…}, …}).

Content generated by `save` function:

<figure class="wp-block-image alignleft size-large is-resized has-custom-border is-style-rounded"><img src="https://s.w.org/images/core/5.8/portrait.jpg" alt="" style="border-radius:100%;width:164px;height:164px" width="164" height="164"/></figure>

Content retrieved from post body:

<figure class="wp-block-image alignleft size-large is-resized has-custom-border is-style-rounded"><img src="https://s.w.org/images/core/5.8/portrait.jpg" alt="" style="border-radius:100%" width="164" height="164"/></figure>

Then remove the changes from #52286

diff --git a/packages/block-library/src/image/save.js b/packages/block-library/src/image/save.js
index 6fa8c6b234..95e8803dd6 100644
--- a/packages/block-library/src/image/save.js
+++ b/packages/block-library/src/image/save.js
@@ -58,8 +58,6 @@ export default function save( { attributes } ) {
 				...borderProps.style,
 				aspectRatio,
 				objectFit: scale,
-				width,
-				height,
 			} }
 			width={ width }
 			height={ height }

The warning is gone.

I suspect we need to migrate the markup changes, but it's tricky because the save function doesn't return a valid block, so I couldn't test things out with migrate/isEligible. Plus, I'm not sure here, but manipulating attributes or innerBlocks might not work because:

1. The attributes haven't changed, only the application of them to the <img /> markup
2. There are no innerBlocks/innerBlockProps

I think we'd also need to add attributes and supports to the v6 deprecation?

I've done a few deprecations in the past but I wouldn't class myself as an expert here. I might ask around.

[ndiego]

@ramonjd can this be considered complete when #52822 and #52853 are backported?

[ramonjd]

can this be considered complete when #52822 and #52853 are backported?

Thanks for the ping. Yes, that sounds about right. I should have added the backport to RC label to #52822 sooner, but I'll make sure it features in the next round.

[tellthemachines]

Closing this one because the Image block deprecation fixes were added to core in 6.3 RC2. Thanks everyone!

[wpsoul]

I return back to my initial bug report. Tried actual 6.3 Nightly and bug is returned back

One more time. If I have FrontPage template in block theme, Site editor must show Front Template on initial loading. Currently, it shows page from Settings - Reading - Homepage which has no sense because this page is not used on frontend side.

[ramonjd]

If I have FrontPage template in block theme, Site editor must show Front Template on initial loading. Currently, it shows page from Settings - Reading - Homepage which has no sense because this page is not used on frontend side.

Could you give details about the front-page template you're using?

I've tested with the most basic set up, by creating a new front-page.html with the following content:

<!-- wp:heading {"level":1} -->
<h1 class="wp-block-heading">Front page</h1>
<!-- /wp:heading -->

And it always overrides the Settings > Reading settings in the editor and frontend. So I suspect it might be specific to the front-page template?

[wpsoul]

And it always overrides the Settings > Reading settings in the editor and frontend. So I suspect it might be specific to the front-page template?

Ok, so, the situation is even worse. If front-page.html uses just static content, it works. But if it uses patterns or template parts, it doesn't work

<!-- wp:pattern {"slug":"greenshift/footer-default"} /-->

or

<!-- wp:template-part {"slug":"header","tagName":"header","className":"site-header"} /-->

but if I copy content from header template part and insert it directly in front-page.html, then it works

so, wp:pattern and wp:template-part (any of this) will break site editor initial loading. In the same time, if I select Front template in editor, then it works correctly

[ramonjd]

I wonder if it's related to #52983

[wpsoul]

I wonder if it's related to #52983

No. In my case, template is working if I open it in editor. Problem is only in initial loading which doesn’t show Frontpage if template has pattern

[wpsoul]

The latest build made everything even worse. Now, it shows Front-page template on initial loading, but you can't edit anything in the content area

[ramonjd]

Here's what I'm seeing:

2023-08-02.11.52.16.mp4

Is this happening on other themes for you as well?

[ramonjd]

Oh I think the fix was included in the latest round of cherry picking for 6.3:

• Fix not expanding pattern in page editor #53169 (comment)