WordPress 7.2 Technical Breakdown: HTML API Sanitization, Viewport State APIs, and Core Component Deprecations

WordPress 7.2 Release Schedule and Key Scope Decisions

The roadmap for WordPress 7.2 establishes the critical schedule leading up to the final release of the year. Beta 1 is scheduled for October 20, 2026, followed by Release Candidate 1 (RC1) on November 17, and the general availability release on December 8, 2026. Developers building plugins, themes, or maintaining custom client stacks should align their testing workflows within this key window.

In addition to upcoming milestone dates, several architecture decisions have altered what is included in the release scope:

• Real-Time Collaboration: Intentionally excluded from the 7.2 release. The development team is transitioning the feature to a server-aware architecture. Work continues within dedicated feature plugins, such as the Presence API plugin, which recently introduced new functions and dedicated database tables.
• React 19 Upgrade: Listed on the broader roadmap, but explicitly flagged as unlikely to fully land within the core WordPress 7.2 release.
• Security Features: Core improvements include email notifications when new Application Passwords are created, automatic non-HTTPS environment detection, safer default_role handling, and SameSite cookie updates. A CLI-only version of the Secrets API is tentatively planned, while a formal sudo mode proposal remains under development.

HTML API Refactoring for wp_kses() Sanitization

WordPress is actively rebuilding its fundamental HTML sanitizer, wp_kses(), on top of the robust, high-performance HTML API. Targeted for either 7.2 or 7.3 depending on test suite feedback, this overhaul shifts how markup string sanitization occurs across the core ecosystem.

The revised parser normalizes incoming markup structure, strips the internal contents of <script> and <style> tags completely, and systematically rejects malformed SVG elements, MathML constructs, and invalid HTML comments. Extension authors who perform post-sanitization comparison, regex extraction, or database validation against raw HTML strings should run test suites against WordPress trunk immediately.

For legacy environments that encounter unresolvable breaking changes during testing, core provides a temporary override filter:

add_filter( 'wp_kses_force_legacy_parser', '__return_true' );

This filter acts strictly as a short-term stopgap while underlying markup issues are resolved and reported to core Trac tickets.

Custom Responsive Controls via Block Editor Viewport APIs

Responsive style states were introduced in WordPress 7.1, but custom block developers were previously unable to build user interface controls for per-breakpoint styling because the underlying helper utilities remained private. Gutenberg 24.1 publicly exports these viewport state management functions from the @wordpress/block-editor package.

Developers can now utilize getStyleForState() and setStyleForState() along with the block editor store selectors getSelectedBlockStyleState() and hasSelectedBlockStyleState(). This enables custom block controls to read and apply values tailored to specific viewports, such as @mobile or @desktop.

The following practical example demonstrates how to set a block’s minimum height attribute specifically for mobile viewports inside an edit component:

import { getStyleForState, setStyleForState } from '@wordpress/block-editor';

// Target mobile viewport state
const state = { viewport: '@mobile' };
const stateStyle = getStyleForState( attributes.style, state ) || {};

// Update block attributes with scoped responsive rules
setAttributes( {
    style: setStyleForState( attributes.style, state, {
        ...stateStyle,
        dimensions: {
            ...stateStyle.dimensions,
            minHeight: '50vh',
        },
    } ),
} );

Additionally, block position properties can vary per breakpoint, allowing elements like site headers to adopt sticky positioning exclusively on mobile screens while remaining static on larger displays.

Database Behavior Changes and db.php Drop-in Execution

A notable core database update involves wpdb, which now strips the NO_BACKSLASH_ESCAPES SQL mode from WordPress database sessions by default. This change ensures consistent SQL escaping behavior across diverse MySQL and MariaDB host configurations.

If a legacy application or custom plugin explicitly relies on NO_BACKSLASH_ESCAPES remaining active in the database session, developers must utilize the incompatible_sql_modes filter. Because database connection initialization occurs extremely early in the WordPress boot phase, standard plugins and mu-plugins load too late to intercept this logic.

The filter must be executed strictly within a custom wp-content/db.php drop-in file:

<?php
// Executed inside wp-content/db.php
add_filter( 'incompatible_sql_modes', function ( $modes ) {
    return array_diff( $modes, [ 'NO_BACKSLASH_ESCAPES' ] );
} );

