This security release features fixes for multiple issues.

Because this is a security release, it is recommended that you update your sites immediately.

You can download WordPress 7.1.4 from WordPress.org, or visit your WordPress Dashboard, click “Updates”, and then click “Update Now”. If you have sites that support automatic background updates, the update process will begin automatically.
WordPress 7.1.4 is a short-cycle release. The next major release will be version 7.2, currently planned for December 8th.

For more information, please visit the WordPress 7.1.4 HelpHub site.

Security updates included in this release

The security team would like to thank the following people and organizations for responsibly reporting vulnerabilities, and allowing them to be fixed in this release:

• A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window, reported by Umut Bayram.
• A stored XSS with specially crafted block markup, reported by Rafie Muhammad (Awesome Motive, Inc.).
• Privacy Data Removal Requests can be created in a way that leads to stored XSS, reported by Anthropic.
• Multiple stored XSS issues in the Interactivity API independently discovered by AnC and DatNLQ from VietSunshine Cyber Security, rekter0 and Anas cherni, Marcel Karlsson (whoismarcel), and Weston Ruter, Jon Surrell, Alex Concha, and Luis Herranz of the WordPress Security Team.
• A stored denial of service issue in the Interactivity API, reported by Jon Surrell of the WordPress Security Team.
• A stored XSS in Customizer selective refresh, reported by Rafie Muhammad (Awesome Motive, Inc.).
• A Stored XSS in the Categories block reported by Ben Bidner of the WordPress Security Team.
• Specially crafted User Logins can lead to a stored XSS reported by Anthropic.
• Unpublished customizer changesets can be discovered by unauthenticated users, reported by Antonio Lorensius Silaban.
• A Stored XSS in Playlist and image blocks, reported by Ben Bidner of the WordPress Security Team.
• Stored XSS in core/comments-pagination-next and core/comments-pagination-previous blocks, reported by Alex Concha of the WordPress Security Team.
• Notes can be read by privileged users that lack access to edit the post the note is attached to, reported by Ramon of the WordPress Security Team.
• An update to the bundled root certificates due to the eMudhra revocation.

Thank you to these WordPress contributors

This release was led by Aaron Jorbin and Nik Tsekouras. WordPress 7.1.4 would not have been possible without the contributions of the following people:

Aaron Jorbin, Adam Silverstein, Alex Concha, Andrew Duthie, Andrew Serong, David Arenas, Dennis Snell, Ella Van Durpe, George Mamadashvili, Isabel Brison, Jake Spurlock, Jb Audras, Jeremy Felt, John Blackbourn, Jon Surrell, Jonathan Desrosiers, Kira Song,Lance Willett, luisherranz, Marco Ciampini, marcs0h, Marin Atanasov, Mario Santos, Miguel Fonseca, Nik Tsekouras, Peter Wilson, ramonopoly, Rudy Faile, umut3806, Weston Ruter

Backports

As a courtesy, the security fixes were backported to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported. The backports are in progress and will ship as they become ready.

WordPress 7.2 Beta 3 has also been released, containing all applicable fixes.

On the podcast today we have Remkus De Vries.

Remkus has been active in the WordPress space for over twenty years, starting out with his own agency focused on high-performance, scalable WordPress websites. Over time, he has diversified into education and community-building with projects like WithinWP and a new initiative, The Guild, which is a paid community aimed at helping people build smarter, more performant sites through a first principles approach.

Our conversation centers on Scanfully, a site health and monitoring SaaS Remkus co-founded, which recently hit version 2.0. Scanfully’s focus is giving users meaningful, actionable insights into WordPress site health, security, performance, email deliverability, DNS, and more, packing all this data into an easy to understand dashboard.

We talk about Remkus’ motivation for diving deep into the complexities of WordPress monitoring, and why many users struggle to keep on top of the technical side of their websites. Remkus argues that too many site owners are stuck in reactive mode, only investigating issues once something breaks, and Scanfully aims to change that mindset by making ongoing health checks accessible and easy to parse, even for the spreadsheet-averse.

Remkus walks us through the product’s evolution, including the 2.0 update that aimed to reimagine their dashboard experience, added public APIs, and introduced tools like MCP AI integration, empowering users to query their site’s health conversationally.

We also get into recent and upcoming features such as WooCommerce checkout monitoring, activity logs, and future add-ons designed to cover forms and other business-critical flows.

If you manage multiple WordPress sites, run an agency, or are simply interested in building more robust, future-proof WordPress projects, this episode is for you.

Useful links

Scanfully

Scanfully 2.0 release post

Within WordPress

The Guild

Remkus’ personal website

Remkus on X

bbPress 2.6.21 is a security and maintenance release. Everyone running bbPress should update.

This release strengthens access control across forum feeds, search results, BuddyPress activity, group forums, attachment requests, topic moves, and old topic and reply redirects. Inherited forum passwords now apply consistently when WordPress renders topic and reply content, and Akismet moderation requests now require HTTPS.

Maintenance fixes improve forum freshness and child-count queries, preserve metadata when database lookups fail, tighten route and user-profile handling, retain original dates and revision content during moderation and editing, and correct the administration reply destination controls. This release also repairs straightforward orphaned list items on WordPress 6.9 and newer, keeps generated bbPress excerpts available without duplicating content, adds the ugc relationship to topic and reply links, and refreshes administration icons for WordPress 7.2 and newer.

bbPress 2.6.21 still requires WordPress 6.0 or newer and PHP 7.2 or newer, and is tested through WordPress 7.1. The database version remains 264, so no database upgrade is required. The 2.6.21 upgrade notes cover compatibility details.

These changes are also in the 2.7 development branch, which remains 2.7.0-alpha-4. Thank you to antaloaalonso, arielmeadow, bor0, Clorith, dd32, deborah86, diddledani, lmstearn, netweb, noruzzaman, Otto42, Pebbleontheshore, r-a-y, rollybueno, sbask, shadow043, SirLouen, softglaze, terresquall, tharsheblows, and ton-ha for reports, patches, testing, and review.

Download bbPress 2.6.21 from WordPress.org, or update from your WordPress dashboard.

WordPress 7.2 Beta 2 is ready for download and testing! 

This beta release is intended for testing and development only. Please do not install, run, or test this version of WordPress on production or mission-critical websites. Instead, use a test environment or local site to explore the new features.

How to Test WordPress 7.2 Beta 2

You can test WordPress 7.2 Beta 2 in any of the following ways:

The scheduled final release date for WordPress 7.2 is December 8, 2026. The full release schedule can be found here. Your help testing Beta and RC versions is vital to making this release as stable and powerful as possible. Thank you to everyone who contributes by testing!

What’s in WordPress 7.2 Beta 2?

For technical details on the issues addressed since Beta 1, see the following links:

• Closed 7.2 WordPress Core Trac tickets since October 20, 2026
• 7.2 Gutenberg commits since October 20, 2026

Continued Improvements to WordPress 7.2

WordPress 7.2 Beta 2 builds on the first beta with additional enhancements, bug fixes, and refinements across the administration experience and developer APIs.

Development continues on the Abilities API, including content querying, capability requirements, and improvements to schema handling and permissions. New server-side registration capabilities for DataViews and DataForm also provide developers with more ways to extend WordPress interfaces.

Additional work includes improvements to REST API flexibility, admin asset loading, and the transition to modern SVG icons throughout WordPress administration.

Learn more: Trac #66268, Trac #66325, Trac #66229, Trac #66343, Trac #57548, Trac #65089

How important is your testing?

Testing for issues is a critical part of developing any software, and it’s a meaningful way for anyone to contribute – whether or not you have experience. Details on what to test in WordPress 7.2 are available here.

If you encounter an issue, please share it in the Alpha/Beta area of the support forums. If you are comfortable submitting a reproducible bug report, you can do so via WordPress Trac. You can also check your issue against this list of known bugs.

Curious about testing releases in general and how to get started? Follow along with the testing initiatives in Make Core and join the #core-test channel on Making WordPress Slack.

A Beta 2 haiku

Second beta takes shape
New abilities take root
WordPress grows stronger

Props to @mamaduka for pre-publish review.

On October 25, Akismet turns 21. We’re celebrating with a few new guests: an official Drupal module, a PHP SDK, and another year of improvements to our WordPress plugin. Spam still isn’t on the list.

