Introducing the Token Map

There’s a new data structure coming in WordPress 6.6: the WP_Token_Map, but what is it? The ongoing work in the HTML API required the ability to find named character references like … in an HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. document, but given that there are 2,231 names this is no easy task. The WP_Token_Map is a purpose-built class designed to take a large set of static string tokens with static string replacements, and then be used as a lookup and replacement mechanism. That’s all very technical, so let’s see it in action and consider how it might be useful to you.

As an important note: you probably don’t need this because it’s an optimized data structure built for lookup with a very large set of tokens. The examples are unrealistically short but are meant only to illustrate the class usage in a readable form. If working with small datasets it’s possibly faster for most purposes to stick with familiar tools like in_array() or associative arrays.

The Token Map, in short, is a new semantic utility meant to answer one simple question: given a string and a byte offset into that string, does the next sequence of bytes match one of a known set of tokens, and if so, what is the replacement for that token? It’s designed as a low-level utility for use in combination with other string parsing logic.

Continue reading

#6-6, #dev-notes, #dev-notes-6-6

Miscellaneous Editor changes in WordPress 6.6

In this post, you will find dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for smaller changes to the editor in WordPress 6.6.


Table of contents


Added wp-block-list class to the list 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.

Styling a list block using the Site Editor or theme.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. also applied the style to other lists, partially or in full. This caused styling conflicts with blocks that use lists internally and with lists in the editor interface.

The problem has been fixed by adding the CSSCSS Cascading Style Sheets. class wp-block-list to the <ul> and <ol> elements of the list block, and only applying the styling to lists with this class name.

If you have relied on the list block styles to style generic lists, you may need to update your CSS.

GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ pull request: #56469

Props to @poena for writing the dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

Allow view access of the template REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoint to anyone with the edit_post capability

Before WordPress 6.6 the templates and template-parts REST API endpoints were restricted to only be viewed/edited by anyone with the edit_theme_options capability (Administrators). WordPress 6.6 changes the permission checks to allow any user role with the edit_post capability to view these endpoints. Editing is still restricted to the edit_theme_options capability.

This change is because the post editor now includes the ability to preview a post’s template while editing the post. In WordPress 6.5, this option was limited to administrators only. However, WordPress 6.6 now supports previewing the template for all user roles.

GitHub pull request: #60317

Props to @fabiankaegy for writing the dev note.

Unified split logic for writing flow

RichText’s optional onSplit prop was deprecated and replaced with a block.json support key called splitting. The onSplit prop was only used by a few coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks (paragraph, heading, list item, and button), so it’s not expected that this affects a lot of third-party blocks.

In any case, when the onSplit is used, splitting will still work but can’t be controlled as granularly as before: the callback won’t be called, and the block will split in a generic way.

GitHub pull request: #54543

Props to @ellatrix for writing the dev note.

BlockPopover Component is now public

The BlockPopover component is now publicly accessible. For more details, you can check the README.

GitHub pull request: #61529

Props to @gigitux for writing the dev note.

Add filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to modify the list of post content block types

When WordPress renders a post/page’s template at the same time as the content, most template blocks are disabled/locked. However, some blocks, like the Post Title, Post Content, and Post Featured ImageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts., still allow users to edit the content within them. They get rendered in the contentOnly rendering mode.

WordPress 6.6 now adds a filter to modify this list of blocks that should get the contentOnly rendering mode applied when rendered as part of the template preview.

import { addFilter } from '@wordpress/hooks';

function addCustomPostContentBlockTypes( blockTypes ) {
    return [ ...blockTypes, 'namespace/hello-world' ];
}

addFilter(
    'editor.postContentBlockTypes',
    'namespace/add-custom-post-content-block-types',
    addCustomPostContentBlockTypes
);

It is important that only settings that store their data in custom ways are exposed when rendered in this contentOnly mode. An example is a block that stores a subtitle in post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.. Anything that gets stored to the standard block attributes won’t persist.

GitHub pull request: #60068

Props to @fabiankaegy for writing the dev note.

Global Styles: Filter out color and typography variations

