Meeting notes from the 9th of July 2019

The meeting started with a quick round of updates. There is still no resolution about the trusted authors (TA) issues.
After that we started discussing the proposed meeting agendas.

The following is the recap of the meeting, you can read the meeting transcript in the slack archives (a Slack account is required).

Docs team discussion about the theme developer handbook

There was a discussion on the #docs slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel about handover of the theme developer handbook to the TRT.
The idea is to have a single responsible person from the TRT team that will take care of the developer handbook for the themes. This means updating it with new requirements and keeping it up to date in general.

It was agreed that the person in charge of the theme developer handbook will be @acalfieri, who is an experienced reviewer and has been an active member of TRT for a long time.
Of course, if there will be interested volunteers to help you can always ask in the slack channel.

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) (a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)) requirements

In the accessibility team meeting it was proposed to add some of the requirements from the themes which use accessibility-ready tag to standard themes in the repository.

The emphasis is on making the themes easier to use, especially for the people with certain types of disabilities.
The proposal included incorporating the keyboard navigation, control, skip link, and form labelling requirements from the existing accessibility-ready requirements.

This is the first step in making all themes in wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ repository accessible.

The changed requirement wouldn’t encompass all the accessibility-ready requirements to be present on the standard themes, nor would it automatically make them accessibility-ready, but by incorporating one by one requirements, through longer time period, the idea is to encourage theme authors to write accessible themes out of the box.

It was agreed that the skip links requirement from the accessibility part will be moved to the required section of the review handbook, and that the team will implement new a11y requirement every two months. This will give theme authors enough time to make their themes more accessible.

Removing Demo Content from the theme

It was already agreed with removing demo content files (xml, json or some other format) from the themes. But there needs to be alternative to that.

It was agreed that the requirement should be updated with following to make it more clear:

Importing or Downloading:


Themes are not allowed to import content to a user’s site.
Themes are not allowed to link directly to an XML, JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., ZIP, or other file for direct download or import.
Themes are not allowed to bundle demo content via an XML, JSON, ZIP, or other file.

Also, a meeting will be held in the #design slack channel about updating the wordpress.org previewer content which can then be used as a starting content for the developers to develop their themes.

Theme generated notices

All the notifications generated by a theme should use the admin_notices APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. and follow the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. design pattern. They must be dismissible. Everything wrapped in the admin notice needs to follow Core 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. design for the notices.

This will be a requirement on all the themes.

Open floor discussions

There was a mention of the tool that can help reviewers review a theme – WPTRT-Cloud-Launcher. It’s a Chrome extension that launches a cloud instance that comes pre-configured with the theme and theme snifferTheme Sniffer Theme Sniffer is a plugin utilizing custom sniffs for PHP_CodeSniffer that statically analyzes your theme and ensures that it adheres to WordPress coding conventions, as well as checking your code against PHP version compatibility. The plugin is available from GitHub. Themes are not required to pass the Theme Sniffer scan without warnings or errors to be included in the theme directory./check plugins installed.

#meeting, #meeting-notes, #trt

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

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

Full-Width Blocks and Root Padding in WordPress 6.1

Just under a year ago, a root padding solution was introduced for 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. themes. This allowed designers to add padding values to their theme.json files and users to adjust it via the Styles panel in the site editor. However, there was one catch. There was no built-in way to allow full-width blocks to stretch beyond any horizontal padding and reach the edge of the screen. It was the bane of many theme author’s existence. Sure, they could write custom CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. solutions to address the problem, but that didn’t solve cases where end-users customized things.

Eventually, this issue was fixed in 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 and will land in WordPress 6.1.

The fix added a new useRootPaddingAwareAlignments option to the theme.json standard. The following is an example of its usage:

{
    "version": 2,
    "useRootPaddingAwareAlignments": true,
    "settings": {},
    "styles": {}
}

If set to true, root padding gets added to Group blocks with a constrained layout, and any nested full-width blocks will stretch outside of the Group. If set to false, the padding is applied to the site-wide wrapper, and full-width blocks will not break outside of their containers.