Akismet launched in October 2005 to help people spend less time dealing with comment spam and more time enjoying their blogs. The web has changed a lot since then. People build communities, collect inquiries, accept donations, and create applications on all kinds of platforms. Each of those places gives people a way to contribute. It also gives spammers somewhere to try their luck.

Since then, Akismet has blocked over 570 billion pieces of spam. Every one is something a site owner didn’t have to spend time sorting through. Our birthday wish is to keep making more room for the real people.

Welcome, Drupal

This year, we released the official Akismet Drupal module, built by the team behind Akismet. It brings our spam protection to Drupal comments, contact forms, webforms, and user registrations, with tools for moderators to review submissions and send corrections back to Akismet.

We’ve continued building on that welcome. The latest release supports Drupal 12 and passes richer bot-detection signals into spam scoring. On Drupal 12, comments and registrations are supported now; contact forms, webforms, and the Key module will follow as those modules become ready for Drupal 12.

For people using the older community module, we also built an upgrade path to the official module that carries their API key and protection settings across. The migration guide explains the requirements and which settings need attention.

Welcome, PHP developers

Akismet’s API has long made it possible to protect sites beyond WordPress. This year’s official PHP SDK gives developers a first-party client for bringing that protection into their own PHP applications, including projects built with Laravel or Symfony.

The SDK handles the Akismet API integration so developers can focus on their application. It supports checking submissions, reporting spam and legitimate content, and retrieving usage and account information. The official Drupal module uses it too.

If you’re building a place where people can post, sign up, or send a message, there’s a new tool to help you keep the spam out.

A familiar guest, with a few improvements

WordPress has been with us from the beginning. This year, we kept improving that experience: clearer setup and error messages, accessibility improvements, better detection of automated submissions, and compatibility fixes. You can find the details in the WordPress plugin release log.

Version 5.7 also added support for Abilities and Connectors, helping Akismet fit into WordPress’s evolving tools for integrating external services.

More room for real people

A comment worth replying to. A message from a future customer. A donation to a cause someone cares about. Those are the things we want coming through.

Thank you to everyone who uses Akismet, builds an integration, reports a problem, or helps us improve. You’ve been part of these 21 years, and you’re very much invited to the celebration.

Whether your site runs on WordPress, Drupal, or something you’re building yourself with the PHP SDK, there’s room at the table.

Just no room for spam.

Try out the Drupal module today!

Howdy,

Before anything else: check which version of PHP your sites run. On October 21, the PHP project released fixes for two critical vulnerabilities, and they affect any server running a PHP application, not only WordPress. You’ll find your version under Tools → Site Health → Info → Server in your WordPress admin. If you manage your own server and are still on a version older than 8.2, I highly recommend updating. While many hosts have patched older PHP versions that are end of life, it’s best to stay on versions that PHP officially supports.

On a happier note, I’m back. I was sick for a stretch earlier this month, which is why there was no edition on October 10. Rather than try to cram four weeks into one post, this edition sticks to the last two. Much of what happened in the gap is covered in my October roundup for developers, linked below.

With that, let’s get down to the latest news.

Your friendly neighborhood developer advocate,
Justin Tadlock

Developing Gutenberg and WordPress

The final major release of the year has entered testing. David Baumwald announced that WordPress 7.2 Beta 1 is ready for download and testing, with the final release set for December 8. Notes move into a margin beside the canvas and pick up emoji reactions. Text shadows and form element styling arrive in the design tools, a new Secrets API gives plugins a standard place to store API keys, and client-side media processing extends to the Media Library. There’s even an On This Day dashboard widget. Not everything made it, though: The Repository reports that Notes suggestion mode was punted to 7.3.

The quickest way to try it is the 7.2 Beta 1 Playground instance, or wp core update --version=7.2-beta1 on a test site. Not on production.

Not sure where to start? Noruzzaman’s Help Test WordPress 7.2 breaks the release down by area: security, collaboration, admin, blocks and APIs, design, media. It also walks through the different ways to run a beta, from Playground to a staging site on your host, and points you to where feedback goes. The Beta 1 post is clear that testing counts as contributing, whether or not you’ve done it before.

Your first contribution to WordPress shouldn’t start with installing Git, Node.js, npm, and Docker. That’s the friction the WordPress Contributor Toolkit removes, and Ryan Welcher announced Contributor Toolkit 2.0, a redesigned app in your language. It’s rebuilt on the WordPress Design System, ships in ten languages, and adds a settings dialog. After you apply a patch, you can revert a single file without losing the patch itself. It’s also about 350 MB smaller, which helps when a whole Contributor Day room downloads it at once.

Jorge Costa shared what’s new in Gutenberg 24.2, and the Notes feature is the big headline. Notes now float in a margin the editor reserves next to the canvas, so you no longer have to choose between reading feedback and keeping the Settings sidebar open.

The Navigation block’s link search now looks through pages, posts, categories, and tags at once. Gallery can sort hand-picked images and tint all of them with a single duotone. And the design tools push continues with about 80 more PRs. Minimum width and height controls, for example, went from five blocks to 40.

For developers, React 19 is now on by default. Test your plugins and themes, and if something breaks, you can switch it off under Gutenberg → Experiments. Gutenberg 24.3 RC1 is already out, too, with rich text formatting across blocks, so expect that next week.

On the Developer Blog, I put together What’s new for developers? (October 2026), and I tried something different this month. Instead of walking through every aspect of the project, it focuses on the changes I think matter most if you build on WordPress: custom blocks building their own responsive controls, wp_kses() being rebuilt on the HTML API, stroke-based Core icons, and the automated security review for plugin releases. Everything else is linked at the end.

Readers may remember Chris Zarate’s post on moving collaboration to the server from the last edition. Alec Geatches follows it up with a guide to the sync engines for real-time collaboration, comparing yjs-server, DE-RTC, and intent-log on their strengths and weaknesses. In every engine, each change goes through WordPress, which confirms who sent it, checks their permissions, and validates it before merging. You can try all three in the experimental Gutenberg Sync Engines plugin. It needs WordPress 7.0+ and the Presence API plugin, and it bundles its own copy of Gutenberg, so deactivate the Gutenberg plugin first.

Feature Notifications has been quiet since version 0.2.0 shipped in April 2023. Jonathan Bossenger is reviving it with a status update and plan for 0.3.0, aiming to ship it with WordPress. That would be the project’s first working MVP: a notifications system that creates, stores, displays, and dismisses notifications. His honest assessment is that the foundations are solid but nothing is wired up end to end yet. He’s posting weekly updates if you want to follow along or help.

Benjamin Zekavica published the recap of the WordPress 7.1 “Mary Lou” retrospective, summarizing what contributors would keep, add, and change for future release squads. If you answered the survey, this is where your feedback landed.

Plugins, Themes, and Tools for #nocode site builders and owners

Sticky headers are one of those things you end up fixing on nearly every block theme site. Jamie Marsland turned his fix into a free plugin, Jamie’s Header Effects.

The standout is Chameleon mode: as visitors scroll, the header picks up the background color of the section beneath it and flips its text between light and dark to stay readable. There are also frosted-glass, solid, hide-on-scroll, and transparent overlay styles. It finds your header template part on its own, respects prefers-reduced-motion, and lives under Appearance → Header Effects.

Meta Box’s custom models no longer have to sit in isolation. A few weeks after moving model creation into the builder, Lua Nguyen announced the new Custom Model field, which lets you pick one or more items from a custom model the same way the Post field picks posts. MB Relationships also gains a Model object type, so you can connect models to posts, terms, users, or other models in either direction. Think hotel rooms as a post type with bookings attached from a custom model—no IDs stored by hand.

On WordPress.com, Ronnie Burt covers what’s new with WordPress Agent: it now designs a custom theme from your answers, hands you off to a simplified AI Editor with Preview and Edit tabs, and can install and manage plugins when you ask. The latest WordPress.com changelog also opens premium themes to every paid plan, starting with Personal.

WooCommerce 11.2.1 fixes two regressions: classic checkout on stores that remove address fields with filters, and postcode validation in the Checkout block for Argentina and a few other countries.

Theme Development for Full Site Editing and Blocks