In addition to style variations, WordPress 6.6 adds the ability for themes to create color and typography presets. These are subsets of style variations and give users the ability to replace the color or typography of a site without all the other changes that come in a style variation.

To add color and typography presets to a theme, developers follow the same process as adding style variations, except that each variation must contain only color or typography rules. Any style variations that contain only these rules will be treated as presets and will appear under Global Styles > Typography or Global Styles > Colors > Palette.

Style variations that already conform to this requirement, i.e. they contain only color or typography rules, will automatically be treated in this way. That means these style variations will no longer appear under Global Styles > Browse styles, but instead in the relevant section for either colors or typography.

GitHub pull request: #60220

Props to @scruffian for writing the dev note.

Add custom Aspect Ratio presets through theme.json

WordPress 6.6 adds a new two new properties to the settings.dimensions object in theme.json. settings.dimensions.aspectRatios allows defining your own custom Aspect Ratio presets. These presets will be used by any block that uses the aspectRatio block support. In core that means the Image, Featured Image, and Cover block.

{
    "version": 2,
    "settings": {
        "dimensions": {
            "aspectRatios": [
                {
                     "name": "Square - 1:1",
                     "slug": "square",
                     "ratio": "1"
                 },
                 {
                     "name": "Standard - 4:3",
                     "slug": "4-3",
                     "ratio": "4/3"
                 },
            ]
        }
    }
}

Additionally the settings.dimensions.defaultAspectRatios key allows you to disable the list of core aspect ratio presets.

{
    "version": 2,
    "settings": {
        "dimensions": {
            "defaultAspectRatios": false
        }
    }
}

GitHub pull request: #47271

Props to @fabiankaegy for writing the dev note.

Root padding style updates

Root padding styles have been updated to address inconsistencies in pattern display and make the application of padding more predictable across different sets of markup. It’s now expected that:

  • Padding is applied to the outermost block with constrained layout (this is the layout enabled when “Inner blocks use content width” is set).
  • Padding is applied to all blocks with constrained layout that are full width or wide width.
  • Padding is applied to all blocks with constrained layout inside a full width flow layout (this is the layout enabled when “Inner blocks use content width” is unset) block.
  • Nested full width blocks will always be full width: a full width block inside another full width block will extend to the edges of the viewport.

GitHub pull request: #60715

Props to @isabel_brison for writing the dev note.

Added Text alignment block support

WordPress 6.6 adds new block support for setting the horizontal alignment of text.

This support is controlled by settings.typography.textAlign in theme.json, which defaults to true. To opt-in to this support for a block, add the supports.typography.textAlign field in block.json. For example:

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 3,
    "name": "gutenpride/my-block",
    "title": "My Block",
    "supports": {
        "typography": {
            "textAlign": true
        }
    }
}

Currently, core blocks do not support textAlign and the Text Alignment UIUI User interface is implemented separately without this block support. In the future, it is planned to gradually migrate core blocks to this support as well, and progress will be tracked in this Github issue: #60763.

The default horizontal alignment style can also be defined via theme.json. For example:

{
    "$schema": "https://schemas.wp.org/trunk/theme.json",
    "version": 3,
    "styles": {
        "blocks": {
            "core/heading": {
                "typography": {
                    "textAlign": "center"
                }
            }
        }
    }
}

There is a known issue where the default horizontal alignment defined in the global styles or theme.json cannot be overridden on a block instance, which is currently being addressed in #62260.

GitHub pull request: #59531

Props to @wildworks for writing the dev note.


Props to @juanmaguitar for review.

#6-6, #dev-notes, #dev-notes-6-6

Internationalization improvements in 6.6

Various internationalization (i18n) improvements are in WordPress 6.6, and this developers note focuses on these.

Enhanced support for only using PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files

WordPress 6.5 shipped with a completely new localization system with improved performance, which uses .l10n.php files in addition to .po and .mo files. This system was slightly enhanced in 6.6 to better support scenarios where only these PHP translation files exist, but not the others. This specifically applies to wp_get_installed_translations(), which is used to check which translations are installed, and the Language_Pack_Upgrader for updating translations.

See #60554 for more details.

New lang_dir_for_domain filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.

