Twenty Twenty-One: Consider adding block-templates support

[kjellr]

The template editor coming in WordPress 5.8 must be manually enabled on a per-theme basis. At time of writing, this is not turned on for any of the default themes:

​ https://make.wordpress.org/core/2021/06/16/introducing-the-template-editor-in-wordpress-5-8/

It seems reasonable that at least Twenty Twenty-One should support this feature when it's introduced.

[kjellr]

Also, I did try adding support to Twenty Twenty-One briefly, but the editor styles (eg. color) didn't appear to properly load there. Not sure if that's an actual bug or not:

[joyously]

I don't think the bundled themes should have any special consideration. That way they are a good indicator of how all the other themes will work. The new features should work better with existing themes and not need so many changes to the themes.

This PR adds block template support to Twenty Twenty-One, and also provides a default block template, as per the instructions here:

​ https://make.wordpress.org/core/2021/06/16/introducing-the-template-editor-in-wordpress-5-8/

The default template includes a simplified approximation of the default page layout, minus things like navigation and a footer (which requires translatable text — something not yet possible in block templates). This was pulled from TT1 Blocks, but simplified down a little bit.

Note: The theme stylesheet is not loaded in the template editor. ​ A warning is thrown about this , but I'm not sure what to make of it since Twenty Twenty-One does enqueue the stylesheet properly via add_editor_style() .

## GIF:

Trac ticket: https://core.trac.wordpress.org/ticket/53564

[poena]

I think that it is something that needs to be discussed for 5.9 and the next default theme.

And yes it worries me that work on Twenty Twenty Two has not even been publicly announced.

I did some exploring with the theme support enabled last week when I mentioned it in the corethemes slack chat, and the design and style for the theme does not match what is seen in the template editor.

Tldr: It does not keep the integrity of the theme and does not respect its design.

The effort to get it working well and to figure out the best way to keep backwards compatibility and avoid CSS duplication, not to mention dark mode and accessibility, is significant, and involves so much more than enabling theme support and one template.
It should not be rushed but done with care.

[kjellr]

Thanks @poena — I missed ​ your messages in the channel last week.

The effort to get it working well and to figure out the best way to keep backwards compatibility and avoid CSS duplication, not to mention dark mode and accessibility, is significant, and involves so much more than enabling theme support and one template.

Out of curiosity, what are your accessibility concerns in regards to adding this? Are they theme-specific?

And good point about dark mode — in my testing it worked as expected in the front-end. It's not present on the backend, but all styles are broken there so that makes sense.

[poena]

I don't have specific accessibility concerns other than the color work the theme squad did for the previously existing blocks and the pairing of blocks, and secondary, confirming that the underlines are correct. It requires a lot of testing.
This should be done for the new blocks no matter if template editing is enabled or not, but the difference is the time frame suggested in this issue.
My concern is that trying to push for this late in the RC period is going to end with a less than optimal and untested solution. It should not be stressed.

[onemaggie]

I have not had any issues with the editor styles running Kjell's branch. This is the editor:

This is the frontend:

[poena]

I was able to spend some more time troubleshooting but I could not solve the issue with the editor dark mode styles.

@onemaggie Did you test dark mode?

A temporary(?) solution suggested in #53530 would be to turn off dark mode in all editors. I worry about how this will affect users who use this feature.

---

My wish is that I would like the blocks to match the original styling better.

-In the default template, center the title and tagline. This matches the theme when there is no menu, and, because the navigation block is not in 5.8, there is no menu in the template.

-Lower the font weight of the post title to 300.

-Reduce the font size of the meta (post date, tags/ categories).

[kjellr]

Thanks for testing, @poena!

The PR now includes the following fixes:

• The title and tagline are centered (thanks, I forgot that's how the theme handles this!)
• The font weight of the post title matches the weight used in our usual templates.
• The meta is now the same size it is for the usual templates.
• The margins/spacing in the front end now match the usual templates more exactly.
• Separator blocks now appear the correct width.

There's still a bunch of extra vertical spacing in the editor (around group blocks for example), but that's a broader issue that I think we should tackle outside of this PR... I'm not sure it makes sense to add a bunch of aggressive CSS to change it just for the header section of this specific layout.

I took a look at the dark mode situation, and it looks... complicated. This is something that I'd need additional help building, and I think it would end up being substantial enough that it could be handled in a separate patch.

Dark mode aside, this feels pretty close to a decent v1 to me.

Here are some current screenshots:

Editor:

Front-end:

[kjellr]

A temporary(?) solution suggested in #53530 would be to turn off dark mode in all editors. I worry about how this will affect users who use this feature.

Oh, and I meant to respond to this suggestion: I share your worry that removing dark mode support from all editors would confuse existing users. I do think it would be okay (but not ideal) to launch this new feature without dark mode support, and then add it in later on. At least then the theme's current features would be unaffected.

[kafleg]

I checked the Twenty Twenty-One theme with 5.8 RC 2 and was looking for the template editing possibility in this theme. But, it is not possible.

I wish it should be enabled in the core theme so that other theme developers can take the reference from it.

[poena]

I have not been able to test the updated pull request properly; I am seeing errors that I hope are only on my test installation (I made sure to build the theme files, just in case).

In the template editor:
The background is always white no matter what background color is selected in the customizer, including the default, and dark mode is off.

Only the post title has the correct font family. The site title, tagline, and post date are using the font family serif .

WP version 5.8-RC2-51366 plus the PR. Windows 10, Chrome version 91.0.4472.124.
The error in the console about the stylesheet not being loaded correctly, that was reported earlier, is present.

[kjellr]

The background is always white no matter what background color is selected in the customizer, including the default, and dark mode is off.

Only the post title has the correct font family. The site title, tagline, and post date are using the font family serif.

Those are the same issues I was seeing when I originally tried this ! 😅 When I build the PR today though, they're gone and the styles load as expected. I'm curious if anyone else is able to reproduce?

[jffng]

I tested this and see the same thing as @poena:

The following console error is thrown when template editing mode is initialized:

 Stylesheet  was not properly added. For blocks, use the block API's style ( https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#style ) or editorStyle ( https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#editor -style). For themes, use add_editor_style ( https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-support/#editor -styles). < link rel=​"stylesheet" href=​"http:​/​/​wordpressbeta.local/​wp-admin/​load-styles.php? c=1&dir=ltr&load%5Bchunk_0%5D=dashicons,admin-bar,buttons,media-views,editor-buttons,wp-components,wp-block-editor,wp-nux,wp-reusable-blocks,wp-editor,common,&load%5Bchunk_1%5D=forms,wp-reset-editor-styles,wp-block-library,wp-editor-classic-layout-styles,wp-edit-blocks,wp-edit-post,wp-block-directory,wp-&load%5Bchunk_2%5D=format-library,admin-menu, dashboard,list-tables,edit,revisions,media,themes,about,nav-menus,wp-pointer,widgets,site-icon,l10n,wp&load%5Bchunk_3%5D=-auth-check,wp-block-library-theme&ver=5.8-RC2-51366" media=​"all">​ (anonymous) @ block-editor.min.js? ver=ccce823101eb1098c67ccbd5ea53f37a:12 <link rel="stylesheet" href=" http://wordpressbeta.local/wp-admin/load-styles.php?c=1&amp ; dir=ltr&amp;load%5Bchunk_0%5D=dashicons,admin-bar,buttons,media-views,editor-buttons,wp-components,wp-block-editor,wp-nux,wp-reusable-blocks,wp-editor,common,&amp;load%5Bchunk_1%5D=forms,wp-reset-editor-styles,wp-block-library,wp-editor-classic-layout-styles,wp-edit-blocks,wp-edit-post,wp-block-directory,wp-&amp;load%5Bchunk_2%5D=format-library, admin-menu,dashboard,list-tables,edit,revisions,media,themes,about,nav-menus,wp-pointer,widgets,site-icon,l10n,wp&amp;load%5Bchunk_3%5D=-auth-check,wp-block-library-theme&amp;ver=5.8-RC2-51366" media="all">

WordPress 5.8-RC2-51366
Chrome Version 91.0.4472.106 (Official Build) (x86_64)

[kjellr]

Yeah, that's the same error I was getting originally as well. The stylesheet is being added correctly though, so I'm not sure what's going on there. I wonder if someone from the Gutenberg team can take a look?

[scruffian]

I noticed some issues with alignment styles....
In the editor:

In the front end:

[kjellr]

Great catch, @scruffian. I just pushed a commit that expands Twenty Twenty-One's alignment styles to cover the new group block markup (with no inner container), and also blocks that live directly within the new wp-site-blocks container.

Editor:

Frontend:

[pbking]

Tested the recent alignment changes and they are working exactly as expected.

I'm not sure what else would need to be done to finish this, it seems pretty complete (except of course for dark mode support noted already). I believe this is ready to come in.

[kjellr]

I noticed in my screenshots above that paragraphs outside of entry-content were not inheriting the correct vertical spacing margins on the front end, so I pushed a small update to fix that and adjusted the template's spacing to match.

[onemaggie]

This one looks solid to me with the latest fixes

[kjellr]

Thanks for the testing! I've pushed a small update to add the template-editing tag from #53556 . I haven't seen that styles loading error in a while, so I'm fairly certain this is good to go.

[kjellr]

Just wanted to add a brief update here: @poena and I discussed this issue ​ on slack the other day, and she raised the issue of dark mode support.

This patch does not presently include a solution for dark mode in template editing. I've done some light digging, and wanted to summarize situation and the blockers here:

• Currently, if you apply this patch but have dark mode enabled on your site, the template mode will appear in light mode. Your front end will still appear in dark mode — it's just the template editing interface that will be shown in light mode. This is not consistent with the way the standard post and page editor works.
• The post and page editor uses wp_add_inline_style() and the enqueue_block_editor_assets hook to inject the dark mode color variables into the editor. This method is not compatible with the iframed template editor. My understanding is that only styles loaded via add_editor_style() are currently be enqueued there.
• To get this to work, I think we'd need to rewrite (or duplicate and modify) that dark mode function to use a new approach that's compatible with the iframe.

If there's another developer (who's more familiar with the iframed editor) available to take a look that would be really helpful. In the meantime, we're a little stuck.