If you’ve ever had to explain to a client why they should move to a block theme, Simon Cooke has done the work for you. His Human Made guide on how a WordPress block theme is built, and why it matters for enterprise sites walks through each part of a block theme and who owns it, with a side-by-side comparison to classic themes. He’s clear that moving is a project, not a theme swap. The point he lands on: when design rules live in the theme, a page built by someone who joined last week follows the same rules as one the designer built.

What if you could point a tool at any static HTML and CSS site and get an editable block theme back, headers and footers included? That’s the Static Site Importer, and Chris Huber of Automattic talks it through with Nathan Wrigley on WP Tavern in episode #238 on making migration to WordPress easier than ever. You’ll hear how it crawls a site, maps HTML elements to blocks, and handles trickier features like WooCommerce, plus how it fits into the broader Data Liberation effort.

WooCommerce’s Purple theme has a new home. Luigi Teschio announced that Purple development moves to the WooCommerce monorepo, as the first theme in its new themes/ directory, so contributions and bug reports go there now. One of the stated reasons is that keeping themes next to the blocks they use makes it easier for contributors, and AI coding tools, to see how templates and patterns use WooCommerce blocks. Nothing changes for existing installs, and Purple still releases on its own schedule. For more background, Bob Dunn’s Do the Woo episode on WooCommerce themes in 2026 covers Purple and theme performance.

Building Blocks and Tools for the Block editor.

The new @wordpress/ui package will gradually replace @wordpress/components, so how much of an existing plugin can you move over today? Ryan Welcher found out live by migrating Advanced Query Loop to @wordpress/ui with the Design System MCP.

Once your page registers WebMCP tools, those tool definitions are an API, and the consumer is a language model. Pascal Birchler built playwright-webmcp for testing WebMCP tool surfaces, with linting, Playwright matchers, agent evals, and a site audit CLI. He lists the failure modes that make this tricky: vague descriptions the model ignores, schemas the browser quietly rejects, and two tools on the same page with nearly identical names.

Extension developers no longer need to duplicate a WooCommerce ability just to expose a few extra fields. Luis Felipe Zaguini opened a call for testing extensible abilities for extension fields, an experimental API in WooCommerce 11.3. Extensions can add fields to product, order, and order item reads and writes, register query filters, and refuse a change with a validator before it saves. It’s off by default, so turn on Extensible abilities under WooCommerce → Settings → Advanced → Features to try it. The gift wrap example in the post is a good place to start.

What’s new in Playground?

The best way to find out what’s hard about site editing is to watch someone try it. Jamie Marsland built a user testing app for WordPress on Playground and Spacefast to do exactly that. You send a tester a link, and Playground spins up a fresh site in their browser from your existing demo blueprint, with a card of five to seven tasks in the corner. The results page shows how long each task took, who needed the hint, and whether the site actually changed. It’s also an MCP server, and it’ll flag a task that gives away the button name.

AI in WordPress

Two weeks after the MCP Adapter arrived on WordPress.org as a canonical plugin, the AI team got approval to make MCP a default part of WordPress. Rae Morey reports on the move to make MCP a default part of WordPress, with 7.3 floated as a target. That doesn’t necessarily mean merging the adapter into Core: bundling it, enabling it through existing interfaces, and building specific capabilities into Core are all on the table. It’s also a reversal of the reasoning behind the canonical plugin, and maintainers are asking what changed. The AI contributor summary for October 21 has the meeting’s side of the discussion.

Andy Peatling launched WordPress Agent Benchmarks to measure how AI agents handle WordPress, and Rae Morey walks through the first results. Across 193 sites built for requests that suited WordPress, agents chose it zero times, even though they named it as an option about half the time. Using the MCP Adapter alone, they completed no tasks on existing sites, largely because it doesn’t yet bundle the abilities for common operations. Brian Coords asks what WordPress would have to change in helping agents choose WordPress, drawing on a WP Minute panel with Andy.

Is the MCP Adapter safe? Brad Williams of WebDevStudios calls it a door: “You decide which rooms it opens into.” He explains why production use of the MCP Adapter is a governance decision, not a plugin decision. An agent gets whatever abilities are exposed, using the permissions of the user it connects as, and every plugin you install can add more. His advice is to write the agent’s job description before you hand over the keys.

If you connect an AI client to WooCommerce, this one needs action before you upgrade. Darren Ethier explains that WooCommerce 11.3 removes its deprecated MCP endpoint. Requests to /wp-json/woocommerce/mcp will return a 410. Install the MCP Adapter, create an application password for a user with only the capabilities the client needs, and point the client at the adapter’s default server. Extensions that hooked into the old endpoint’s filters should check the post’s full list of what’s been removed.

WPShout’s guide on how to connect Claude to WordPress opens with the question most guides skip: where your site is hosted decides which route you take. WordPress.com, Jetpack, and other self-hosted sites each get their own path, and the walkthrough uses a free MCP plugin with a least-privilege grant. It’s also candid about a gap: the WordPress MCP Adapter has no OAuth server of its own, so claude.ai’s sign-in can’t connect to it directly yet.

Post revisions spent years bloating databases. Human Made thinks they’re about to become valuable. In WordPress revisions: agentic gold?, Noel argues that every revision records what changed, who changed it, and when, which makes them a log of how your team really works. Mine them for repeated changes and you’ve found the workflows an agent could take over. The post includes a prompt you can run, on a copy of your database and never on production.

	Need a plugin .zip from Gutenberg’s master branch? Gutenberg Times provides daily build for testing and review. Now also available via WordPress Playground. There is no need for a test site locally or on a server. Have you been using it? Email me with your experience.

Questions? Suggestions? Ideas?
Don’t hesitate to send them via email or
send me a message on WordPress Slack or Twitter @bph.

For questions to be answered on the Gutenberg Changelog,
send them to changelog@gutenbergtimes.com

The PHP project has announced a security release that fixes two critical security vulnerabilities discovered in PHP.

Due to the critical severity of the issues, site owners are encouraged to immediately update their installations of PHP. Your web host may already be working to update PHP and put web application firewall (WAF) rules in place to mitigate the vulnerabilities, but you should still check for updates from your web host and, if necessary, update PHP as soon as possible.

Within WordPress, you can see which version of PHP your site runs under Tools > Site Health > Info > Server. Many web hosts provide this information in your web hosting administration panel too.

These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues.

Versions of PHP prior to 8.2 no longer receive security updates from the PHP project.

If your site runs a version prior to this and you manage your own web hosting, you should consider taking your server offline while you prepare to update to a newer version of PHP. This advice is being published by several national cyber security agencies. To quote the UK National Cyber Security Centre:

Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated.

Further information on wordpress.org:

• Get a faster, more secure website: update PHP today
• PHP Compatibility and WordPress Versions
• FAQ My site was hacked

On the podcast today we have Chris Huber.

Chris’s journey with WordPress began back in his college days, first as a writer and blogger and eventually progressing to software engineering. After moving his personal site, extrachill.com, to WordPress in 2018, Chris went deeply into WordPress, developing custom plugins and exploring all the corners of the platform. His passion for experimentation and creative tech led him to Automattic, where he now helps shape the WordPress experience as a software engineer.

Our discussion centers around two main topics: Data Liberation and the Static Site Importer tool. We focused upon the evolving landscape of website migration and ownership. Chris explains how Data Liberation aims to make it easier for users to take control of their site, whether they’re moving to WordPress from platforms like Wix, Squarespace, or Drupal, or just want portability for their data.

We also get into the Static Site Importer, which takes this a step further by converting any static HTML / CSS website into a fully editable WordPress block theme, headers, footers, and all.

Chris walks us through how these tools work in tandem, highlighting the mechanics behind website crawling, mapping HTML elements to Gutenberg blocks, and handling complex features like WooCommerce and calendars.

We talk about the continuous improvement of these tools, how each migration helps raise the bar for future imports, and how this project could fundamentally change the way people move websites between platforms.

If you’re curious about the future of website migration and how WordPress is removing the hurdles for users who want to truly own and manage their content, this episode is for you.

Useful links

Chris’ extrachill.com website

Chris’ chubes.net website

Static Site Importer on GitHub

WordPress Studio

Data Liberation Project

liberate.sh website

Chris on X

There’s going to be an emergency PHP release made in just over 2 hours. It’s to address a critical security bug.

I’m not sure how long it’ll be before Ubuntu updates, but I will preload a bunch of posts here and on inphotos.org using WP Super Cache and turn off PHP until it’s updated. The files will be served by Apache’s mod_rewrite, so no PHP involved at all. Uncached pages won’t be so lucky, but at least some pages will still be live.

