Pattern Placeholder blocking editing of template parts in site editor

[davipontesblog]

Quick summary

Status: Work around in place, issue is being left open while root cause is addressed

There seems to be a bug in the site editor when editing a Header or Footer template part where you see Pattern Placeholder block, and you can’t edit.

This has been reported so far on simple sites, and on a range of themes.

Workaround: editing the template from the Page Editor works as expected.

Tasks

• Stop triggering the GB bug: Don't add post types to patterns #79238
• Open a PR in GB to fix the issue @arthur791004 Edit Site: Fix the pattern with the post types becomes the placeholder pattern when editing template part WordPress/gutenberg#52503
• Revert Don't add post types to patterns #79238 once the GB fix has been deployed to dotcom

Steps to reproduce

1. Pick one of these themes: Appleton, jinjang, Barnett
2. Click to go to Site Editor
3. Go to template parts
4. Click to edit Header or Footer template parts

What you expected to happen

To edit the blocks that are part of the template part

What actually happened

Can't see blocks, so can't edit.

Impact

Some (< 50%)

Available workarounds?

Yes, easy to implement

Platform (Simple and/or Atomic)

Simple

Logs or notes

No response

[cuemarie]

FYI this was escalated internally by OP here: p1688757944597679-slack-C02FMH4G8

📌 Message to Author

• Hey @davipontesblog , you mentioned this is noted on a range of themes, but could you let us know any of the themes that should be used when testing to replicate this? Your steps to replicate doesn't currently include that info. Thanks!

[liviopv]

More info:

• Only affecting Simple Sites. I couldn't repro in Atomic of self-hosted.
• It seems to happen on theme switches, affecting only WordPress.com themes.
• It seems to be affecting themes set to display the latest post on the front page (those using Front Page, Home or Index template to load front page content). When I switched to Meraki, which uses a page assigned as front page on Reading Settings, I cannot reproduce it.
• TT2 and TT3 are not affected either.

Tested the following theme switches:
TT3 (no issue) > Tenaz (issue) > Archivo (issue) > Kigen (issue) > TT3 (no issue) > TT2 (no issue) > Geologist (issue) > Meraki (no issue)

• Yesterday, I ran into this on 6511093-zd-woothemes and I thought the issue was being caused by attempts to headstart a FSE theme, so I tried to recreate the header by copying the blocks from the theme demo, which worked.

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 6511093-zen
• 6517506-zen
• https://wordpress.com/forums/topic/editing-header-footer-not-displaying
• https://wordpress.com/forums/topic/editor-not-showing-section-on-index-page
• 6520328-zen
• 6522285-zen

[davipontesblog]

Themes where we saw this:

Appleton, jinjang, Barnett

Hey @davipontesblog , you mentioned this is noted on a range of themes, but could you let us know any of the themes that should be used when testing to replicate this? Your steps to replicate doesn't currently include that info. Thanks!

cc @cuemarie 👍

[khristiansnyder]

Noting this is happening on an AT site with Barnett active: #6517506-zen

Site Editor:

Template editor accessed from the regular page editor:

[sophiegyo]

I also could not reproduce this on a jurassic ninja selfhosted instance with WP 6.2.2 and NO plugins (or just Gutenberg 16.1.2).

Ran into a thread of reports:
https://wordpress.com/forums/topic/editing-header-footer-not-displaying/

[aleone89]

I've ran into this here: https://wordpress.com/forums/topic/editor-not-showing-section-on-index-page/

Theme: Bitácora

On this theme, the workaround of editing the footer and header in the page editor doesn't seem to work.

[wiesenhauss]

6520328-zen - Issue appeared for after switching from Boutique to Yuga on an Atomic site.

[metabreakr]

pdEkSe-3PS-p2 using the Russell theme.

[dsas]

This only seems to happen when a template-part contains a pattern which includes postTypes in its metadata. On dotcom we add this header to patterns which include a core/template-part blockType if it doesn't already have a postType set.

The intention of us adding that header is to hide patterns that aren't relevant to the post editor from the post editor. I think we could just temporarily remove that while we investigate.

The issue can also be reproduced on a dotorg site using the latest GB release if you change a dotorg theme like TT3 to make one of the patterns include a Post Types header like this one.

[Greatdane]

6522285-zd-woothemes

Theme is Tenaz Simple site, switched from a classic them to FSE.

[liviopv]

@dsas It definitely seems related to ETK.

When I activate it on an Atomic Site (GB 16.1.2), this is what I get:

The block that isn't rendering is not on the Header, ignore it.

And this is without ETK:

[liviopv]

Bumping the priority to high, since it's affecting both types of WordPress.com sites and the workaround at difficult to implement. cc @cuemarie

[arthur791004]

The root cause is the site editor only allows the pattern with the specific post types but it doesn’t pass the current template type to the hook. Hence, the pattern with the post types will be filtered out and becomes placeholder pattern.

[dsas]

I deployed a change to stop triggering this issue a while ago and have deployed a new ETK version to dotorg. It'll be picked up on atomic sites within the hour.

[cuemarie]

@dsas Thank you for that update! Checking in - looks like #79238 is merged, but WordPress/gutenberg#52503 is not yet, so I don't want to jump to conclusions.

[dsas]

Yeah it's not a problem on dotcom right now because I disabled something obscure. I would like to keep this issue open so I remember to re-enable it when the GB PR makes its way back to dotcom.

[metabreakr]

For pdEkSe-40P-p2 I'm encountering an issue where the "pattern placeholder" exists for the comments template part — comments are not rendering on Atomic, however just using the Comments block works fine.

Caveat: I am using a child theme of TT3, however this was not an issue earlier.

[dsas]

@metabreakr I doubt it's the same bug. I think it sounds like create-block-theme isn't exporting the pattern/template-part correctly.

Are you comfortable checking that on a wporg site and raising a bug on https://github.com/WordPress/create-block-theme if so? if not I can do it.

[metabreakr]

@dsas I was discussing this with a colleague and will see if I can reproduce this further with the parent TT3 active. For what its worth, with the child theme active, the Comments template part when removed/re-added renders blank. Editing it shows only the pattern placeholder. On the other hand, just using the Comments block renders correctly.

[cuemarie]

📌 ACTIONS

• Due to the status of this issue, I've downgraded the priority from High to Normal to better reflect its status in the larger context of open bugs in this repo.

I would like to keep this issue open so I remember to re-enable it when the GB PR makes its way back to dotcom.

@dsas WordPress/gutenberg#52503 should now be in Dotcom, so just pinging you in case you'd like to revert #79238 next. 👍 When that's all squared away, I think we should be able to close this out again

[iamtakashi]

I'm unsure if this is the same, but I'm experiencing something similar—some patterns in a theme don't appear in the editor. (they appear as pattern placeholders in the list view) It's only happening on simple sites, not atomic sites, not self-hosted sites.

[annezazu]

Hey folks. I just tried to replicate this on a simple site using the jinjang theme and wasn't able to replicate:

can.t.replicate.editing.header.mov

Instead, I was able to edit the header in isolation without a problem. Further, from what I can see above, the Gutenberg PR to fix this was merged a long time ago: WordPress/gutenberg#52503

I think it's safe to say that without the ability to replicate nor any recent reports that we can close this out. Let me know if that was incorrect.