WordPress 7.2 is the last major release of 2026, and Beta 1 is scheduled for October 20, 2026. RC1 follows on November 17 and the final release is planned for December 8.
That gives plugin and theme developers roughly seven weeks to catch problems before thousands of client sites auto-update. Most changes are additive, but a few can quietly break markup, styles or database code.
Here is a practical checklist of what to test, with code you can drop in today.
📌 Last week we shared our full performance stack in How to Build Ultra-Fast WordPress Sites in 2026: The Essential Developer Stack. This post is the "before you update" companion to it.
⏱️ The 7.2 timeline at a glance
| Milestone | Date |
|---|---|
| Beta 1 | October 20, 2026 |
| Release Candidate 1 | November 17, 2026 |
| Final release | December 8, 2026 |
The fastest way to test is a disposable WordPress Playground instance with the beta loaded, or a staging site running trunk plus the latest Gutenberg plugin.
1. wp_kses() is being rebuilt on the HTML API
This is the change most likely to surprise you. WordPress's HTML sanitizer is being rebuilt on top of the HTML API (targeting 7.2 or 7.3, depending on testing).
The new parser normalizes the HTML it returns, removes the contents of <script> and <style> elements, and rejects some malformed SVG, MathML and comments.
Why it matters: if your code sanitizes HTML and then compares, hashes, caches or snapshot-tests the result, the output may no longer match byte-for-byte.
There is a temporary escape hatch while you fix things:
// Temporary only: fall back to the legacy kses parser.
add_filter( 'wp_kses_force_legacy_parser', '__return_true' );
Treat this as a stopgap and report breakages on the Trac ticket. The core team also published a tool to check your HTML against the new parser.
2. Your blocks can now offer per-breakpoint settings
Responsive style states arrived in 7.1, but only core blocks could use them. Gutenberg 24.1 made the helpers public, so custom blocks can now store styles per viewport.
@wordpress/block-editor now exports getStyleForState() and setStyleForState(). Example: a custom block that sets a different padding on mobile only.
import { getStyleForState, setStyleForState } from '@wordpress/block-editor';
function setMobilePadding( attributes, setAttributes, value ) {
const mobile = { viewport: '@mobile' };
const current = getStyleForState( attributes.style, mobile ) || {};
setAttributes( {
style: setStyleForState( attributes.style, mobile, {
...current,
spacing: { ...current.spacing, padding: value },
} ),
} );
}
Position can also vary by viewport now, so a "sticky on mobile only" header is possible without custom CSS.
3. Meet Ipsum, the new default theme
7.2 ships a new default theme called Ipsum, and it breaks the old year-based naming tradition. It is a minimal blog theme whose style variations recolor the whole page, and the team says every combination meets WCAG AA.
Test it if: your plugin outputs front-end UI (forms, galleries, popups, WooCommerce blocks). Many users will see your plugin inside Ipsum first. You can try it from the Ipsum GitHub repo.
4. Block supports landed on almost every core block
Gutenberg 24.1 switched on existing design supports (backgrounds, gradients, shadows, borders, link colors, text columns, alignment) for core blocks that were missing them.
Two practical consequences:
- Custom CSS you wrote just to add a shadow or background to a core block can move into
theme.jsonunderstyles.blocks. - Accordion, Tabs, Tab Panel and Post Template now output
has-link-colorstyle classes. Check your link styles inside those blocks for specificity collisions.
{
"styles": {
"blocks": {
"core/code": {
"shadow": "var(--wp--preset--shadow--natural)"
}
}
}
}
5. Text shadow is now a real block support
Text shadow moved from Global Styles only to a full block support with presets. For your own blocks, opt in via block.json:
{
"supports": {
"typography": {
"textShadow": true
}
}
}
Themes can register presets in theme.json, and each preset generates a --wp--preset--text-shadow--{slug} custom property and a .has-{slug}-text-shadow class.
6. NO_BACKSLASH_ESCAPES SQL mode is off by default
wpdb now removes NO_BACKSLASH_ESCAPES from WordPress's own database session. Most sites won't notice. If one of yours depends on it, you can keep it, but only from a db.php drop-in, because plugins and mu-plugins load too late:
<?php
// wp-content/db.php
add_filter( 'incompatible_sql_modes', static function ( array $modes ): array {
return array_values( array_diff( $modes, array( 'NO_BACKSLASH_ESCAPES' ) ) );
} );
7. Five components are deprecated (removal in 7.4)
These @wordpress/components are deprecated as of 7.2 and scheduled for removal in 7.4:
-
Divider→ useSeparator -
ResponsiveWrapper→ use plain CSSaspect-ratio ScrollableZStackElevation
Also, MediaUpload's unstableFeaturedImageFlow is now featuredImageFlow. Search your codebase now:
grep -rnE "Divider|ResponsiveWrapper|Scrollable|ZStack|Elevation|unstableFeaturedImageFlow" src/
8. Core icons are now stroke-based
About 330 core icons were redrawn with strokes and set fill: none inline. A fill prop or CSS fill rule no longer recolors them. Use CSS color instead:
/* Before */
.my-plugin-toolbar svg { fill: #db2777; }
/* After */
.my-plugin-toolbar svg { color: #db2777; }
Update @wordpress/icons and @wordpress/components together, since mixing new icons with an older Icon component can drop styles.
9. Plugin releases now get an automated security review
If you ship to the WordPress.org directory, new releases now go through an automated security review during the release cooldown. High-risk releases are blocked and committers get an email with the findings.
Action: make sure the email on your committer account is one someone actually reads.
This fits a bigger trend. October 2026 has already seen several critical, actively exploited WordPress plugin vulnerabilities. Sites running outdated or nulled plugins (which never get security updates) are the easiest targets. If you manage client sites, licensed plugins with working updates are not optional anymore. We explain how activation and updates work in our WordPress Plugin & Theme License Keys guide.
✅ Copy-paste pre-flight checklist
- [ ] Spin up Playground or staging with 7.2 Beta 1
- [ ] Run your HTML sanitization tests against the new
wp_kses() - [ ] Load your plugin's front-end UI inside the Ipsum theme
- [ ] Check link styles inside Accordion, Tabs and Post Template blocks
- [ ] Grep for the 5 deprecated components and
unstableFeaturedImageFlow - [ ] Replace
fillrules on core icons withcolor - [ ] Confirm nothing depends on
NO_BACKSLASH_ESCAPES - [ ] Update
@wordpress/iconsand@wordpress/componentstogether - [ ] Verify your WordPress.org committer email
- [ ] Make sure every premium plugin on client sites can receive updates
🧰 Keeping client sites ready for 7.2
Core updates are only half the story. Page builders and addons need to keep pace too, so check that your Elementor stack is current before December. If you're building with Elementor, our step-by-step Elementor website guide for 2026 and our comparison of the best Elementor addons in 2026 cover what we use on client projects.
And if a site slows down after the upgrade, start with the stack from our previous DEV post, or hand it to the team behind our WordPress speed optimization service.
For genuine, updatable plugins and themes for client work, browse GeniusWP, including Premium WordPress Plugins and Elementor Plugins & Addons.
📚 Official sources
- What's new for developers? (October 2026), WordPress Developer Blog
- WordPress 7.2 release schedule
- Roadmap to 7.2
- Introducing Ipsum, the new default theme
Which 7.2 change worries you most: the new wp_kses() or the component deprecations? Have you already tested Beta 1 on a real project? Drop your findings in the comments 👇
Top comments (0)