This beta release is intended for testing and development only. Please do not install, run, or test this version of WordPress on production or mission-critical websites. Instead, use a test environment or local site to explore the new features.

How to Test WordPress 7.2 Beta 1

You can test WordPress 7.2 Beta 1 in any of the following ways:

The scheduled final release date for WordPress 7.2 is December 8, 2026. The full release schedule can be found here. Your help testing Beta and RC versions is vital to making this release as stable and powerful as possible. Thank you to everyone who contributes by testing!

Editing Experience

Responsive Design Controls

Building on the responsive design improvements introduced in WordPress 7.1, WordPress 7.2 expands viewport-specific styling to additional design tools and blocks. Creators gain more granular control over how layouts and visual settings adapt across screen sizes, including responsive Gallery settings for columns, image cropping, and aspect ratios.

Learn more: GitHub #80388, #82003

Improved Global Styles and Design Tools

WordPress 7.2 makes site-wide styling easier to manage with a new Customized filter for finding blocks with modified styles and inherited Global Styles values displayed directly in block inspector controls. Expanded design tools and support for styling form elements provide additional flexibility when creating a consistent visual identity across a site.

Learn more: GitHub #82520, #76525, #34198, #84657

Text Shadow Support

WordPress 7.2 introduces new text shadow controls, giving creators more ways to add depth and emphasis to their content. Text shadows can be customized through block settings and defined as presets in theme.json, making it easier to maintain consistent typography across a site.

Learn more: GitHub #73320, GitHub #79584, Trac #65869

Easier Navigation Management

Improvements to the Site Editor make managing navigation links more intuitive. Creators can add, organize, and edit navigation items directly from the editor sidebar, making it easier to maintain site menus without interrupting their editing workflow.

Learn more: GitHub #77069

Better Collaboration with Notes

WordPress 7.2 introduces Emoji reactions on notes and a new toolbar icon that makes Notes easier to access and manage. Notes move to the editor canvas, bringing conversations directly into the margin. Users can now keep Notes and the block settings sidebar open simultaneously, making it easier to review feedback while editing content.

A new minimized Notes mode reduces visual clutter, while improvements to positioning and display create a smoother, more consistent collaboration experience.

Learn more: GitHub #79970, GitHub #83786, GitHub #80015, Trac #64638

Faster, More Efficient Media Uploads

WordPress 7.2 expands client-side media processing to the Media Library, allowing images to be resized, compressed, and converted directly in the browser before being uploaded. This can improve upload performance, reduce server resource usage, and provide better support for modern image formats, particularly on hosting environments with limited image-processing capabilities.

Learn more: Trac #65661, GitHub #12585

New “On This Day” Dashboard Widget

WordPress 7.2 introduces a new On This Day dashboard widget that helps users rediscover content published on the same date in previous years. By highlighting posts from the site’s history, the widget makes it easier to revisit past content, celebrate milestones, and find opportunities to refresh or reshare older posts.

Learn more: Trac #65116

Block Editor Usability Improvements

WordPress 7.2 includes a collection of smaller improvements aimed at reducing friction in everyday editing. These changes include clearer error messages, more helpful feedback when something goes wrong, and refinements to common editor interactions, making the editing experience more predictable and approachable.

Learn more: GitHub #81453, #82496, #84656, #84649

A More Consistent WordPress Admin

WordPress 7.2 continues modernizing the administration experience by replacing legacy Dashicons in the admin bar and sidebar with icons from the WordPress icon library. The updated icons bring greater visual consistency between the traditional WordPress dashboard and newer editing interfaces.

Learn more: GitHub #12270

An Updated Block Settings Experience

A new DataForm-powered inspector introduces a refreshed approach to managing block settings in the editor. Built on the DataForm component system, this work aims to provide more consistent controls and a more extensible foundation for future block editing improvements.

Learn more: GitHub Gutenberg · Call for Testing

Faster WordPress Administration

WordPress 7.2 improves admin performance by modernizing how scripts and stylesheets are loaded. Instead of combining assets into large files, WordPress now loads them individually for better browser caching. A new prefetching mechanism also anticipates which admin screen users are likely to visit next, loading its resources in advance to make navigation between the dashboard, post lists, and editor faster.

Learn more: Trac #57548

For Developers

New Secrets API

WordPress 7.2 introduces a Secrets API, providing developers with a standardized, secure way to store sensitive credentials such as API keys and authentication tokens. The API supports encryption at rest, credential rotation, and customizable storage providers, helping plugins and integrations manage sensitive information more securely.

