Make WordPress

WordPress 7.2 introduces a new textShadow typography 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. support, along with text shadow presets and a user interface in both the block inspector and Global Styles. The Paragraph and Heading blocks are the first coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks to adopt it.

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 by the repository owner. https://github.com/ issue: #47904 | PR: #79584

Background

WordPress 7.1 added the ability to declare a text-shadow value under styles.typography in theme.json (#73320, see the Text Shadow Support in Global Styles 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.). That first step covered theme.json styling only. There was no control in the editor, no preset system, and no way to set a shadow on an individual block.

WordPress 7.2 builds on this foundation. Text shadows now work like font sizes and shadows: themes define presets, users pick or create them in Global Styles, and blocks that opt in get a control in the Typography panel.

How to opt in

In WordPress 7.2, the Paragraph (core/paragraph) and Heading (core/heading) blocks support text shadow by default. Other blocks can opt in through supports.typography.textShadow in their block.json:

{
	"supports": {
		"typography": {
			"textShadow": true
		}
	}
}

When a block declares support, a Text shadow control is added to the Typography panel of the block inspector, letting users choose from the predefined text shadow presets:

The control is not shown by default. Users can reveal it from the Typography panel’s options menu, or a block can show it automatically through __experimentalDefaultControls.

{
	"supports": {
		"typography": {
			"textShadow": true,
			"__experimentalDefaultControls": {
				"textShadow": true
			}
		}
	}
}

When a text shadow preset is applied to a block, its slug is stored in the textShadow attribute and output as a CSSCSS Cascading Style Sheets. class:

<!-- wp:paragraph {"textShadow":"strong"} -->
<p class="has-strong-text-shadow">Hello World</p>
<!-- /wp:paragraph -->

Defining presets

WordPress ships with two default text shadow presets, Light and Strong. Like font size and color presets, these can be managed in Global Styles (Typography > Text shadow presets), where users can change the styles of the default presets or add their own custom presets.

Themes can also define their own presets in theme.json with settings.typography.textShadowPresets. Each preset needs a name, a slug, and a textShadow value:

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 3,
	"settings": {
		"typography": {
			"textShadowPresets": [
				{
					"name": "Soft",
					"slug": "soft",
					"textShadow": "1px 1px 2px rgba(0, 0, 0, 0.3)"
				},
				{
					"name": "Glow",
					"slug": "glow",
					"textShadow": "0 0 8px rgba(255, 215, 0, 0.8)"
				}
			]
		}
	}
}

Each preset outputs a --wp--preset--text-shadow--{slug} CSS custom property and a .has-{slug}-text-shadow class. Theme presets are shown alongside the default presets.

The Text shadow control lists all available presets and a None option. When there are 7 or more presets, it switches from a list to a compact dropdown.

The styles.typography.textShadow property introduced in WordPress 7.1 now also accepts a preset reference, such as var:preset|text-shadow|light. For more examples of applying text shadows globally, per block, or per element, see the Text Shadow Support in Global Styles dev note.

Values set in Global Styles override theme defaults, and values set on a block instance override both, following the same cascade as other typography styles.

Disabling text shadow

To hide the default presets, set defaultTextShadowPresets to false. To remove the feature entirely, also set textShadow to false:

{
	"version": 3,
	"settings": {
		"typography": {
			"textShadow": false,
			"defaultTextShadowPresets": false
		}
	}
}

Further reading

