Testing and Feedback for using block based template parts in classic themes

This post was a collaboration between @greenshady @mamaduka @fabiankaegy @annezazu

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 14.1, coming September 15th, enables the ability to use blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. template parts without adopting everything that comes with block templates. Using this functionality, you can do things like allow a user to edit and build a headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. with blocks without exposing them to the entire block template system. This offers a new gradual adoption pathway for folks with classic or hybrid themes and new ways to explore full site editing features for agencies that need testing and feedback ahead of WordPress 6.1’s release on November 1st.

For more information around larger gradual adoption pathways, please review the converting a classic theme to a block theme handbook page. For information around how to curate the experience further while still allowing new abilities to edit template parts, please review the curating the editor experience handbook page.

Overview

Gradual adoption options remains a focus for the project and, increasingly, there are more ways to adopt parts rather than the whole of a feature coming to the latest version of WordPress. The aim is to allow folks to adopt what they need as they are ready in a way that is still future forward. In this case, once the feature is enabled, users will see a new “Template Parts” menu visible under “Appearance,” which displays a list of template parts. From there, all theme blocks are available, but the environment is inherently limited compared to block themes. For example, users can edit existing template parts but not delete them or create new ones.

WP Admin interface with the Appearance menu open highlighting the new template parts section.

For a sense of how one could adopt this feature, here are a few examples to get creativity flowing:

  • Offering a header template part that allows a user to set a video or image background, set duotone colors, change the focal point, and more without altering the positioning of the blocks within (navigation, site title, etc).
  • Providing the ability to edit parts of a footer directly, like location and hours of operations, while keeping the structural blocks locked down to preserve the design.
  • Adding a more open ended header template part that allows for any and all block movement/removal/etc but curates the experience with certain design tools disabled for certain blocks and offering default colors that match the broader theme style.

How to test

In order to enable this feature a theme first needs to specify block-template-parts theme support and to use Gutenberg trunk or Gutenberg 14.1 when it’s released on September 15th, 2022. You can also follow these instructions to use the specific PR that implemented this feature.

With that theme support added a theme can now add block-based template parts by placing htmlHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. files containing the block template into the parts directory inside the root of the theme.

function add_block_template_part_support() {
    add_theme_support( 'block-template-parts' );
}

add_action( 'after_setup_theme', 'add_block_template_part_support' );

These block-based template parts can now be used in the traditional PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. templates by using the block_template_part function. This function returns the markup of the template part which then needs to get output.

If a theme author wanted to make the site footer available to edit as a template part, they would create a footer.html file and place it within their theme’s /parts folder.  The following code snippet is an example of what the template part would look like:

<!-- wp:group {"layout":{"inherit":true}} -->
<div class="wp-block-group">
	<!-- wp:group {"style":{"spacing":{"padding":{"top":"80px","bottom":"30px"}}}} -->
	<div class="wp-block-group" style="padding-top:80px;padding-bottom:30px">
		<!-- wp:paragraph {"align":"center"} -->
		<p class="has-text-align-center">Proudly Powered by <a href="https://wordpress.org" rel="nofollow">WordPress</a></p>
		<!-- /wp:paragraph -->
	</div>
	<!-- /wp:group -->
</div>
<!-- /wp:group -->

To display the part on the front end, the theme would include it in its top-level templates, such as index.php, single.php, and others via the block_template_part() function with a reference to the part name.  In the case of a site footer, this code would replace the call to get_footer() in most themes.

<?php block_template_part( 'footer' ); ?>

Advanced testing

While this feature is currently aimed at providing options for themes, plugins can also explore extending this functionality to enable the same UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. for users. If you explore extending this feature via a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, please share what blockers, bugs, and enhancements you’d like to see to help shape future work in this area.

Leave your feedback in the comments 

The following are some questions to keep in mind and answer:

  • Did the Template Parts menu appear under Appearance? 
  • Were you able to properly define a template part and see it appear under Appearance > Template Parts?
  • When you edited a template part, did the changes properly reflect on the front end of the site? 
  • Are there missing features or options that would improve this experience as a developer?
  • What did you find frustrating or confusing about the feature?
  • Are there things you particularly appreciated about it?

Please share any and all feedback in the comments.

#testing