A new lang_dir_for_domain filter has been added to WP_Textdomain_Registry, allowing plugins to override the determined languages folder when using just-in-time translation loading. This is mostly useful for multilingual plugins.

See #61206 for more details.

Additional context for the load_translation_file filter

The load_translation_file filter was introduced in WordPress 6.5 to support changing the file path when loading translation files, regardless if it’s a PHP or an MO translation file. In 6.6, the localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. is passed as an additional argument to this filter, bringing it more in line with similar i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. filters.

See #61108 for more details.

Props to @audrasjb and @juanmaguitar for review.

#6-6, #dev-notes, #dev-notes-6-6, #i18n

Section Styles

In WordPress 6.6, Section Styles simplify the process of styling individual sections of a webpage by offering users a one-click application of curated styles, eliminating the need for repetitive manual configuration.

Table of Contents

  1. What’s Changed?
  2. Usage
    1. Registration of Block Style Variations
    2. Defining Block Style Variations
      1. Theme.json Partial Files
      2. Programmatically
      3. Via Theme Style Variations (Not Recommended)
  3. Backwards Compatibility
  4. Limitations
  5. What’s Next?
  6. Useful Links

What’s Changed?

Section-based styling has been enabled by extending the existing Block Styles feature (aka 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. style variations) to support styling inner elements and blocks. These enhanced block style variations can even be applied in a nested fashion due to uniform CSS specificity (0-1-0) for Global Styles introduced in WP 6.6.

In addition block style variations can now be:

  • registered across multiple block types at the same time
  • defined via multiple methods; primarily through theme.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. partials, or by passing a theme.json shaped object in the style’s data given to existing block style registration functions
  • customized via Global Styles (see also current limitations)

Usage

Registration of Block Style Variations

The block style variations that can be defined and manipulated through Global Styles are limited to those that have been registered with the WP_Block_Styles_Registry or via a block type’s styles property, such as Outline for the Button block. If a block style variation has not been registered, any theme.json or global styles data for it will be stripped out.

Any unregistered block style variation defined within a theme.json partial with be automatically registered.

Outlined below are three approaches to registering extended block style variations. The approaches leveraging theme.json definitions will automatically register the block style variation with the WP_Block_Styles_Registry.

Defining Block Style Variations

Outlined below are recommended approaches to registering extended block style variations.

Theme.json Partial Files

With the extension of block style variations to support inner element and block type styles, they essentially are their own theme.json file much like theme style variations. As such, block style variations also reside under a theme’s /styles directory. They are differentiated from theme style variations however by the introduction of a new top-level property called blockTypes. The blockTypes property is an array of block types the block style variation can be applied to.

A new slug property was also added to provide consistency between the different sources that may define block style variations and to decouple the slug from the translatable title property.

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 3,
	"title": "Variation A",
	"slug": "variation-a",
	"blockTypes": [ "core/group", "core/columns", "core/media-text" ],
	"styles": {
		"color": {
			"background": "#eed8d3",
			"text": "#201819"
		},
		"elements": {
			"heading": {
				"color": {
					"text": "#201819"
				}
			}
		},
		"blocks": {
			"core/group": {
				"color": {
					"background": "#825f58",
					"text": "#eed8d3"
				},
				"elements": {
					"heading": {
						"color": {
							"text": "#eed8d3"
						}
					}
				}
			}
		}
	}
}

Programmatically

Within a theme’s functions.php or 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, a call can be made to register_block_style, passing it an array of block types the variation can be used with as well as a theme.json shaped style object defining the variation’s styles. The style object provided here will be absorbed into the theme’s theme.json data.

register_block_style(
	array( 'core/group', 'core/columns' ),
	array(
		'name'       => 'green',
		'label'      => __( 'Green' ),
		'style_data' => array(
			'color'    => array(
				'background' => '#4f6f52',
				'text'       => '#d2e3c8',
			),
			'blocks'   => array(
				'core/group' => array(
					'color' => array(
						'background' => '#739072',
						'text'       => '#e3eedd',
					),
				),
			),
			'elements' => array(
				'link'   => array(
					'color'  => array(
						'text' => '#ead196',
					),
					':hover' => array(
						'color' => array(
							'text' => '#ebd9b4',
						),
					),
				),
			),
		),
	)
)