• PR: Add textShadow typography support and UI (#79584)
• Previous step: Global Styles: Add textShadow style support (#73320)
• Tracking issue: Typography: Add “Text shadow” support (#47904)
• Dev note: Text Shadow Support in Global Styles
• Reference: Block Supports: typography.textShadow

Props to @ramonopoly for review.

#7-2, #dev-notes, #dev-notes-7-2

MigrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. from Emotion to SCSS Modules

WordPress 7.2 completes the migration from Emotion to SCSS Modules in @wordpress/components, continuing the work described in the WordPress 7.1 dev note. This removes the package’s remaining Emotion dependencies and reduces styling runtime and build overhead. Most consumers using documented props and className will not need changes. Code that relied on Emotion-specific behavior should review the following migration details. (#85022)

Replace the legacy css prop on View

__experimentalView still accepts the css prop for compatibility, but the prop has no effect. Use style for inline declarations or className for stylesheet rules, including pseudo-classes and media queries.

import { __experimentalView as View } from '@wordpress/components';

// Before.
<View css={ { padding: 16 } } />;

// After.
<View style={ { padding: 16 } } />;

Also review custom selectors and tests that depend on generated Emotion classes or internal markup. Use classes you control or documented component selectors.

Combine Emotion fragments whose declaration order matters

Components no longer performs Emotion style merging when joining class names. If your styles depend on overlapping declarations, shorthand/longhand order, or matching nested selectors, combine those fragments in a single css() call before passing them to cx():

import { css, cx } from '@emotion/css';

const className = cx(
	css( baseStyles, isExpanded && expandedStyles ),
	consumerClassName
);

Independent classes do not need this treatment. Applications can continue using Emotion without adopting SCSS Modules.

Provide an Emotion cache for other documents

__experimentalStyleProvider no longer manages an Emotion cache. If your @emotion/react or @emotion/styled components relied on it to insert styles into an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. or another document, provide a cache targeting that document’s <head>:

import createCache from '@emotion/cache';
import { CacheProvider } from '@emotion/react';
import { __experimentalStyleProvider as StyleProvider } from '@wordpress/components';

// Create once for each destination document, outside rendering.
const emotionCache = createCache( {
	key: 'my-plugin-iframe',
	container: targetDocument.head,
} );

// Wrap the content rendered into that document.
<StyleProvider document={ targetDocument }>
	<CacheProvider value={ emotionCache }>
		{ children }
	</CacheProvider>
</StyleProvider>;

Create the cache after the destination document is ready and reuse it while that document remains the same. Portals into another document also need a cache for their destination.

Keep StyleProvider for package CSSCSS Cascading Style Sheets. Module registration, along with the package and design-token stylesheets your application requires. CSS Module styles still use runtime <style> injection.

@emotion/css has a separate cache that ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org’s CacheProvider does not configure. Use @emotion/css/create-instance with the destination <head> as its container, then generate classes with that instance’s css and cx functions.

If your application requires a CSP nonce, configure it on your own Emotion cache. This does not add nonce support to CSS Module style injection. See the cross-document setup guidance for package styles and design tokens.

Review props, dependencies, and build configuration

• __unstableMotion props: Components no longer supplies Framer Motion’s optional @emotion/is-prop-valid dependency. Where that validator previously ran, unknown DOM props may now be forwarded. 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. application-only props before they reach DOM elements, including inside custom React components. Framer Motion continues filtering its animation props.
• Emotion dependencies: Declare any Emotion packages your application imports as direct dependencies. Components and DataViews no longer supply them transitively. Remove Emotion dependencies or compiler plugins only when your application, tests, and tooling no longer use them.
• Custom builds: @wordpress/build no longer runs the automatic Babel pass specific to packages/components. Projects or forks that relied on it for Emotion transforms or project Babel configuration should run those transforms explicitly before @wordpress/build. (#84707)

After migrating, check custom styles and dynamic variants in the main document and any iframe or portal documents, including RTL layouts where relevant.

See the migration tracking issue for further details.

FontFamilyControl styling changes

Starting in WordPress 7.2, __experimentalFontFamilyControl from @wordpress/block-editor uses @wordpress/ui. Consumers with custom CSS overrides should review the following changes. (#84715)

What changed

The .block-editor-font-family-control root class remains available. Labels and selected hints now use these control-specific classes:

• .block-editor-font-family-control__label
• .block-editor-font-family-control__hint

The control no longer adds the following legacy classes:

• .components-custom-select-control
• .components-custom-select-control__item
• .components-custom-select-control__item-hint
• .components-custom-select-control__hint
• .has-hint
• .components-input-base
• .components-input-control__container
• .components-input-control__backdrop
• .components-input-control__suffix
• .components-input-control-suffix-wrapper
• .components-base-control__label

Popup items now render outside the control root, so selectors that target them as descendants of .block-editor-font-family-control no longer match.

What to do

Update label and selected-hint overrides to use the control-specific classes above.

Custom options[].style now applies only to the option label. To style an entire popup item, supply options[].className and target that class directly in your stylesheet without relying on the item being inside the control root.

New presentation prop for palette swatches

ColorPalette, GradientPicker, and DuotonePicker in @wordpress/components now accept a presentation prop that controls swatch interaction and 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) semantics. (#82023)

The available values are:

• "listbox", the default: Uses one tab stop, arrow-key navigation, and aria-selected to expose selection.
• "toggle-buttons": Gives each swatch its own tab stop and exposes selection through aria-pressed.
• "command-buttons": Gives each swatch its own tab stop without exposing selection state. Use this when activating a swatch performs an action, such as opening an editor.

Replace asButtons

The asButtons prop is deprecated but remains supported for backward compatibility.

• Replace asButtons or asButtons={ true } with presentation="toggle-buttons".
• Remove asButtons={ false } to use the default listbox presentation, or replace it with presentation="listbox".

When both props are supplied, presentation takes precedence.

The loop prop applies only to the "listbox" presentation. In "command-buttons" mode, activating a predefined swatch always calls onChange, even if value or selectedSlug already identifies that swatch.

Deprecated components

Starting in WordPress 7.2, the following components from @wordpress/components are deprecated, with removal scheduled for WordPress 7.4.

• Animate: Write your own CSS animations, preferably using the motion tokens from @wordpress/theme. (#80931)
• Divider (__experimentalDivider): Prefer a surrounding component’s Separator, such as Menu.Separator, when available. Otherwise write your own CSS, preferably using the design tokens from @wordpress/theme. (#83040)
• Elevation (__experimentalElevation): Use the elevation tokens from @wordpress/base-styles. (#83269)
• ResponsiveWrapper: Use the CSS aspect-ratio property. (#83347)
• Scrollable (__experimentalScrollable): Write your own CSS. (#83273)
• Surface (__experimentalSurface): Write your own background and border CSS, preferably using the design tokens from @wordpress/theme. (#80943)
• Tip: Use Notice from @wordpress/ui. See the migration guide for the replacement composition. (#84197)
• ZStack (__experimentalZStack): Write your own CSS. (#83344)

Co-authored by @0mirka00 and @mciampini.

Props to @aduth for review.

#7-2, #dev-notes, #dev-notes-7-2

Joe Youngblood’s report surprised me because I didn’t realize our conservative sanitize_username approach doesn’t apply to registrations when you’re not in multi-site mode.

https://x.com/YoungbloodJoe/status/2118795342875431305

We should assume every CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) attempt is hostile. Where else can we tighten up the range of what we accept? For usernames we could make new registrations have stricter rules than before without breaking backwards compatibility.

Just like we ship with moderated comments on by default, I think it’s a good opportunity to look at every instance where we send an email and look at how we can become less interesting to spammers. Should comment notification emails not include the content by default, and instead just link you to the moderation page?