October 2026 Developer Roundup: wp_kses() Gets a Real Parser, Responsive Controls Go Public, and Collaboration Steps Off the 7.2 Train

October 16, 2026 — The monthly developer roundup landed two days ago, a little late and in a new, shorter format, with WordPress 7.2 Beta 1 due October 20, RC1 on November 17, and the final release on December 8 (release party schedule). September’s survey month is over; this is the last roundup before the testing window opens, and the timing should set every publisher platform team’s priorities. Three items stand out. The HTML sanitizer that touches every non-admin save in a multisite newsroom is being rebuilt from scratch. Real-time collaboration has been taken off the roadmap entirely while its architecture is rethought around the server. And the responsive controls that only Core blocks could use in 7.1 are now open to the custom blocks publishers actually ship.

Key Themes

WordPress 7.2 Beta 1 lands October 20, so anything that touches sanitized HTML, theme CSS, or deprecated components needs to be in a test environment within days, not weeks.
wp_kses() is being rebuilt on the HTML API, which normalizes stored markup and changes how script, SVG, MathML, and malformed fragments are handled.
Collaborative editing is intentionally left off the 7.2 roadmap while the project moves to a server-aware design that lets WordPress attribute, authorize, and merge every edit.
Gutenberg 24.1 made the viewport state helpers public, so third-party blocks can store per-breakpoint settings in the same style model Core blocks use.
The 7.2 security track hardens Application Passwords and adds a Secrets API, and plugin releases on WordPress.org now pass through an automated AI-assisted security review.

Jump to: 🧹 The New Sanitizer · 🤝 Collaboration Steps Off the Train · 📱 Responsive Controls Go Public · 🔐 Credentials and Release Gates · 🎨 The Pre-Beta CSS Audit · 🔧 Housekeeping · 💡 Takeaways

🧹 wp_kses() Gets a Real Parser

The wp_kses() progress report describes a full replacement of WordPress’s HTML sanitizer: PR #13271 (Trac #66208) swaps the legacy chain of string processing and regular expressions for an implementation built on the HTML API, targeting 7.2 or 7.3 depending on testing. The interface does not change, but the output does. Markup is re-serialized rather than patched — tags lowercased, attributes double-quoted, character references decoded and re-escaped. The contents of disallowed <script> and <style> elements are now removed with their tags instead of left behind as visible text. SVG or MathML that needs more complex parsing is cut off where it begins, documents containing <noscript> are rejected, and truncated tails like <butto are discarded. Some content the old parser swallowed now survives — a sentence like “under <$500 and >5 years old” no longer loses its middle. Unescaped ampersands in pasted URLs can resolve differently: &section= written without escaping becomes §ion=, exactly as a browser would read it. The wp_kses_force_legacy_parser filter restores the old behavior, but the report warns it may disappear as early as 7.2.0, and a parser tester shows how specific HTML is affected.

Why this matters: Newsrooms are among the heaviest users of wp_kses(). On multisite, only super admins hold unfiltered_html by default, so every editor, author, and contributor save runs through wp_kses_post before it is stored. The changes land on exactly the content publishers paste in most: inline SVG charts, embed snippets, tracking pixels wrapped in <noscript>, and URLs with hand-typed query strings. The less obvious risk is normalization. Any pipeline that hashes, diffs, or compares stored HTML — syndication change detection, migration validators, content-integrity tests — will see changes on content that did not change in substance. Run a representative archive sample through the tester before Beta 1. If something breaks, report it on the Trac ticket instead of reaching for the legacy filter.

🤝 Collaboration Steps Off the 7.2 Train

The Roadmap to 7.2 says it plainly: collaborative editing is “intentionally not on the roadmap,” because, as in 7.1, more time is needed for architectural decisions. The reasoning is in moving to a server-aware approach for collaboration. Today’s experiment merges edits only in the browser, which leaves three gaps. The server cannot attribute edits, so an author without raw-HTML rights could add a <script> block that gets saved under the capabilities of an admin who only fixed a typo. The server cannot participate, so a script that reads a post at 09:00 and writes it back at 09:03 erases whatever two editors did in between. And the server cannot mediate when a peer reconnects from a dropped connection and saves over newer work. The proposed fix routes every update through WordPress, which records who made it, checks permissions, merges it, and stores the result. Three candidate sync engines are under exploration in the gutenberg-sync-engines plugin: a PHP Yjs server, a three-way merge on save or autosave, and an operational-transform intent log.

Why this matters: Each of the three failure cases already happens in a newsroom. Contributors without unfiltered_html work alongside editors who do the final pass. Wire ingest, syndication, and AI enrichment jobs write to posts through the REST API while people are editing them. Breaking-news desks work on hotel and conference Wi-Fi. A browser-only sync engine was never going to be acceptable for a publisher’s security or legal review, so the delay is the right call, even though it closes the 7.1 door covered in June’s roundup. The cost is server load: the post admits that frequent polling is unrealistic on lower-resourced hosts and points to alternative transports for hosts willing to invest, which is a conversation enterprise platforms should join early. In the meantime, Notes is the collaboration that ships. Margin notes arrived in Gutenberg 24.2, and the 7.2 roadmap adds suggestions and emoji reactions. Plan 2027 editorial workflows on Notes, not on co-editing.

📱 Responsive Controls Go Public

