'Show Template' defaulting to on for non-English(US) languages

[jordesign]

Quick summary

Update: The "Show Template" option should be on by default for all languages.

Quick summary

If a user's account language is set to English(US), the 'Site Template' option (from the preview menu and/or 'Template' setting in the sidebar) doesn't default to on.

This is not matching the default Gutenberg behaviour on self-hosted sites.

Steps to reproduce

1. In your user profile - ensure your account language is set to English(US).
2. Go to 'Pages' in the admin menu and click a page to edit.

What you expected to happen

The Page content should be displayed with the page template (header, footer, etc).

What actually happened

The page editor only shows the page content.

Impact

Some (< 50%)

Available workarounds?

Yes, difficult to implement

If the above answer is "Yes...", outline the workaround.

User's affected by this can switch to English as their account language temporarily.

Platform (Simple and/or Atomic)

Simple

Logs or notes

These seems to be effecting Simple Sites.
However I have noticed in testing my Atomic site that the 'Site Template' also shows by default - I'm not sure if this is by design.

[Robertght]

📌 REPRODUCTION RESULTS

• Tested on Simple – Replicated
• Tested on Atomic – Could Not Replicate
• Replicable outside of Dotcom – No

📌 ACTIONS

• Triaged
• Requested author feedback

📌 Message to Author
@jordesign I'm a bit unsure how to read this. Should we or should we not have "Show template" turned on by default?

While checking this on a self-hosted website, I noticed the option is turned on by default on all languages.

@annezazu do you know if language should be a factor on how this feature works?

[jordesign]

My understanding is that on WPCOM we have it disabled deliberately.
p1732229905485519-slack-CNXKTTYCV

[annezazu]

do you know if language should be a factor on how this feature works?

No! This shouldn't be different based on language.

[jartes]

This happened on this interaction: 9176633-zd-a8c

[github-actions]

Support References

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

• 9176633-zen

[annezazu]

@youknowriad do you know why this might be? Pinging you based on your work in WordPress/gutenberg#62304 which caused the template to show for pages. Oddly enough, on my simple site, I don't see the template showing in either flow (Pages > Add New, Site Editor > Pages) when it should. @jordesign where are you seeing that this was intentionally turned off? You linked to a thread I was a part of that has no indication of this being disabled for WordPress.com.

To be clear, I expected the template to show for all pages when 19.8 was put on WordPress.com.

[jordesign]

@annezazu - Apologies - that was my incorrect interpretation of that thread.

I suppose that the issue, then, is the inconsistency generally depending on language

[jartes]

I added an update message to the issue.

Related dotcom-escalation convo p1734525664059729-slack-C02FMH4G8

[dsas]

I took a look at this, I made some progress but don't 100% know what the solution looks like right now, and it's rather late.

The issue is happening on the front-end because default_rendering_mode isn't in the API response for American English users.

It's easier to try and debug this by using the wp.com api console to visit wp/v2/sites/:siteid/types/page?context=edit&environment-id=stage - you'll see there are 17 keys in the response. Append &_locale=en-gb to the url and you'll see there are now 18 keys in the response - default_rendering_mode is the added one.

If I comment out the call to wpcom_switch_to_locale in WPCOM_REST_API_V2_Locale (see fbhepr%2Skers%2Sjcpbz%2Sjc%2Qpbagrag%2Serfg%2Qncv%2Qcyhtvaf%2Spragenyvmrq%2Sybpnyr.cuc%3Se%3Qq18pq534%26zb%3Q160%26sv%3Q10%2354-og) then I can't reproduce the issue - I always get default_rendering_mode in the response.

The way that default_rendering_mode is supposed to get into the API response, is that gb provides a gutenberg_post_type_default_rendering_mode method which hooks register_post_type_args to add default_rendering_mode. This is only done if the theme is a block theme.

When this method is called a block theme isn't necessarily active. On some calls it's the a8c public-api placeholder theme that is active, which is not a block theme. Temporarily commenting out the is_block_theme check makes it work. This is where the change needs to happen.

As to why it works for non-default locales, I stopped digging but my assumption is that locale switching happens after we've switched from public-api to the target site. As part of switching locales we probably re-run the post type registration so that the localised strings are used. As the theme is now a block theme, it passes the check in gutenberg_post_type_default_rendering_mode

[dsas]

Last time we ran up against the issue of is_block_theme running on the public-api theme (p58i-f7m-p2#comment-59242) we eventually avoided it by running some code to undo stuff after we've switched to the target site.

I think there are a few (untested!) options here, but maybe others can think of more:

1. The upstream code is changed to use a hook ran later than the current register_post_type_args, it'd have to be something later than rest_pre_dispatch.
2. We do some jiggery-pokery in wpcom to additionally run post type registration from a later hook
3. We add a wpcom specific hack for this endpoint

cc @david-binda, have you seen a solution to this kind of problem when running core merges?

cc @youknowriad for any perspective on an upstream change

[david-binda]

As to why it works for non-default locales, I stopped digging but my assumption is that locale switching happens after we've switched from public-api to the target site. As part of switching locales we probably re-run the post type registration so that the localised strings are used.

That seems correct. The create_initial_post_types is hooked to change_locale in the wp-includes/default-filters.php file.

I believe that calling the create_initial_post_types() function after getting the target site in REST API might actually do the trick here. It's being called anyway in case different than the english location is being used, so there should be no harm in calling it for the english locale as well.

However, while testing the approach, I run into https://github.com/Automattic/jetpack/blob/ff26ecb6c6ac8876b9562205034b437a9e8efe87/projects/packages/jetpack-mu-wpcom/src/features/wpcom-hotfixes/wpcom-hotfixes.php#L16 which reverting the addition. Looks like there is some related issue.

[david-binda]

I've prepared a PR adding the create_initial_post_types() to the REST API in 169117-ghe-Automattic/wpcom

[dsas]

Looks like there is some related issue.

Oh yeah sorry, I should've mentioned that. There are multiple things going on here!

1. The underlying feature is broken for editor-level users. This is a GB bug another team is looking at.
2. To prevent that being a problem on dotcom, we have disabled the feature in the commit you found.
3. This issue, which meant that American English users weren't seeing the (broken) underlying feature on dotcom, even before we disabled it.

Thanks for opening a PR, I'm taking a look now.