Supports custom colors in the template editor using block_editor_settings_all .
Adds the is-dark-theme CSS class to the body of the template editor iframe.

This fixes an issue where the background color selected in the customizer did not display in the template editor,
with or without dark mode enabled.

Relies on ​ https://github.com/WordPress/wordpress-develop/pull/1455
_The colors will not display correctly without 1455._

What is left to do:

• Add a version control for versions below WordPress 5.8.
• Fix any coding standard issues and optimizations.
• Testing
• Add props to ellatrix :)

Trac ticket: https://core.trac.wordpress.org/ticket/53564

[poena]

@kjellr I did not know how to add to your PR, so I submitted a PR that needs to be tested in combination with yours.

[kjellr]

Thanks, @poena! I've migrated your changes over to the main PR, and added you as a collaborator to that fork in case you'd like to push any other changes. I'm not seeing the class added though, so I'm wondering if I missed a piece?

[poena]

Here is what I am finding with ​ 6158e9a , WordPress 5.9-alpha-51272-src:

1. Enable dark mode in the customizer.
2. Using the block editor, create and publish a new post.
3. In the Template section in the block editor, click "New" to create a new template and enter the template editor.
4. The green background is showing, and the is-dark-theme CSS class is missing from the iframed <bod>y element.
5. Refresh the page or go back to the block editor and select edit to open the template editor again.
6. The background is dark grey and the CSS class is there (There is a flash of the green background first).

(No plugins enabled)

[poena]

The above is inconsistent, the background color only changes some times, and sometimes not until after 20 seconds.

I think it is related to the time out and attempts in ​ editor-dark-mode-support.js but my JS skills are not enough to be sure or to solve it.

[poena]

There are several things to consider here.

It seems reasonable that at least Twenty Twenty-One should support this feature when it's introduced.

At this stage, long after the release of the theme , and with multiple block themes available, I think that the block templates and template parts should remain disabled by default because enabling them now would be a big change for existing users.

But, I also think that if someone enables the theme support in a child theme, the dark mode settings should not break.

I have not personally tested if there are still breaking issues since my last comment 3 years ago, and I think testing should be the first step.