This approach has been enabled as a temporary means to facilitate ergonomic definitions of shared block style variations through theme style variations. It is being flagged here for transparency however it will likely be deprecated soon as the Global Styles architecture is updated to address growing complexity and simplify its mental model.

More details on what’s ahead for Global Styles can be found in this issue.

Shared block style variations can be defined via styles.variations. Style data defined under styles.variations will be copied to, and merged with, variation data stored at the block type level for all block types that have a matching variation registered for it.

Additionally, a new translatable title property has been added here to mirror the capabilities of the theme.json partial files outlined above.

The key for the variation correlates to the slug property for theme.json partials. In the example below, this would be variation-a.

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 3,
	"title": "Theme Style Variation",
	"styles": {
		"variations": {
			"variation-a": {
				"color": {
					"background": "#eed8d3",
					"text": "#201819"
				},
				"elements": {
					"heading": {
						"color": {
							"text": "#201819"
						}
					},
				},
				"blocks": {
					"core/group": {
						"color": {
							"background": "#825f58",
							"text": "#eed8d3"
						},
						"elements": {
							"heading": {
								"color": {
									"text": "#eed8d3"
								}
							}
						}
					}
				}
			},
		}
	}
}

Backwards Compatibility

As the Section Styles feature was implemented via extensions to block style variations rather than as a replacement, existing block style variations will continue to work as before.

Limitations

The following limitations for block style variations in WordPress 6.6 should be noted:

  1. Only root styles, i.e. those that apply directly to the block type the block style variation belongs to, can be configured via Global Styles.
  2. Block style variations cannot redefine or customize inner block style variations.
  3. Block style variations do not support their own custom settings values (yet).
  4. Custom block style variations cannot be applied and previewed within the Style Book.

What’s Next?

The Global Styles UIUI User interface for block style variations will be updated to facilitate the customization of all available styles for inner elements and block types. This includes potentially enhancing the Style Book to support block style variations.

Another future enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. is the possible support for settings per block style variations.

Props to @bph, @oandregal and @juanmaguitar for review

#6-6, #core-editor, #dev-note, #dev-notes, #dev-notes-6-6, #gutenberg

WordPress 6.6 CSS Specificity

One of the goals of WordPress 6.6 is to simplify the process for theme authors to override coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. styles while also maintaining support for Global Styles.

Historically, high CSSCSS Cascading Style Sheets. specificity in core styles has made customization challenging and unpredictable, often requiring complex CSS rules to achieve desired outcomes. Development of the new section styles feature also highlighted a need for uniform CSS specificity to support nesting such styles, facilitating the creation of sophisticated, layered designs.

Uniform 0-1-0 Specificity

WordPress 6.6 introduces several changes aimed at broadly reducing CSS specificity and making it more uniform. These changes generally fall into two categories:

  1. Core 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. Styles
  2. Theme.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. / Global Styles:

Where adjustments to CSS specificity were required, they were achieved by wrapping the existing selector within :root :where(...).

Core Block Styles

The choice of 0-1-0 specificity greatly reduced the changes required to existing core block styles as blocks targeting their default .wp-block- class already have the desired specificity.

Any blocks with Global Styles support using higher specificity selectors had those selectors wrapped in :root :where(...). This also applied to Block Styles (aka block style variations) and their default styles e.g., .wp-block-image.is-style-rounded img was updated to :root :where(.wp-block-image.is-style-rounded img).

Theme.json / Global Styles:

