Forthcoming releases 🚀

WordPress 6.9 Timeline

WordPress 6.9 is planned for December 2, 2025, with BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 beginning October 21.

Bug Scrub Schedule

Regular scrubs are already underway, led by @wildworks and @welcher across time zones.
Full details are in the Bug Scrub Schedule for WordPress 6.9.

Call for Testing 

The Test Team invites testing and feedback on the following upcoming blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor features:

• Call for Testing: Accordion Block
• Collaboration: add block-level comments:
  • Actively developed for 6.9. See #66377
  • Several existing issues have already been reported. See #71774
• Call for Testing: Ability to Hide Blocks
• Help test changes to template management

Discussion 💬

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ subprojects status update

@krupajnanda asked for an update on several Gutenberg subprojects, and @youknowriad provided some useful info about their status:

• Stretchy Type Block: Already merged. See PR 71904.
• “Simplified Site Editing” experiment / “content-only patterns” features: They are the same thing with different approach. The latter (content-only patterns) is the most promising approach and is close to land but it is not 100% sure it will be ready for 6.9.

WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Verona’s contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.

@realloc mentioned that he will lead the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. table at WordCamp Verona’s contributor day, and asked if there was any specific focus to help during the day. @audrasjb provided a link to the 19 tickets waiting for proper testing in milestone 6.9.

Improving error handling (wp_die() replacements)

@callumbw95 opened ticketticket Created for both bug reports and feature development on the bug tracker. #64009, which proposes reviewing and updating existing wp_die() calls that currently result in 500 errors. The goal is to establish a more consistent approach to error handling and reduce unnecessary error entries in logs.

@westonruter agreed on the approach: “Since WordPress has always been about semantic markup, it makes sense that it use semantic HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. status codes as well. In the same way we don’t use <div> for everything, wp_die() shouldn’t use 500 for everything”.

@callumbw95 added that “the added benefit is that the debug logs will reduce in size as there are a lot of errors that can be resolved client side (401, 403, etc) that don’t need to sit in the error logs”.

@mindctrl is in the process of reviewing/testing the PR with all the AJAX changes to make sure client side JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. isn’t impacted.

Open Floor 🎙️

Template Output Buffering

Ticket #43258 (PR#8412) suggests adding a standardized output buffering layer in Core. This could unify caching and optimization flows and reduce pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party conflicts. The risk is considered low, though there are concerns about potential effects on TTFB and plugin behavior. Clear documentation and testing will be needed.

@westonruter asked for feedback: “If anyone has input regarding standardizing template output buffering for the sake of optimization or caching, or if anyone has experience with streaming the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. for templates specifically without output buffering, I’d appreciate your feedback on that thread, or the ticket #43258, or the PR“.