Block Supports Consistency, Text Shadow Presets, and Theme Changes

Gutenberg 24.1 delivers broad design tool consistency across the editor ecosystem. Approximately 140 pull requests expanded core block supports, enabling features like background images, gradients, drop shadows, borders, text columns, and link/button colors across nearly every native core block.

Theme authors can transition away from custom CSS declarations for blocks like Code or Latest Posts, migrating layout rules directly into the theme.json structure under styles.blocks. Note that blocks like Accordion, Tabs, Tab Panel, and Post Template now append has-link-color class names to generated markup, which may require specificity checks in existing themes.

Text shadow has also been upgraded to a native block support with full preset functionality. Custom blocks can opt into text shadow controls by declaring support in their block.json manifesto:

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

Themes define custom text shadow options inside theme.json, which automatically generates corresponding CSS variables and utility classes:

{
  "settings": {
    "typography": {
      "defaultTextShadowPresets": false,
      "textShadowPresets": [
        {
          "name": "Soft",
          "slug": "soft",
          "textShadow": "0.05em 0.05em 0.1em rgba(0, 0, 0, 0.25)"
        }
      ]
    }
  }
}

This configuration produces the CSS custom property --wp--preset--text-shadow--soft and the global layout class .has-soft-text-shadow.

WordPress 7.2 also departs from historical precedent by introducing Ipsum, a default blog theme that drops year-based naming conventions. Ipsum is designed as a minimalist, typography-focused canvas with style variations that systematically recolor both canvas elements and embedded images while maintaining full WCAG AA contrast compliance.

Icon Vector Redraws and Private Collection Registration

The core SVG icon library underwent a full redesign in Gutenberg 24.1, converting approximately 330 core icons from fill-based vector shapes to stroke-based vector paths. Each redrawn SVG element explicitly defines an inline fill: none attribute.

Consequently, custom CSS rules relying on svg { fill: ... } will no longer re-color core admin or UI icons. Developers must update admin stylesheets to target the CSS color property instead. Additionally, developers updating @wordpress/icons in custom build pipelines must ensure @wordpress/components is updated simultaneously to prevent class name mismatches.

For custom icon management, the Icon Registration API introduced in 7.1 now supports restricting visibility via a public parameter:

wp_register_icon_collection( 'themeslug-admin', [
    'label'  => __( 'Theme Admin Icons', 'themeslug' ),
    'public' => false,
] );

Icons registered within a non-public collection remain available programmatically via wp_get_icon(), but are hidden from REST API responses and blocked from appearing inside the user-facing front-end Icon block picker UI.

Automated Security Scans for Plugin Directory Submissions

Developers publishing extensions to the WordPress.org plugin directory face an updated submission lifecycle. The Plugins team has integrated an automated security review protocol directly into the release cooldown process.

During the cooldown window, automated AI detection models paired with Jetpack Scan evaluate code changes. Releases categorized as high-risk are automatically blocked from distribution, and automated alerts containing scan findings are emailed directly to committer accounts. Plugin authors must ensure that committer email addresses registered on WordPress.org profiles are actively monitored.

Component Deprecations and WordPress Playground Enhancements

Gutenberg 24.1 formalizes the deprecation of five legacy UI components within the @wordpress/components package: Divider, ResponsiveWrapper, Scrollable, ZStack, and Elevation. Marked deprecated as of 7.2, complete removal is scheduled for WordPress 7.4. Developers should replace ResponsiveWrapper with modern CSS aspect-ratio properties, and use Separator in place of Divider.

Media handling components have also stabilized: unstableFeaturedImageFlow has been officially renamed to featuredImageFlow, with the original prefix scheduled for removal in 7.4.

To support browser-based testing, WordPress Playground has added two major tools inside the Dev Tools Dock:

• Terminal Tool: Runs real-time PHP and WP-CLI commands against the running Playground instance. It operates without a standard TTY interface; therefore, interactive or persistent CLI processes (such as wp shell) are rejected. Blueprint wp-cli steps follow identical security constraints.
• Email Tool: Intercepts and displays all transactional messages dispatched through wp_mail() directly within the browser UI. This utility captures mail sent via standard internal PHP sendmail routines, but does not intercept emails routed through third-party SMTP plugins or external API integrations.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.