WordPress powers a huge chunk of the internet, and its ecosystem stretches well beyond core — Gutenberg, Jetpack, developer tooling, boilerplates that new plugin authors use to scaffold their first project. Contributing across that ecosystem means touching a lot of different codebases with very different scopes: a block editor transform bug here, an invalid HTML output there, a one-letter capitalization fix that quietly matters to people using the wrong IDE name.
This batch covers five PRs across four different WordPress-adjacent repositories. Some are functional fixes with real user impact; others are documentation cleanup or tooling corrections. All of them make the ecosystem a little bit more correct.
WordPress Core — Gutenberg
PR #78368 — Button Block: Move Align Attribute to the Wrapper on Transform
The project: Gutenberg is the block editor powering WordPress. It handles how content is structured, rendered, and transformed between block types.
The issue: When transforming an older core/button block (which had direct align support) to the newer core/buttons wrapper block, the align attribute was left behind on the inner button block. The problem: core/button has align: false in its block supports definition, so an orphaned align attribute caused the button to incorrectly fill its row via flex-grow. Visually, a centered or right-aligned button would suddenly stretch to full width after the transform.
The fix: Extract align from the first button in the transform, apply it to the outer core/buttons wrapper, and strip it from all inner button blocks:
// Before — align left on the inner block where it doesn't belongtransform: ( buttons ) => createBlock( 'core/buttons', {}, buttons.map( attrs => createBlock( 'core/button', attrs ) ) );// After — align moved to wrapper, stripped from inner blockstransform: ( buttons ) => { const { align } = buttons[ 0 ]; return createBlock( 'core/buttons', align ? { align } : {}, buttons.map( ( { align: _align, ...buttonAttributes } ) => createBlock( 'core/button', buttonAttributes ) ) );}
A new test file (packages/block-library/src/buttons/test/transforms.js) was added with three test cases covering the alignment migration behavior.
What I learned: Block transforms need to think carefully about which attributes belong to the wrapper and which belong to the inner blocks — and when you’re promoting an inner block’s attribute up to a new wrapper, you have to be deliberate about stripping it from all inner blocks, not just moving a copy.
Jetpack
PR #48869 — Verification Tools: Remove Trailing Slash from Void Elements
The project: Jetpack is Automattic’s flagship WordPress plugin, adding security, performance, and marketing features to self-hosted WordPress sites. Site Verification Tools outputs <meta> tags for Google, Bing, Pinterest, and other services.
The issue: The verification meta tag was output as <meta name="..." content="..." /> — with a self-closing slash. In HTML5, void elements like <meta>, <br>, and <img> don’t use self-closing slashes. That trailing /> is an XHTML habit that HTML5 validators flag as invalid markup. Small thing, but it causes warnings for anyone running their site through an HTML validator.
The fix: Update the output format and tighten the regex used to parse stored verification codes (to accept both the old /> and new > formats for backward compatibility):
// Regex: accept both old /> and new > in stored codes-preg_match( '#^<meta ... />$#i', ...+preg_match( '#^<meta ... /?>$#i', ...// Output: no trailing slash-sprintf( '<meta name="%s" content="%s" />', ... )+sprintf( '<meta name="%s" content="%s">', ... )
What I learned: XHTML habits are remarkably persistent. Self-closing slashes on void elements are harmless in most browsers, but they’re technically incorrect in HTML5 and they accumulate into a noisy validation report. Worth fixing anywhere you see them in output you control.
PR #48870 — Copy Post: Fix Backslashes Being Stripped on Duplicate
The issue: When duplicating a post using Jetpack’s Copy Post feature, backslash sequences (\t, \n, \\, etc.) in the post content, title, and excerpt were silently stripped from the copy. A post title like Path: C:\Users\Austin would become Path: C:UsersAustin after duplication — no error, no warning, just gone.
The root cause: wp_update_post() internally calls wp_unslash() on its input, expecting the data to arrive slashed (the way form data from $_POST arrives). The Copy Post module was passing raw, unslashed data retrieved directly from get_post() — so wp_update_post() “unslashed” data that had never been slashed, stripping real backslashes in the process.
The fix: One line — wrap the data in wp_slash() before passing it to wp_update_post():
// Beforereturn wp_update_post( $data );// Afterreturn wp_update_post( wp_slash( $data ) );
A regression test was added using ReflectionMethod to invoke the protected update_content() method directly, verifying that backslashes survive the duplication round-trip.
What I learned: wp_update_post() is one of those WordPress functions where the docs mention that it expects slashed data, but it’s easy to miss — especially when you’re getting post data from get_post(), which returns it unslashed. If you’re passing data programmatically (not from a form), you probably need to call wp_slash() first.
WordPress Plugin Boilerplate
PR #617 — Fix Stale Docblock References to run()
The project: The WordPress Plugin Boilerplate is a widely-used starting point for building WordPress plugins. A lot of developers — especially those new to plugin development — use it as a reference for how to structure their code.
The issue: The inline docblock comments on enqueue_styles() and enqueue_scripts() in both the admin and public class files told developers: “An instance of this class should be passed to the run() function.” That’s incorrect. Hooks are registered via add_action() and add_filter(); run() is called separately to execute the already-registered hooks. Telling a new developer to pass an instance to run() is quietly misleading.
The fix: Updated four comments across two files to correctly reference add_action():
// Before (×4 across admin and public class files)- * An instance of this class should be passed to the run() function// After+ * An instance of this class should be passed to the add_action() function
Boilerplate code gets copied and referenced constantly. Inaccurate comments in a widely-used template propagate into real projects — worth fixing even when the change is just a few words.
Query Monitor
PR #1116 — Fix Capitalisation of NetBeans
The project: Query Monitor is a developer tools plugin for WordPress — think browser devtools, but for your WordPress backend. It shows database queries, hooks, HTTP requests, and more, and supports clickable stack traces that open directly in your IDE.
The issue: The IDE dropdown in Query Monitor’s settings listed “Netbeans” — but the correct capitalization is “NetBeans” (capital B). The same typo appeared in the documentation for clickable stack traces. Small, but it’s the kind of thing that’s just quietly wrong.
The fix: Updated the label field in output/utils.tsx and two occurrences in the documentation. The internal name slug (netbeans) was intentionally left unchanged to avoid breaking any persisted user preferences that reference it.
// output/utils.tsx-label: 'Netbeans'+label: 'NetBeans'
The slug-vs-label distinction here is a good pattern: keep the internal identifier stable for backward compatibility, update the human-readable display name to be correct. You get both correctness and safety.
Wrap Up
Five PRs across four repos, ranging from a functional block editor bug to a one-character label fix. That spread is kind of the point: open source maintenance isn’t just feature work. It’s the accumulation of small corrections — a void element that shouldn’t self-close, a backslash that shouldn’t disappear, a comment that points to the wrong function, a name that’s always been spelled wrong. None of these are glamorous. All of them make the ecosystem a little more correct for whoever reads or uses these projects next.
Leave a Reply