Responsive style states shipped in 7.1, but only Core blocks could build controls for them because the helpers were private. Gutenberg 24.1 made them public (#82741): @wordpress/block-editor now exports getStyleForState() and setStyleForState(), and the block editor store adds getSelectedBlockStyleState() and hasSelectedBlockStyleState(). A custom block can now write a mobile-only minimum height into attributes.style under a { viewport: '@mobile' } state, the same way Core does it. The same release lets position vary by viewport (#83094), so a header can be sticky on mobile only. Gallery columns and crop now follow viewport states (#82003), and aspect ratio does too (#82233).

Why this matters: Publisher block libraries — story cards, promo rails, newsletter modules, live-coverage headers — have faked breakpoints for years with custom attributes, bespoke inspector panels, and CSS that only the original developer understands. Every one of those is now technical debt with a native alternative. Moving breakpoint settings into the shared style model means editors get one consistent control surface, design-system owners get one place to govern, and the curation toggles covered in September’s roundup can lock the controls down. It also makes “responsive styling for third-party blocks” a stated 7.2 goal rather than a workaround. Start with the house blocks that carry the most layout-specific CSS.

🔐 Credentials and Release Gates

Application Passwords hardening is on the 7.2 roadmap: UX improvements (#66009), an email notice when one is added (#63927), better non-HTTPS environment detection, guards against dangerous default_role values, and SameSite cookie support.
The Secrets API remains tentative and would be CLI-only in 7.2. A “sudo mode” proposal to put privileged actions behind re-authentication is still to come.
The Plugins team added an automated security review: during the release cooldown, several AI models and Jetpack Scan score each release, and high-risk releases are blocked automatically, with findings emailed to committers.

Why this matters: Application Passwords are what connects a publisher’s integrations: headless front ends, syndication partners, AI tooling, and scheduled publishing scripts. The new email notice will go to whatever inbox sits behind each service account, so decide now whether anyone reads it. Publishers who ship plugins to the directory should make sure the committer email is monitored, because a blocked release now waits on a reply.

🎨 The Pre-Beta CSS Audit

Around 140 PRs in Gutenberg 24.1 turned on block supports across Core blocks, as covered in the 24.1 recap. The roundup adds a warning: Accordion, Tabs, Tab Panel, and Post Template now output has-link-color and related classes, so check for specificity collisions.
About 330 Core icons are now stroke-based and set fill: none inline, so svg { fill: … } rules no longer recolor them. Use CSS color, and update @wordpress/icons and @wordpress/components together.
Gallery CSS is now scoped to :where(.is-layout-flex) to support the new Grid variation. Test theme overrides against a Grid gallery.
Divider, ResponsiveWrapper, Scrollable, ZStack, and Elevation are deprecated as of 7.2, with removal planned for 7.4. unstableFeaturedImageFlow is now featuredImageFlow.

Why this matters: None of these changes is dramatic on its own, but together they hit the parts of a publisher theme nobody has opened in years: archive templates, the gallery styles on every photo story, and admin customizations. One pass against Beta 1 will catch them before readers do.

🔧 Platform Housekeeping

Patch first. September brought three security releases: 7.1.1 with 11 fixes, 7.1.2 with a single critical fix, and 7.1.3 with seven more. Confirm that any site with auto-updates disabled is current.

React 19, two answers. Gutenberg 24.2 turned React 19 on by default in the plugin (recap), but the 7.2 roadmap still calls the upgrade “unlikely to fully land.” Keep auditing, but don’t expect it in Core this year.

The post sidebar moves to DataForm. A call for testing is open, and the roundup warns that PluginPostExcerpt may not survive the move. That matters for any newsroom that customizes the excerpt or dek panel.

NO_BACKSLASH_ESCAPES is off by default. The first 7.2 dev note strips the mode from WordPress’s own database session. The incompatible_sql_modes override only works from a db.php drop-in.

Performance and blocks. The roadmap proposes replacing script and style concatenation with prefetching and moves the Table of Contents block to server-side rendering. Footnote IDs now carry an fn- prefix (#82398), so check any code that deep-links to footnote anchors.

Ipsum and private icons. The new default theme, Ipsum, ends year-based naming. Icon collections registered with 'public' => false stay out of the REST API and the Icon block, which is useful for admin-only brand iconography.

Playground gets a terminal and an inbox. The Dev Tools Dock runs PHP and WP-CLI commands against the live site, and the Email tool captures wp_mail() output — sendmail path only, not SMTP or API providers.

💡 Takeaways

Test your archive against the new wp_kses(). Put a sample of real posts — SVG charts, embeds, noscript pixels, pasted URLs — through the parser tester before Beta 1, and report breaks on Trac #66208 instead of relying on the legacy filter.
Audit integrations that write to posts. Wire, syndication, and AI enrichment jobs are the “scheduled integration” case in the collaboration post. Know which ones write while editors are working.
Migrate house blocks to the public responsive helpers. Replace custom breakpoint attributes with getStyleForState() and setStyleForState(), starting with the blocks that carry the most layout CSS.
Update service-account email routing for Application Passwords. The 7.2 notification will go somewhere, so make sure a person reads it.
Test theme CSS against Beta 1. Check icon fill rules, has-link-color specificity, Grid galleries, and deprecated components in one pass while feedback can still shape the release.

The full roundup is available on the WordPress Developer Blog.