For this to work, there is one caveat. Any padding applied via styles.spacing.padding must be in its object form rather than CSS shorthand (this does not apply to other padding usages, only the root level). The following is an example of how these two features work together:

{
    "useRootPaddingAwareAlignments": true,
    "styles": {
        "spacing": {
            "padding": {
                "top": "0px",
                "right": "2rem",
                "bottom": "0px",
                "left": "2rem"
            }
        }
    }
}

How to Test

To test, you should install the latest version of the Gutenberg plugin (currently version 14.0). Then, install the Twenty Twenty-Three theme, which is currently under development. It already has both the useRootPaddingAwareAlignments and styles.spacing.padding values set. You can adjust these to your liking.

Open a new post or page and add some content to it. Then, add at least one full-width block, such as an image.

When viewing the post on the front end of the site, the full-width block should stretch to the edge of the screen while maintaining padding on other elements, as shown in the following screenshot:

Website page view with Chrome developer tools open. An overlay shows padding on the edges of the screen.

Any feedback or questions on this new feature is welcome:

  • Does the padding solution work as expected?
  • Do full-width blocks stretch beyond the container’s padding when in use?
  • Did you run into any problems when testing?

How the Solution Works

For theme authors, they only need to know how to set this up in their theme.json files, as shown above. For those who want to dig a bit deeper into the inner workings, this section will describe how it all comes together.

When setting useRootPaddingAwareAlignments to true, root left and right padding values are applied at the block level instead of the site-wide wrapper. Group blocks with constrained layouts are given the .has-global-padding class so that they are output as shown in the following code snippet:

<div class="has-global-padding is-layout-constrained wp-block-group">
    <!-- nested blocks -->
</div>

Suppose that you added a full-width Cover block inside of that Group. The 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. would look similar to the following:

<div class="has-global-padding is-layout-constrained wp-block-group">
	<div class="wp-block-cover alignfull"></div>
</div>

Remember that the outer Group block now has padding applied to it. To allow the Cover block to stretch outside of it, WordPress will give it negative left and right margins equal to the padding.

Known Issues

Currently, there is still one outstanding issue. When nesting constrained Groups, each get the .has-global-padding class. However, this creates additional horizontal padding at each nested level. There is a ticket where a solution is being discussed.

Props to @kafleg for technical review and feedback.

Themes team meeting agenda for September 13, 2022

This is the themes team biweekly team meeting agenda.

The themes team conducts a meeting on the second and fourth Tuesday of the month. This month second meeting is on 13th of September.

The meeting takes place in the #themereview channel on the WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and you need an account to participate.

Channel: #themereview | Time: Tuesday, September 13 2022, 15:00 UTC

Along with the fixed agendas, we have an open floor at the end where you can ask or share anything related to themes.

We encourage all members, and anyone interested to attend. You can also add your agenda in the comment section below.

Meeting agenda

  1. Weekly updates
  2. Testing Full-Width Blocks and Root Padding
  3. WordCamps contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. sharing (WCUS and WCKTM)
  4. Open floor

1. Weekly updates

Current statistics can be found on: https://themes.trac.wordpress.org/ 

Themes TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket graph: https://themes.trac.wordpress.org/ticketgraph

Check regular weekly updates here.

2. Testing Full-Width Blocks and Root Padding

Last week @greenshady wrote an article about Full-Width blocks and root padding which is coming with WordPress 6.1.

If you are 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. theme developer, then we recommend you check and test this feature. Check how to test section and follow the steps to check this feature.

3. WordCamps contributor day sharing (WCUS and WCKTM)

WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Kathmandu and WordCamp US concluded successfully. Themes team would like to thank you all who attended WordCamp as well as contributor day.

Thank you @anilbasnet for leading themes table at WCKTM and @daisyo for leading WCUS themes table. Attendees, share what you’ve in the comment section below or during the meeting.

You can check upcoming WordCamps and join contributor day as well.

4. Open floor

We will discuss everything related to themes. Attendees can ask or share themes-related things.

Please comment in the comment box below if you have anything to bring up during the open floor.

#meeting, #themes-team