Testing and Feedback for the Fluid Typography Feature

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 13.8 introduced the first version of a fluid typography feature, which allows theme authors to define font sizes that adapt to the viewport. Version 13.9 will also add a couple of fixes and enhancements.

Because this is a new feature that will primarily affect how theme authors build their designs, it needs thorough testing from the theme development community. Please take some time to test and share feedback in the comments.

Overview of Fluid Typography

The fluid typography feature allows theme authors to define scalable font sizes via their theme.json file, as shown in the following video clip:

The new feature gives theme authors two new keys to add in their theme.json files:

  • settings.typography.fluid can be set to true to enable fluid typography feature (default false).
  • Then, individual size objects in settings.typography.fontSizes accept a fluid object with min and max values (in the upcoming Gutenberg 13.9, themers can set this to false to opt out for individual sizes. Gutenberg uses these values, the existing size value, and a default formula (see changeset) to calculate the clamp() CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. output.

The following code snippet shows how to both enable the feature and define the individual sizes. It has two size examples under settings.typography.fontSizes. The first size, normal, adds extra minimum and maximum sizes. The second size, large, disables fluid type (requires Gutenberg 13.9).

{
	"version": 2,
	"settings": {
		"typography": {
			"fluid": true,
			"fontSizes": [
				{
					"name": "Normal",
					"size": "1.125rem",
					"fluid": {
						"min": "1rem",
						"max": "1.5rem"
					},
					"slug": "normal"
				},
				{
					"name": "Large",
					"size": "2rem",
					"fluid": false,
					"slug": "large"
				}
			]
		}
	}
}

This results in the following presets after calculations are made:

--wp--preset--font-size--normal: clamp(1rem, 1rem + ((1vw - 0.48rem) * 0.962), 1.5rem);
--wp--preset--font-size--large: 2rem;

How to Test

To test, you must have at least Gutenberg 13.8 installed and a theme with a theme.json file, such as Twenty Twenty-Two. Alternatively, you can add a custom theme.json file to a theme of your own.

The first step is to enable settings.typography.fluid in the theme.json file, which should look similar to the following:

{
	"version": 2,
	"settings": {
		"typography": {
			"fluid": true,
		}
	}
}

Then, you need at least one custom font size under settings.typography.fontSizes. Your theme.json code should now look similar to the following snippet:

{
    "version": 2,
    "settings": {
        "typography": {
            "fluid": true,
            "fontSizes": [
                {
                    "name": "Normal",
                    "size": "1.125rem",
                    "fluid": {
                        "min": "1rem",
                        "max": "1.5rem"
                    },
                    "slug": "normal"
                }
            ]
        }
    }
}

For testing, you can select the “Normal” font size in the editor or copy/paste the following directly into the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor:

<!-- wp:paragraph {"fontSize":"normal"} -->
<p class="has-normal-font-size">Shortbread cotton candy chocolate bar macaroon cupcake. Dragée cupcake tart apple pie ice cream cheesecake sugar plum shortbread wafer. Brownie gummi bears gummies dragée biscuit brownie.</p>
<!-- /wp:paragraph -->

If testing with Gutenberg 13.9, try adding a second font-size that disables the fluid type feature and running through the same scenario (name this one large):

{
    "name": "Large",
    "size": "2rem",
    "fluid": false,
    "slug": "large"
}

The following are some questions to keep in mind and answer:

  • Did the font sizes adapt to the viewport?
  • Did the theme.json code match what you expected on the front end?
  • Was the behavior the same on the front end and editor? Note: this needs Gutenberg 13.9 to work in the site editor.
  • How well does the type scale with a wide range between the min and max ranges?
  • Did disabling the fluid feature for individual sizes work (Gutenberg 13.9+ only)?
  • Are there missing features or options that would improve this experience as a developer?
  • Did this work well for both classic and block themes, depending on which you tested?
  • What did you find frustrating or confusing about the feature?
  • Are there things you particularly appreciated about it?

Please share any and all feedback in the comments.

Changes and Features Expected in Upcoming Releases

Currently, fluid typography is essentially an early, dev-only feature without all the future improvements that will make it shine. It is a solid start that puts a lot of power directly into the hands of theme authors. However, there is more on the horizon.

Gutenberg 13.9 includes two improvements:

Developers should also keep their eye on a couple of related tickets:

Props to @kafleg for technical feedback and review.

#testing