Learn more (Trac #66187)

Random Content Redirects

WordPress 7.2 adds support for random content redirects, allowing visitors to discover a randomly selected post through a dedicated URL. This provides a simple way to encourage content exploration and help readers rediscover older posts.

Learn more: Trac #64498

More Powerful APIs for Developers

WordPress 7.2 expands the Abilities API with new capabilities for accessing and querying WordPress data, providing a more consistent foundation for integrations, automation, and AI-powered tools. (Trac #66268, #64605, #64657)

Enhancements to the Interactivity API introduce new ways to render trusted HTML and manage reactive navigation, giving developers more flexibility when building dynamic, interactive blocks. (Trac #66246, Gutenberg PR #83092)

Additional improvements to the HTML API, block supports, and responsive design tools provide more reliable markup processing and greater control over how custom blocks are styled and displayed across devices. (Trac #65824, #66150, #65869)

How important is your testing?

Testing for issues is a critical part of developing any software, and it’s a meaningful way for anyone to contribute – whether or not you have experience. Details on what to test in WordPress 7.2 are available here.

If you encounter an issue, please share it in the Alpha/Beta area of the support forums. If you are comfortable submitting a reproducible bug report, you can do so via WordPress Trac. You can also check your issue against this list of known bugs.

Curious about testing releases in general and how to get started? Follow along with the testing initiatives in Make Core and join the #core-test channel on Making WordPress Slack.

WordPress 7.2 will include new features that were previously only available in the Gutenberg plugin. Learn more about Gutenberg updates since WordPress 7.1 in the What’s New in Gutenberg posts for versions 23.7, 23.8, 23.9, 24.0, 24.1, 24.2, and 24.3.

What’s new in WordPress 7.2?

With so much in progress for WordPress 7.2 Beta 1, this is still only the beginning; expect continued refinement with each Beta and RC release ahead of the final release on December 8, 2026

Just for you: a Beta 1 haiku:

Ipsum takes the stage
Secrets bloom, designs take shape
New blocks come alive

Props to @audrasjb, @annezazu, @adamsilverstein, @westonruter, @markoserb, @im3dabasia1, @jorbin, and @noruzzaman for proofreading and review.

OpenStation is a free WordPress plugin that turns wp-admin into a desktop. Every admin screen opens in its own window that you can move, resize and keep open next to the others. You can try it in your browser right now, with nothing to install.

Can’t see the video? Watch it on YouTube.

Why we built it

Most of us spend the day jumping between screens in wp-admin. You open a post, go back to the list, check the media library, then go back again. With OpenStation, those screens stay open side by side, so you don’t lose your place.

What you get

• A window for every admin page: posts, media, settings, plugins
• A dock with your whole admin menu, including your other plugins
• Several desktops, for example one for writing and one for site settings
• Wallpapers, widgets and accent colors
• Cmd+K to jump anywhere fast
• Your windows are still open when you come back

Try it in your browser

Go to the OpenStation page on WordPress.org and click Live Preview. It runs a full WordPress site with OpenStation in your browser tab, so you can’t break anything.

Install it on your site

1. In your admin, go to Plugins → Add New and search for “OpenStation”
2. Click Install Now, then Activate
3. Click the desktop icon in the top-right corner of the admin bar

It’s safe to try

OpenStation is opt-in for each user, so the rest of your team keeps the normal admin. Click the same icon to go back to the classic view. If you deactivate the plugin, wp-admin goes back to exactly how it was. It doesn’t change WordPress core.

Tell us what you think

Have a question? Ask in the support forum. Found a bug or have an idea? Open an issue on GitHub.

I made a WordPress plugin for my holidays. It’s called Travel Steps, and it turns a trip into a page with a map down one side and the story of each day down the other.

Every photo I take ends up in Immich, on my own server. My phone sends where I’ve been to Dawarich, on the same server. So after a trip I have all the photos and the whole route, sitting in two apps on my private server. The travel apps that make nice trip pages want your photos and your location on their servers. I’d rather keep them on mine.

How it works

You make a trip, give it a first and last day, and press Sync. Travel Steps asks Dawarich for your location over those days, and Immich for the photos you took. You can pick one Immich album instead. If you don’t use Immich at all, upload the photos to the trip. It will detect the start and end dates from the uploaded photos, or an Immich album too.

Sync makes a draft post for every day that has favourite photos. Each one is a “step”. It splits the day into places too. A new place starts when a favourite is more than 2 km from the last one and in a different town. Each place gets a heading and a block of photos, so all that’s left is the writing.

Place names come from GeoNames data that ships with the plugin, so naming a town doesn’t send your location anywhere. Immich only names a place from a photo’s own GPS. A photo from a camera without GPS gets placed from your Dawarich history instead, and named the same way.

Publish the days you want people to see. Drafts stay private, and so do their photos.

The distance at the top follows the whole route, flights included. GPS glitches that put you in the Atlantic for a second are dropped. Anything you’d have needed to travel faster than 1,080 km/h to reach counts as a glitch. Sorry, Concorde.

Your photos stay at home

Visitors never talk to Immich. WordPress fetches each photo, caches it and serves it itself, so Immich and the original files stay private. It caches a trip’s photos in the background after a sync. The trip keeps working when Immich is down. A daily sweep deletes cached photos older than a number of days you choose, whether a trip still uses them or not, and they’re fetched again the next time someone looks.

Photos you upload to a trip keep their GPS in the original, but it’s stripped from every copy WordPress makes, and only those copies are ever sent. A trip can have a password, and you can let some logged-in people skip it.

Pin, hide, cover

Hover over a photo to pin it (always show it), hide it, or make it the trip’s cover. The rest of the day’s photos sit behind a “Show more photos” link.

On phones, those buttons show up after you press Edit photos as illustrated by the images below.

Tap a photo and it opens full screen. On a phone you swipe from one photo to the next, edge to edge. On a desktop there are arrows, and the arrow keys work too.

Try it

Here’s a demo in WordPress Playground. It’s a week in the west of Ireland, running in your browser that installs nothing. Stand-in Immich and Dawarich servers feed the real sync code with photos from Unsplash. You’re logged in as an admin, so press Sync, pin and hide photos, and edit the days in the block editor. It all disappears when you close the tab.

The code is on GitHub. To install it, download travel-steps.zip from the latest release and upload it under Plugins → Add New. It needs WordPress 6.7 and PHP 8.0. Immich and Dawarich are both optional. It has been submitted to WordPress.org but if you read this blog, you’ll know how to install a plugin from a zip file!

WpApp

Travel Steps is built on WpApp, Alex Kirk’s framework for building apps on top of WordPress.

A plugin usually adds screens to wp-admin, or puts its pages inside your theme and hopes the CSS gets along. A WpApp app gets its own URLs instead (/travel-steps/ here), and its pages are plain HTML with no theme in the way. WordPress still does the boring work: users and logins, roles, the block editor, the REST API, cron and the database. WpApp adds the bits in between:

• URL routing, using WordPress rewrite rules,
• pages that don’t load your theme,
• the admin bar on every page, with the app’s own icon (the green map at the top of my screenshots),
• access control using WordPress capabilities.

You can start one with composer create-project akirk/create-wp-app my-app. Alex has a showcase of apps built with it, including a cookbook and a family wiki.

Built with Claude Code

I wrote Travel Steps with Claude Code. The first commit was on 11 October, and there are many more now. Most of the work went round the same loop. I file an issue, Claude fixes it test-first on a branch and opens a pull request, and other agents review it. I deploy it to my own server and try it. The tests run in WordPress Playground too, the same as the demo.

If you run Immich, give it a whirl. Bug reports welcome on GitHub

Demo photos from Unsplash: Cliffs of Moher by Jarek Skowron, Temple Bar by Sarah, Galway by Daniel Zbroja and Anna Hunko, Kilronan by Jonathan Borba. Map © OpenStreetMap contributors.

In mid-April 2026 my employer started a project called “Radical Speed Month” to step away from our existing structures and processes, make space for people to dive more deeply into AI tooling, and try to build new or sleeping ideas. My participation in this experiment ran until late September and I stacked up a lot of explorations without having written about them or about the process. In this post I’d like to highlight some of the results of this time and share some learnings.

Selected lessons

• Massive agentic deployment demands heavy storage and generic compute capacity — inference is not the only bottleneck. This is necessary to support massively parallel checkouts of code, benchmarking, analysis of other software and data, running hierarchies of thousands of test workers and headless browsers, generating and analyzing image and video artifacts, creating indexes, and more.
• Instructing an agent to “find the five hidden defects” is more effective at finding real issues than asking if there are any hidden defects. They may return false claims, but they try to answer the questions they are prompted — it’s not that different than the comparison between asking someone what in their day brought them a smile, or what was difficult for them, rather than asking “how was your day?”
• Agents with web searching capabilities are powerful knowledge-retrieval and aggregation tools. Reports they generate to aid in developing code can be more effective than asking the agents to generate the code directly.
• Models today are incredibly powerful, but guiding human insight is also powerful. Autonomous agentic activity demonstrated a tendency to produce more evidence of accomplished work than actual accomplished work. In a strange way this might reflect the training dataset: corporations must also guard against the dangers of overly-burdensome paperwork.

Projects

All of the projects here were almost entirely built by AI agents, but with my guidance and supervision. Therefore, credit for each of them does not rest entirely with me. However, for the sake of brevity I will omit mentioning in each one that AI tooling was the actual producer.

Each project below is assigned a truly unscientific evaluation:

• The project succeeded with clear value.
• The project completed its goals, but the value is unclear.
• The hard work has completed, but I need to close the loop and deploy it.
• The idea is sound but not ready; it needs more development.
• The project failed to bear fruit for any reason.

My personal favorites:

• Fix bugs in proprietary hardware drivers
• Gather empirical evidence to guide development decisions
• Stream real-world HTML from Common Crawl
• Provide deep insight into PHP script execution
• Rapidly prototype a comprehensive collaborative editing environment for WordPress

Tools

Because I expected a short availability for the enhanced AI access, I prioritized building, early on, tools whose value would outlast the project. Generally I prefer working in offline or local environments, so I built archivers for several services which are only available when connected to the Internet.

While MCP servers were very popular at this time, I have always been unhappy with the load centralization and amplification they create. The same is true for any online resource against which agents perform searches. My intuition is that it’s more considerate to those services to make one batched update, to download all new data since the last sync, than it is to make repeated queries which might overwhelm their servers and fetch the same resources over and over.

Being offline and local, the archivers are extremely fast and operate in the terminal where I prefer to interact.

GitHub archive

Finding GitHub’s search functionality lacking, and wishing for a chronological stream of my activity, I built github-archiver so I could have the tools and performance I wanted. This initially supported searching through PRs, issues, and comments, as well as rendering my own activity in a reverse-chronological view. I eventually added two additional views for replies: people I replied to, and people who had replied to me. This gives me great awareness of my recent conversations and has helped me to avoid losing conversations. Sometimes I struggle to find a PR that I meant to follow-up on, but it disappears from my GitHub notifications and I can’t remember the exact wording that will turn it up in a search result. I even tend to forget in which code repository it was left, so my tool aggregates activity across all archived repositories.

The basic design is a compressed HTTP cache of the GitHub API. When fetching or updating, it respects rate limits and leans on HTTP headers to avoid wasted transfers. After some work with banking APIs several years ago, I found that storing raw HTTP responses proved more flexible than parsing into a custom internal data type, as it lets me rewrite logic in the app later without having to re-download the entire archive. This came in handy several times as I expanded the search index and added more functionality.

The tool renders GitHub content as richly-formatted and highlighted text in a console unless running outside of an interactive TTY. It renders Markdown and HTML content into this rich text format and lays out meta elements in a meaningful way. Its speed, zero-network dependence, and minimized output make it a good fit for agents that would otherwise be hammering GitHub’s API, waiting, and wasting tokens on irrelevant content.

Trac archive

Just like the github-archiver, I built a trac-archive for WordPress’ Trac system. It is feature-similar to the GitHub archiver, but provides an additional perk: because bots relay messages from GitHub back into Trac, issues often have two markup formats in use simultaneously. My trac-archive first parses its content according to Trac’s own system, but then it additionally parses Markdown where it finds it. It shares much of the rendering logic with the github-archiver and provides a clearer experience than the web view due to the additional parsing, syntax highlighting, and ability to exclude bot traffic from the results.

Review the evolution of a series of commits over time

git-sequence-patch was used to help me understand the full scope of the WordPress collaborative editor project. Since many large features or projects span many commits and possibly even months or years of work, this tool reads a number of git commit SHAs and will build a fictitious patch that more or less represents how the entire project would be proposed were it to be proposed against the latest branch head. Another way to look at this is to generate one massive revert commit for the original feature and all descendant changes to it since its inception.

This is a project I had been wanting to build for a long time; for each of the given commits, it tracks which lines were changed by the commits, and then steps forward through the branch history, noting when other commits also modify or remove those lines. Once it completes at the branch head, it prepares a patch to replace all of those lines with the code that was there before the original patch, and reverse the patch. This means that it doesn’t produce a patch that would actually merge, but it produces a patch that’s useful for understanding the full scope of how a change evolves over time.

It’s line-oriented and so would miss some obvious scope. For example, if tracing the sequence for a new function, it will miss a later change which calls into that function. This would actually be possible to add to the tool as an enhancement, but it wasn’t necessary for my purposes at the time and I think it would remain ideally an option rather than a default behavior.

I spend a lot of time trying to quickly understand entire systems that I didn’t write or have any experience with, and this tool is a delight for answering the question: “how has this change evolved through time?”

Analyze real-world HTML from Common Crawl

To better test the HTML API against real HTML documents, I built cc-analyzer, which feeds data from the Common Crawl index into a user-supplied PHP script. This operates in two modes: streaming and batched. In streaming mode it continuously sends HTML documents from the archive into the analysis script. In batched mode, it saves documents from the archive into a subdirectory and then may be invoked again to re-run those documents through specific analysis scripts.

This project has greatly benefited the testing and verification of the HTML API, and informed decisions about what actual HTML syntax patterns exist on the web and what concerns are practical and which are esoteric. Throughout this grand experiment I have examined hundreds of thousands of HTML documents to test the HTML API code, to understand reported and actual text encodings of websites at large, to benchmark changes and optimizations for the HTML API, and to understand parsing needs of real HTML documents.

Instantly search code from the WordPress ecosystem

Veloria.dev (formerly WPDirectory.net) provides fast code search across all of the plugins and themes listed on the WordPress directory. It was experiencing elevated outage rates and I decided at the start of September to recreate it locally as a single binary with a simple compressed offline archive. Previous efforts to slurp the directory left efficiency gains on the table and output around 120 GB of data on the filesystem. By taking advantage of available concurrency, streaming computation as resources are downloaded, pruning the stored files to those which were being indexed, and saving into a custom compressed binary object, my wp-code-search tool was able to archive the directory in five hours storing only 5 GB among three data files: a compressed archive of the source files, a search index, and a metadata archive.

This idea originally came from Dan Luu, who commented that “if we’re repeatedly searching for text on a computer, the obvious thing to do to speed that up isn’t to write a native code compiler for regex matching, it’s to create an index.” Code searches across the entire directory typically return within 10 ms, output syntax-highlighted snippets from the files in which they are found, and the tool can extract those files or entire plugins from the compressed archive. The index is sorted by active installs so the most-deployed results appear first.

This tool has become an invaluable daily driver for me as I refactor Core WordPress internals and want to avoid needlessly breaking existing code.

Towards the end of September I had another long-shot idea: could the ideas making the text search so fast be mixed with structural queries so that I could perform data-flow and control-flow analysis on the code? Turns out that yes, with another 5 GB sidecar index, and a custom WordPress-specific query syntax this was not only possible, but practical with many complicated queries executing in anywhere from a few seconds to a few tens of seconds.

There’s a lot of power in this query syntax to identify complicated code structures and I still have to learn how to generate the kinds of queries I want to. I built the structural code search to aid in discovery of risky code patterns to harden as part of my work improving WordPress’ security stance.

Text-mode access to the modern web

My zs tool performs web searches and downloads rendered HTML pages in the terminal. Fascinatingly enough, when I attempted to start this project I tried explaining very clearly that I wanted to adhere to the terms of use for all services, that I wanted to respect the remote servers providing the content, and that this was a user-agent acting on my behalf to perform queries in the terminal instead of a browser. Unfortunately, it seems like the instructions to follow the rules were misinterpreted as attempted bypasses and overly-refused.

Regardless, I was able to create this non-GUI browser and build up enough of the Web Platform to render the pages I wanted to view. When Captchas and other verification interstitials appear, they render inline into the terminal via terminal raster commands. I’m able to indicate which boxes contain the bus, or motorcycle, or a bridge, which Google seems really intent on learning, and continue with text flows and shell pipelines.

My motivation for building this was to perform web searches from the CLI, but once I had the mechanisms in place to interact with the search engines, I realized I could also use this to grab dynamically-rendered pages. For any given URL, a page loads, executes scripts, and renders until the JavaScript event queue empties or a timeout trips, and then the final DOM serializes into the HTML output.

This makes the tool more valuable than my typical curl flow, which too-often downloads an empty HTML page reminding me that I should be using JavaScript. Because it implemented so much of a browser’s internals, I added a feature to extract the visible text content of the rendered page, something which is surprisingly difficult to download without a full browser and CSS engine, and something which is really valuable when trying to pipe documentation pages into coding agents.

All in all it’s a bit buggy and I would like to start over based on what I learned along the way. It still works sometimes and it’s valuable to me when web pages return otherwise-empty mountains of script contents.

WordPress.com

Clarify wording in notification messages

WordPress.com sends notifications about comments, likes, follows, etc., and sometimes the wording is awkward or inconsistent. I generated a report classifying emotional content of the wording and suggested improvements to better inform the reader of what they could or needed to do. It was effective at joining snippets of strings that are concatenated together throughout the code and provided useful insights. It also provided good suggestions for updates that focused on removing anxiety and clarifying possible actions to take in response to the alerts (e.g. replace “Renewal Failed” with “Payment did not go through; update by May 18 to keep your plan active”). Unfortunately those updates are still on my backlog to deploy.

Migrate confused legacy data to simplify runtime code

There are old notification records in the database with conflated and truncated values, and these require complicated code when rendering them to make sense of the confused properties. I was hoping that it would be possible to have the AI examine these broken records and the generating code and provide clear guidance on how to update them. Among 3,000 old records in the database, it proposed seventeen cases for recovery and fixing. Unfortunately this also sits in my backlog to assess and apply.

Fix translation issues and typos

Developers frequently concatenate separately-translated strings which lead to confusing translations. I ran an analysis for this kind of translation issue inside the notifications source code and also for typos and other mistakes. This produced a list of around fifty bug-fixes, including for a missing namespace specifier that was broken for more than a decade and which hadn’t been noticed in error logs, malformed HTML tags which had been hard-coded in string literals, plenty of concatenated translated strings, broken interpolation placeholders, missing calls to the translation function, and missing null checks. This was deployed in May to the production system.

WordPress, the open-source project

Generate automatic previews for dev-docs changes

WordPress Playground runs a copy of PHP and WordPress entirely in the browser via compilation into a WASM environment. It provides testable previews for WordPress and Gutenberg PRs. Missing has been a way to preview changes to the generated developer documentation, which is notoriously difficult to get running at all, let alone dynamically in a browser. I proposed a demonstrator in #29 that does just that through a GitHub Actions workflow on PRs. It has inspired follow-up, but due to the need to ensure a maintainable solution, is still pending deployment.

Harmonize the ignore ruleset across git and Subversion

The official WordPress source code lives in Subversion with a git mirror. The .gitignore and Subversion ignore rulesets are fundamentally distinct from each other, notably in that git ignore patterns apply recursively through a file tree. I attempted to use AI to harmonize the rulesets. Some adjustments were made, but the entire set still needs careful review.

Visualize per-package activity within Gutenberg

To better understand per-package activity within the Gutenberg editor project, I produced a visualization showing commit activity.

Provide deep insight into PHP script execution

Inspired by my childhood Gameshark, I built a PHP extension to improve my ability to debug and analyze PHP script runs. This started as a way to compare two runs of a given script, but expanded into a set of related but distinct modes.

Differential mode compares which functions were called and how many times across two different script runs; this could be useful for performance optimizations or comparing what runs for two different code paths and was built initially while working on page renders vs API call responses.

Trace value records every function or method call whose arguments contain a requested value. It tracks user space as well as builtin functions and was built to help identify code paths which send untransformed data where it shouldn’t reach. A follow transformations option tracks not only the given value, but also common escaped, encoded, serialized, quoted, slashed, and other variations of it. This is a clever security tool for finding out where and how unwanted data is passed around.

Invariant mode takes a PHP file with “hooks” that attach to functions and methods, either during entry into those contexts or when returning from them. They are supplied the values to the arguments, the $this value if a method, and the return value if a post hook. This enables a novel approach to applying software contracts on code with neither the production runtime overhead nor the noise from the contract-enforcement. This was loosely inspired by Clojure’s core.spec. Because the hooks file is user-space PHP code with access to global state, this provides mechanisms for enhanced testing and analysis code, and when registering a shutdown handler in PHP, can print reports at the end of script execution. Hooks may also raise exceptions to halt execution when any desired invariant is violated, such as when preg_match() receives a pattern that might be attempting to parse HTML.

Unused runtime coverage mode generates a report of all loaded identifiers which were never read or executed during a script execution. A sampling option can be used in production to assemble such a report, probabilistically, over time. This mode was designed to find effectively dead-code that might be lurking behind runtime conditions which can never actually run due to real data distributions. For example, a function which is only ever called before a given date, when the given date is several years in the past. Static analysis will miss this while a month of production sampling with no calls will provide evidence that it’s safe to remove the function, that no other strange or unexpected call-paths are still calling it.

Trace allocations mode traces heap allocations made by PHP during a script execution. It immediately surfaced unnecessary allocation in wp_is_numeric_array(), which was promptly eliminated in [#12100].

This extension has provided incredible insight into how WordPress and other PHP scripts run, and I’ve only scratched the surface of how I can take advantage of it.

Introduce dynamic security policies into PHP with eBPF to isolate plugin code and extensions

Like the php-gameshark extension, I built a modified php binary which coordinates with eBPF in the Linux kernel to apply dynamic security policies and create isolated security domains within executing PHP code. There is no logical separation between executing the Core WordPress code and the code from plugins running on a site. This is a security challenge because the two kinds of code warrant different trust, and a site operator may want to assign unique trust and capabilities to different plugins.

This extension provides a wp_runtime_security_apply_policies() function which registers sandboxing rules against files whose source code matches the provided glob. It allows disabling network access, shell execution, sending of emails, reading uploaded files, and writing uploaded files demonstrating a path towards securing WordPress sites from errant or malicious plugins, as well as an explicit opt-in capability model for plugins as they have need. It doesn’t just protect user-space PHP code either; thanks to the fact that policy enforcement occurs within eBPF, it can also apply the same policies against compiled PHP extensions running on the host, assuming that the extensions are not actively attempting to exploit the guards (the protection is aimed at security vulnerabilities within the commonly-deployed PHP extensions, not against potentially-malicious extensions).

I built this extension after a discussion with Lynn Griffith at WordCamp US in late August. It seems promising but is under-developed and needs production testing. As it relies on eBPF, it only supports Linux environments, ruling out Windows, BSD, and macOS-based hosts.

Benchmark HTML parsing optimizations against realistic data from the Internet

With the aid of cc-analyzer, I automated the benchmarking of numerous optimizations that we have explored over the years with the HTML API, mostly changes to the internal data structures and how attributes are represented during the parse. The AI tooling provided the run-scripts for cc-analyzer, invoked it, and gathered the results. It also collected PRs that I had proposed (using the github-archiver) since May 2023 so that I didn’t have to find them.

Fuzz-test the HTML API

I fuzz-tested the HTML API, finding several unreported bugs, including easy-to-overlook defects in the code. Fuzzing in this way also prevented a number of defects with the rewrite of wp_kses(). This complements the existing spec-compliance tests against the html5lib test suite, practical tests against real HTML from the web, and a unit-test suite covering intentional behaviors.

Scaffold fuzz-testing in Gutenberg

I attempted to build a generalizable fuzz-testing infrastructure for the Gutenberg editor. This was an extended autonomy agentic session that ultimately produced a good-looking dashboard with nothing but false-alarms. I tried to establish a framework in which other developers could easily add new generative categories and the system would run new fuzzers for them, compare outputs, and triage failures. AI parallelism made for impressive work, but in this early project I was unable to accomplish my goal and gave up on the idea.

Port data sync libraries into PHP

As an experiment in goal-oriented design, ten distributed data structure libraries were ported into PHP userspace code to aid in building a demonstrator for the DE-RTC prototype [#12334, #79602]. With minor caveats, this built working copies of yjs, automerge, loro, diamond-types, diff-match-patch, json-patch, json-joy, sharedb-json0, prosemirror-collab, and collabs which passed their upstream test suites when they were converted to call the PHP code. Eight of the libraries were completed within a few days, but loro (the library I was primarily interested in) and json-joy held out the longest, taking weeks to complete. They appeared stagnant for the bulk of that time and rapidly finished passing the remaining tests in a burst at the end. While I had originally built a prototype collaborative editor with yjs (which is what the existing project team had chosen to use in JavaScript), once automerge completed I was able to swap out the synchronization primitive and later do that again with loro, adding the capability to make more semantically granular changes and merges. This work was almost entirely hands-off and ran in the background until it was completed; every ten minutes it updated an HTML dashboard showing status and operating notes.

Fuzz-test the proposed collaborative editor for WordPress

From the end of April until October, I paired with Dan Luu to fuzz-test the collaborative editor proposal, and we uncovered an array of issues which ultimately led to changes in the timeline for the project, as a number of the defects were nontrivial to solve. Most of the fuzz infrastructure was built by Dan, while I attempted to coordinate the reproducible bug reports with the rest of the team and to propose fixes. The fuzzing machinery produced effectively no false positives due to the triage and reproduction steps built in. It also provided the visuals for theoretical bugs which are hard to diagnose manually with a keyboard and mouse, but which actually occur frequently in concurrent systems.

This was a high-reward project for the investment because, while AI was dominant in the early code generation, once the testing suite was established, it was able to continue to operate without much additional AI input, and it’s possible to run without any AI inputs.

It highlighted two aspects of fuzz-testing: the more robust the code being tested already is, the more valuable the fuzz-testing will be; and the more frequently a bug is likely to materialize, the more quickly fuzz-testing will find it. There is a good match here between the needs and the operating characteristics.

Actually, Dan and I were originally looking at working on other projects for this Radical experiment. I had suggested that we use the nascent collaborative editing project to organize our notes and work within a WordPress site — to “dogfood” the editor. We pivoted to this testing and design support role only because of problems which immediately appeared as we tried to use it.

Prototype a comprehensive collaborative editing environment for WordPress

To demonstrate another approach to collaborative editing, I instructed an agent to follow my core principles and requirements for the task and build a prototype. At first I wanted the agent to mimic forming its own company, planning, dividing labor, and harmonizing productivity, but as this ran for weeks it kept descending into a cycle of producing more and more meaningless paperwork with less and less actual work. Around the end of May I rebooted the project with far more direction and guidance, replacing the goal-oriented and hands-off approach with a human-driving-the-loop method. This proved more effective and in two weeks I had a working prototype that demonstrated every aspect that I considered important and lacking in some of the other public proposals. At some point I will share a version of an internal post I wrote summarizing this work. It proved influential on the project and I believe that the continued development of collaborative editing is heading in a stronger direction as a result.

For years I have struggled to adequately convey why specific principles and requirements are important, but having a visual prototype made it feel real in a way that persuasion had failed me. The amount of up-front work to produce this prototype had been obstructive for years, and without the agent I would not have been able to communicate the tradeoffs involved in its approach.

Restore developer documentation generation by updating deprecated legacy code

At the end of February I had restored WordPress developer documentation which had been stale for two years due to failing build scripts and deploy scripts. While this work resolved most issues and unlocked updated docs for WordPress 6.9, there remained a few unresolved issues which led to specific submodules being excluded from those docs. In mid-May, fixes for the remaining issues were applied to the dependent projects which removed all remaining barriers. All documentation was updatable again and the scripts could run in the latest PHP versions without crashing.

Prevent mistakes in commit messages and automate the repetitive parts of writing them

After seeing my colleague Jon Surrell’s neovim linter for writing WordPress commit messages, I ported his linter into a single-binary/stdout LSP usable in any LSP-supporting editor. This expanded the work Jon did and built upon work from my other tools to show inline previews of Trac tickets and GitHub PRs. It included new auto-fixers for formatting and line ordering and I use this today to prepare my commit messages, avoiding mistakes I have overlooked in the past.

Gather empirical evidence to guide parsing decisions in the HTML API

I used an instrumented custom build of PHP and lexbor in September to answer a perplexing question: “how many tokens of lookahead would be required for the HTML Processor to fully-parse a given percentage of all HTML documents?” This stems from the tricky re-parenting issues in HTML tree building, where a syntax form at the end of the document could appear towards the start of parsed tree structure. The instrumented code examined when lexbor ran its “adoption-agency algorithm” and tracked how much further into the document the current token appeared after the token associated with its actual parent node.

An hour-long run of cc-analyzer showed that among 70,000 documents, approximately 1,000 require at least 1-token lookahead, only about 250 could parse with 5-token lookahead, and 13 would have required more than 10,000-token lookahead! In one case, a document contained an un-closed <b> tag near the start of the document, and then 400 kB and 35,000 syntax tokens later, triggered re-parenting — no default behavior will offer 35,000-token lookahead.

The outcome of this run was disappointing, but the data was invaluable and prevented wasting time implementing a lookahead mechanism that wouldn’t meaningfully benefit consumers of the API.

Review and scrutinize code change proposals

Throughout the entire experiment AI was providing valuable code review and patch preparation. WordPress security fixes are typically backported to WordPress 4.7, which covers 25 released versions and trunk. Many of these support older versions of PHP missing standard-library features that newer code depends on, and lack WordPress functionality that newer code depends on. When preparing a backported patch, I created reports detailing which features and functions had to change at each WordPress release, and what was driving that need. I found these to be more useful than having agents automate the backporting as fewer mistakes were overlooked when I was performing the changes with the assistance of the reports.

AI code review was invaluable though during the refactor of wp_kses() within WordPress. For weeks I instructed it to find the remaining overlooked defects that need resolving before merge, and it kept finding places to harden or fix the code. I never asked an agent to perform “code review” or indicate if a patch was ready to go. Instead, I instructed them to find hidden defects that I wasn’t sure existed, but when told to return three items, they would do it! I consider these kinds of situations among LLMs’ greatest strengths, when false negatives are more costly than false positives, and when validating claims is trivial. Every issue the agent claimed became a test that proved or disproved it and now guards against regression.

Simplenote and Simperium

Implement well-defined feature requests in unfamiliar code

To explore autonomous feature development, I had an agent resolve a concrete bug report describing difficulty copying content from historic revisions of a note [#3358]. This kind of enhancement/fix was frustrating previously because it touches numerous parts of the codebase I was unfamiliar with. The models picked up a number of places I would have overlooked when working on the problem.

Document confusing data flows in unfamiliar projects

The data service powering Simplenote was written with untyped Python code, and partial duck-typed data structures are passed around which can make code comprehension dizzying. While I wanted to avoid AI-generated code changes, given how critical the backend is, in late May I produced comment-only changes annotating data types and providing explanatory comments where certain code constructs were unclear. This was a low-effort way to pass along some insight about the code in hopes that it makes someone else’s job clearer in the future, as I have not maintained this codebase for years.

Random

Monitor Codex usage

codex-usage-report.py scans the ~/.codex directory and summarizes token counts, the models which were used with them, and approximates the dollar cost of that usage based on current API pricing.

Export Codex usage into a searchable format

As the radical experiment was drawing to a close, I created a Codex exporter which dumps the session data into a giant single-file HTML archive where I can search interactively through the sessions and view the chat history, including tool calls, in a rendered view. I’ve referenced this several times as it’s quick and easy compared to logging into a server, finding the right session, and searching through its history.

Run inference on unsupported legacy hardware

My old MacBook Pro came with a dedicated Radeon GPU and sits idle or off most of the time. llama.cpp doesn’t support the older GPU and so I wanted to see if I could get it running. It did produce a working copy that runs local inference on the Radeon GPU, but in practice it underperformed the CPU-based inference for the same models. With only 4 GB of VRAM, it couldn’t load enough weights at one time to operate without constantly transferring data, and the transfer overhead was too high. I explored different means of sharing work between the CPU and GPU, but they were fighting for memory bandwidth.

While this didn’t provide me with a low-and-slow inference engine, it demonstrated the ideas and ran the experiments which is something I had little patience for, given that I expected poor usefulness in the best of cases.

Fix bugs in proprietary hardware drivers

At home I use my Fujifilm X-T3 as a webcam. It makes for a great quality video feed, but when Fujifilm updated the camera driver to integrate with one of the previous macOS updates, they introduced a memory leak which would end up using 90 GB+ of RAM plus swap by the end of a call and sometimes take down my system before I realized it. Knowing I had little hope of motivating Fujifilm to fix this, I made a binary patch to the driver and fixed the bug directly. This was directly inspired by stories of Microsoft fixing bugs in components whose source code they had lost.

To my delight this fixed the memory leak and provided a plausible explanation. By decompiling the driver, the AI found a missing call to release JPEG data from each frame after passing it to CMIOSampleBufferCreate — a classic memory bug. It predicted the impact of this defect and confirmed the rate of memory bloat with successive system dumps of the process. To add the missing release call it shuffled around some existing instructions to a region of padding bytes in the driver and then called into those; this freed up the bytes necessary for the instructions to call the release function. 44 bytes are written across three spans to make the fix, and this is a verifiable fix that I was able to apply without disabling the system integrity protection — an even better delight.

This has been quite possibly my favorite AI-assisted project. There is no way I could have imagined doing this work myself or having traction with Fujifilm to debug and fix this issue, and yet now I can have video calls run on for hours (were I to want such a thing) and memory use by the driver is fixed; it doesn’t fill up and then purge all of my RAM.

A special thanks belongs to Automattic for providing this space in which to learn and explore, to OpenAI who provided elevated access to their frontier models and made it possible to preview what a future of abundant AI might look like, and to the Jetstream2 project funded by US taxpayers who donated high-capacity compute resources to help improve the reliability and security of the WordPress project. I would also like to thank Dan Luu, who worked with me on this project and who taught me so much about practical generative/fuzz testing, and with whom I could never keep pace, in the best of ways.

Over the course of this time period I worked with GPT-5.4 all the way up to GPT-6-Astra, at ultra thinking levels on fast priority, and with Claude Sonnet 4.6–5.4. The earliest use came from Qwen3.5-397B-A17B, but I had also been running Qwen3.5-27B-4bit locally before the experiment started, and by the end was relying on Qwen3.6-27B-4bit.

I’m thankful for the chance to reach into the past and demonstrate ideas I’ve had sitting on the back-burner, as well as to look towards the future and prototype designs I want to see turn into usable products.

How employment is changing at Anthropic is a fascinating read.

We get a lot of flak at WordPress.org for supporting older PHP versions, but an area we’ve always pushed the frontier is in Web Standards, getting websites and browsers evolving together to make the web richer. Ever since I caught the religion from Zeldman, promoting more functionality in the browser has been a life mission.

It’s a little nerdy, but we wanted to do client-side media processing (use all that amazing Apple and Google silicon instead of burdening the poor servers) so we used something amazing Google created called Document Isolation Policy. When WordPress 7.1 “Mary Lou” shipped these features only worked in Chromium-based browsers and Mozilla and Webkit/Apple weren’t keen to support it, but since then Mozilla has expressed support and WebKit has withdrawn their initial concerns. WordPresser Adam Silverstein has been driving much of this work and opened a WICG issue to help move the standard forward and formally requested that WebKit add support.

Hat tip: Anne McCarthy for helping with this post.

(If you want to see other crazy stuff we’re doing in browsers, check out WordPress Playground, I think it’s actually the perfect web development environment for agents, which can then publish to Spacefast.)