All block styles, including block style variation styles, output by theme.json and Global Styles are now limited to 0-1-0 specificity. Layout styles, e.g., constrained, flex, flow` etc., have also been limited however depending on the specific layout type and definition the final specificity varies slightly from 0-1-0 so they apply correctly.

Usage

The alignment of 0-1-0 specificity for Global Styles to default block selectors, e.g. .wp-block-, greatly reduces the need for updates. It’s recommended for theme and block authors to double-check their designs if they rely on custom CSS using more complex selectors.

Custom blocks

Authors of custom blocks that opt into global styles and apply default styling via a selector with greater than 0-1-0 specificity, should update those selectors wrapping them in :root :where().

An example could be a custom list block that opts into padding block support but defines default padding via:

ul.wp-block-custom-list {
    padding: 0;
}

Without adjusting the specificity of this rule, any customizations of the block type’s padding in Global Styles would be overridden. Wrapping the selector in :root :where() here would allow the style load order to determine which rule takes precedence.

// Block's stylesheet
:root :where(ul.wp-block-custom-list) { // This is a contrived example and could simply be `.wp-block-custom-list`
    padding: 0;
}

// Global Styles - Loaded after the block styles
:root :where(.wp-block-custom-list) {
    padding: 1em;
}

Block Styles (aka Block Style Variations)

Theme authors customizing Block Styles for a core block will need to limit their style’s specificity, so the block style continues to be configurable via Global Styles.

For example, take a theme that tweaks the border radius for the Image block’s rounded block style:

.wp-block-image.is-style-rounded img {
    border-radius: 2em;
}

Without adjustment, this style would override any customizations made to the Rounded block style within Global Styles.

In this case, the theme can tweak its rounded image style to the following:

//. Theme style
:root :where(.wp-block-image.is-style-rounded img) {
    border-radius: 2em;
}

// Global Styles - Loaded after the block styles
:root :where(.wp-block-image.is-style-rounded img) {
    border-radius: 4px;
}

Zero-Specificity, CSS Layers, and the future

Reducing all core styles to zero specificity was explored before settling on 0-1-0 specificity. Zero specificity unfortunately wasn’t robust in the face of common reset stylesheets and required more widespread changes.

CSS Layers were also evaluated but fell short due to not being able to enforce all styles belonged to a layer. This will change in the future at which point a combination of CSS Layers and zero-specificity can be revisited to further the benefits gained in this initial reduction of CSS specificity.

More history and context can be found in this detailed discussion.

Useful Links

Props to @bph and @juanmaguitar for review

#6-6, #core-editor, #dev-note, #dev-notes, #dev-notes-6-6, #gutenberg

Summary, Dev Chat, June 19, 2024

Start of the meeting in 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/., facilitated by @mikachan. 🔗 Agenda post.

Announcements

  • WordPress 6.6 Beta 3 was released yesterday! Thank you to all the contributors for a successful release. Please continue to test and report any issues you find.
  • 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/ 18.6 is scheduled for release today. This release will not be included in WordPress 6.6.
  • Thank you so much to everyone who joined and contributed to the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tables on 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/. at WCEU!

Forthcoming Releases

Next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.6

We are currently in the WordPress 6.6 release cycle. See the Roadmap Post for details about what is planned for this release.

Discussion

@jeffpaul raised this just-before-chat note from Josepha on the About page and Microsites that’s worth highlighting and driving folks there for input.

Hello in here, wonderful release squad! I understand that my request about the About Page vs Microsites has gotten confusing, so I’m here to answer whatever questions we have.

In a post-release retrospective a while back, I noticed that we were working on a lot of duplicate content in various places every release. I always want to make sure that we are making the most of the time we put in, so I had asked if we could write/create the content for the microsite first, and then copy/paste highlights from it to the About page in the CMS (+ link to the microsite), and the release post.

@marybaum, @ryelle, and @annezazu are working to update the Google doc to reflect the latest priorities from the microsite for final review ahead of the upcoming string freeze.

@meher raised questions in this thread about whether a BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 4 is needed due to bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes that didn’t make it into Beta 3?

@joemcgill said that there is no requirement to do an extra Beta release to test commits that happen between Beta 3 and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1.

@hellofromtonya mentioned that there have also been times when an unscheduled Beta release has been done when there is a fix that needs more exposure and testing before RC 1.

After the meeting, @jorbin suggested that we codify the philosophy so we can make it easier to make these decisions in the future, and shared the following thoughts:

  1. There needs to be a large enough change (either quantity or quality) for the investment to make sense.
  2. It’s a not insignificant amount of work for each beta release. Between an announcement post, package creation, package testing and commits, it’s an investment.
  3. The investment should pay for itself in increased confidence. This confidence comes in the way of time that people can test and bug reports or bug elimination confirmations. 
  4. If possible, others investments such as a make post or a GB release may make the most sense since those can allow for increased confidence with a lower amount of required work.

Open Floor

There was no time for open floor today.

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

Props to @mikachan for proofreading.

#6-6, #core, #dev-chat, #summary

Roster of design tools per block (WordPress 6.6 edition)

Below you find a table that lists all coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks available in the inserter marks in the grid the feature they support in 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. It’s a basic lookup table that helps developers to find the information quickly.

While this post is released as part of 6.6, the content summarizes changes between 6.1 and 6.6. This is an update of the post published for the 6.1 release and provides a cumulative list of design supports added with the last five WordPress releases.

The features covered are:

  • Align
  • Typography,
  • Color,
  • Dimension,
  • Border,
  • Layout,
  • Gradient,
  • Duotone,
  • Shadow,
  • Background image*
  • Pattern overrides / Block Bindings (PO/BB)

*Note: In WordPress 6.6, the background image tools are only available for Group, Pull quote, Site Logo blocks and as side-wide feature. For Quote, Verse and Post content blocks, it’s only 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/ 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 18.6 and slated for WordPress 6.7.

Updated on July 3 with the list tracking issues to add various design tools to core blocks, so one can follow along the progress.

Work in progress

The issue Tracking: Addressing Design Tooling Consistency lists tracking issues for individual block supports.

Props to @annezazu and @juanmaguitar for review.

#6-6, #dev-notes, #dev-notes-6-6, #editor

Site-wide background images in WordPress 6.6

In WordPress 6.6 you can define site-wide background images in theme.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. and the Site Editor.

A “site-wide” background image is one whose value is set on the body element using the background-image CSSCSS Cascading Style Sheets. property, and, therefore, appears on every page of a site.

An example might be a photo that stretches with the window size, or a repeating pattern background.

To customize how background images appear, WordPress 6.6 supports the following background style properties:

  • background position
  • background size
  • background repeat

Usage

In theme.json

In theme.json, site-wide background images and their properties are defined under "styles.background".

For example, as a single image URI in styles.background.backgroundImage.url:

{
	"styles": {
		"background": {
			"backgroundImage": {
				"url": "<a href="http://path.to/some/image.png">http://path.to/some/image.png</a>"
			},
			"backgroundSize": "cover"
		}
	}
}

For the above, WordPress will automatically wrap the image in the CSS url() function.

styles.background.backgroundImage also accepts string values, which can be any valid CSS value for background-image :

{
	"styles": {
		"background": {
			"backgroundImage": "url(<a href="http://path.to/some/image.png">http://path.to/some/image.png</a>)",
			"backgroundPosition": "center"
		}
	}
}

The above examples use absolute paths to image files. Such files would need to be hosted and maintained.

Most likely, theme developers will want to define background images using paths to a theme’s own assets. This ensures that the theme is self-contained and portable.

Relative paths to theme assets are defined using the file:./ prefix:

{
	"styles": {
		"background": {
			"backgroundImage": {
				"url": "file:./assets/my-theme-background.jpg"
			},
			"backgroundSize": "cover"
		}
	}
}

Paths are resolved on the backend using get_theme_file_uri.

Paths defined this way must be relative to the theme root, regardless of where the theme.json sits in your theme’s directory. This follows an existing pattern for web fonts.

Despite the dot in file:./, the special symbols dot (.) and double dot (..) for directory navigation are not supported in theme.json relative paths. This means, for example, that theme style variation files, which reside under the style/ directory, would use the same path as the theme’s main theme.json.

An issue exists to make the syntax more consistent.

In the Site Editor

Background images can be also be uploaded, and their properties tweaked through the Site Editor’s styles panel.

In WordPress 6.6, background image controls are located under Styles > Layout.

The styles panel navigation is undergoing review however, so in upcoming versions the location may change.

As well as setting new background images, it’s possible to “remove” a theme’s default background image in the Site Editor.

Relative paths to any images in theme.json are resolved on the backend, and are sent in the _links array of Global Styles REST responses. The Editor uses the resolved values to generate theme CSS in the client.

Limitations

In WordPress 6.6, the ability to define background images in theme.json exists only for top-level styles. Top-level styles apply to the body element. An open PR aims to also enable the feature at 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. level in the next WordPress release.

Work is also underway to:

  • add support for fixed images, using the background-attachment CSS property.
  • avoid conflicts between gradient backgrounds, whose values are currently set to the background property, and background-image. The proposal is that gradient backgrounds will also be set to background-image, and, where both an image and a gradient are defined, their values are merged .

Backwards compatibility

WordPress already has support for custom site-wide background images in the Customizer. The theme.json variant will not affect themes that have enabled this feature.

Background images added in the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. take precedence over those set in theme.json or in the Site Editor.

An ongoing discussion seeks to harmonize the two features.

What’s next

Progress on upcoming work is tracked on Background Image block support follow-up tasks.

Props to @andrewserong and @juanmaguitar for review

#6-6, #core-editor, #dev-note, #dev-notes, #dev-notes-6-6, #gutenberg

Theme.json version 3

The theme.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. version is incremented whenever a breaking change would need to be made to the 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.. This allows consumers to opt-in to the breaking change by updating the version. Older theme.json versions will always be supported in the latest versions of WordPress.

Updating to version 3 is recommended when your minimum supported WordPress version reaches 6.6. See theme.json version 3 frequently asked questions for more information on when to update. Then check out the theme.json reference for migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. instructions when you are ready to update.

Breaking changes in version 3

Starting with theme.json version 3 the default behavior for using the same slugs as the default fontSizes and spacingSizes presets has been changed to match how other theme.json presets work: from always overriding the default presets to requiring defaultFontSizes or defaultSpacingSizes to be false in order to override the default presets.

Default font sizes

settings.typography.defaultFontSizes is a new option in theme.json v3. It controls whether the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. provided default settings.typography.fontSizes presets are shown and used.

The default fontSizes presets’ slugs are: small, medium, large, and x-large.

  • When defaultFontSizes is true it will show the default font sizes in the editor and prevent the theme from creating presets using the default slugs.
  • When defaultFontSizes is false it will hide the default font sizes in the editor and allow the theme to use the default slugs.

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 defaultFontSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.

For classic themes there is a new theme support default-font-sizes which is also true by default. However, unlike block themes, it is set to false when editor-font-sizes theme support is defined.

In theme.json v2, the default font sizes were only shown when theme sizes were not defined. A theme providing font sizes with the same slugs as the defaults would always override the defaults.

To keep behavior similar to v2 with a v3 theme.json:

  • If you do not have any fontSizes defined, defaultFontSizes can be left out or set to true.
  • If you have some fontSizes defined, set defaultFontSizes to false.
--- theme.json v2
+++ theme.json v3
@@ -1,24 +1,25 @@
 {
-	"version": 2,
+	"version": 3,
 	"settings": {
 		"typography": {
+			"defaultFontSizes": false,
 			"fontSizes": [
 				{
 					"name": "Small",
 					"slug": "small",
 					"size": "10px"
 				},
 				{
 					"name": "Medium",
 					"slug": "medium",
 					"size": "14px"
 				},
 				{
 					"name": "Large",
 					"slug": "large",
 					"size": "20px"
 				}
 			]
 		}
 	}
 }

Default spacing sizes

settings.spacing.defaultSpacingSizes is a new option in theme.json v3. It controls whether the core provided default settings.spacing.spacingSizes presets are shown and used.

The default spacingSizes presets’ slugs are: 20, 30, 40, 50, 60, 70, and 80.

  • When defaultSpacingSizes is true it will show the default spacing sizes in the editor and prevent the theme from creating presets using the default slugs.
  • When defaultSpacingSizes is false it will hide the default spacing sizes in the editor and allow the theme to use the default slugs.

defaultSpacingSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.

For classic themes there is a new theme support default-spacing-sizes which is also true by default. However, unlike block themes, it is set to false when editor-spacing-sizes theme support is defined.

In theme.json v2, the default spacing sizes were only shown when theme sizes were not defined. A theme providing spacing sizes with the same slugs as the defaults would always override the defaults.

Furthermore, there are two settings that can be used to set theme level spacing sizes: spacingSizes and spacingScale. With theme.json v3, presets from both will be merged together and sorted numerically by slug. Presets defined in spacingSizes will override those generated by spacingScale if the slugs match.

In theme.json v2, setting both spacingSizes and spacingScale would only use the values from spacingSizes.

To keep behavior similar to v2 with a v3 theme.json:

  • If you do not have any spacingSizes presets or spacingScale config defined, defaultSpacingSizes can be left out or set to true.
  • If you disabled default spacing sizes by setting spacingScale to { "steps": 0 }, remove the spacingScale config and set defaultSpacingSizes to false.
  • If you defined only one of either spacingScale or spacingSizes for your presets, set defaultSpacingSizes to false.
  • If you defined both spacingScale and spacingSizes, remove the spacingSizes config and set defaultSpacingSizes to false.
--- theme.json v2
+++ theme.json v3
@@ -1,27 +1,25 @@
 {
-	"version": 2,
+	"version": 3,
 	"settings": {
 		"spacing": {
-			"spacingScale": {
-				"steps": 0
-			},
+			"defaultSpacingSizes": false,
 			"spacingSizes": [
 				{
 					"name": "Small",
 					"slug": "40",
 					"size": "1rem"
 				},
 				{
 					"name": "Medium",
 					"slug": "50",
 					"size": "1.5rem"
 				},
 				{
 					"name": "Large",
 					"slug": "60",
 					"size": "2rem"
 				}
 			]
 		}
 	}
 }

Props to @scruffian and @juanmaguitar for assistance with writing and reviewing this post.

#6-6, #dev-note, #dev-notes, #dev-notes-6-6

Social Links block changes in WordPress 6.6

WordPress 6.6 includes some changes affecting both the social link and social links blocks.

HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. changes when using a social links 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. inside a Navigation Block

As of WordPress 6.6, the social links block will be wrapped in a list item (li tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) when used in the navigation block. This change fixed an issue where the navigation block produced invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. HTML (the social links block’s ul was nested directly under the navigation block’s ul).

This may affect some themes that depend on the exact nesting of the HTML elements, for example using a selector like .wp-block-navigation__container > .wp-block-social-links.

Here are some examples of how the HTML has changed:

Example of navigation block and social links markup before WordPress 6.6

<ul class="wp-block-navigation__container wp-block-navigation">
  <ul class="wp-block-social-links is-layout-flex wp-block-social-links-is-layout-flex">
  </ul>
</ul>

Example of navigation block and social links markup after WordPress 6.6

<ul class="wp-block-navigation__container wp-block-navigation">
  <li class="wp-block-navigation-item">
    <ul class="wp-block-social-links is-layout-flex wp-block-social-links-is-layout-flex">
    </ul>
  </li>
</ul>

Class name changes to the social link block

As of WordPress 6.6, the social link block will no longer output the components-button class name on its button element within the block editor.

Themes targeting this class name for editor styles should use the existing wp-block-social-link-anchor class instead.

It’s expected that most themes will be doing this already, so for most no change will be required.

Why was this class name present?

The class name was a side-effect of using the Button ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. component from the @wordpress/components package (which can also be referenced as wp.components.Button) within the social link block’s implementation.

Why is this being changed?

  • The components from @wordpress/components are intended for use in the editor’s general interface and have a lot of opinionated CSSCSS Cascading Style Sheets., while the on-canvas part of a block is intended to be styled by a theme and should have minimal CSS.
  • Updates made to styles in the @wordpress/components can have unintended side-effects for the block’s appearance, and can also raise or lower the specificity of the styles above or below what a theme implementer might expect. The change to the block’s implementation leads to more stable and predictable css specificity.
  • There’s no guarantee the styles from @wordpress/components will continue to work in the iframed editor canvas, some CSS variable references in the styles were already not working as expected.
  • The styles that were previously added to the social link block contravene the CSS guidelines used by developers on the WordPress project.

Props to @ramonopoly and @juanmaguitar for review

#6-6, #dev-note, #dev-notes, #dev-notes-6-6