WordPress 6.9 Planning Proposal and Call for Volunteers

Planning is underway for WordPress 6.9, and this post outlines a proposed schedule along with a call for volunteers to support the release process.

Following the typical cadence and accounting for holidays later in the year, the proposed final release date for 6.9 is Tuesday, December 2, 2025.  This proposed timeline remains flexible to adjustment by the resulting Release Squad as they determine what timeline works best for their schedule.

Proposed Schedule

MilestoneDate
Alpha BeginsImmediately (trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. was open on March 25th)
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. 1Tuesday, October 21
Beta 2Tuesday, October 28
Beta 3Tuesday, November 4
Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1Tuesday, November 11
Release Candidate 2Tuesday, November 18
Release Candidate 3Tuesday, November 25
Dry RunMonday, December 1
Final ReleaseTuesday, December 2

As always, all dates are subject to change based on development progress.


Call for Volunteers

Each WordPress release depends on contributors from across the project coming together to make it a success.  As with the 6.7 and 6.8 release cycles, WordPress 6.9 will continue the approach of forming a smaller, focused Release Squad.  This streamlined structure places more emphasis on collaboration with the various Make Team Reps, who are encouraged to help coordinate efforts from within their respective teams.  The goal is to reduce the overhead on the Release Squad while still ensuring each team’s contributions and priorities are represented throughout the cycle.

If you’re interested in helping with WordPress 6.9 in one of the following roles, please comment below or reach out in the #6-9-release-leads SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel:

  • Release LeadRelease Lead The community member ultimately responsible for the Release.Matt Mullenweg
  • Release Coordination – helps manage timelines, cross-team collaboration, and status updates
  • Tech Leads – oversees coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development (including 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/), triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., and critical issues
  • Design Lead – ensures consistent, user-focused experiences across new features
  • Triage Lead – help monitor issues, shepherd patches, and guide contributors
  • Test Lead – coordinates testing efforts across the community and test reports

Whether you’ve led a release before or are looking to get involved for the first time, there are many ways to contribute.  Volunteers of all experience levels are welcome!

If you’re interested in volunteering, please leave a comment below noting your preferred area(s) by Friday, July 25th.

Let’s build WordPress 6.9 together!

Props @annezazu @priethor @4thhubbard for reviewing this post.

#6-9, #planning

Proposal: PHPStan in the WordPress core development workflow

tl;dr Several official WordPress projects use PHPStan for static code analysisStatic code analysis "...the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing." - Wikipedia of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files as part of their development tooling and quality control. It’s used by thousands of WordPress plugins and themes to catch and prevent bugs before they’re committed. Let’s use it for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. too.

What is PHPStan?

PHPStan is a mature, popular, and well-maintained static code analysis tool for PHP. From the PHPStan website:

PHPStan scans your whole codebase and looks for both obvious & tricky bugs. Even in those rarely executed if statements that certainly aren’t covered by tests.

You can run it on your machine and in CI to prevent those bugs ever reaching your customers in production.

PHPStan provides a means of scanning 100% of the PHP code in a project and identifying whole classes of bugs relating to code correctness within the context of the project as a whole, even before executing, testing, or writing tests for the code.

Another static code analysis tool that is already in wide use in WordPress is PHP_CodeSniffer (PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS.), which checks adherence to coding standards that primarily relate to code formatting (although the WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. provides additional rules for security, performance, and internationalisation best practices). PHPStan doesn’t care about coding style, it is un-opinionated and only tests the validity and correctness of code using increasingly strict levels of rules which allow it to be gradually introduced into an existing code base, even one the size and age of WordPress. It is complementary to PHPCS, not a replacement.

What is being proposed?

On #61175, @westonruter notes that:

PHPStan is a vital static analysis tool for identifying bugs in code. Previously it has been used to identify problems in core by manually running PHPStan on the core codebase.

This post proposes that:

  • PHPStan gets added as a development dependency to WordPress with the required settings and a configured baseline.
  • PHPStan analysis runs as a required check during CI on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions.
  • Documentation on usage of PHPStan gets added to the core handbook.
  • These changes are implemented during the WordPress 6.9 development cycle.

@justlevine has kindly been working on the bulk of the core implementation, the baseline, and the CI workflow in this pull request on GitHub. Work on a documentation page for the handbook is yet to start.

The advantage of implementing a baseline is that PHPStan analysis can be introduced without having to make sweeping changes to the core codebase in order to pass all of the PHPStan rules from day one. The analysis will apply to code changes going forward, and existing issues in the baseline can continue to be addressed just as they have been in recent releases.

Benefits of PHPStan

Adopting PHPStan improves our codebase and development workflows in several ways:

  • Catch bugs in untested code: Unit, integration, and E2E tests only cover the code they execute. PHPStan can find bugs in code that isn’t explicitly tested, and make sure that code changes don’t introduce new bugs even in old code that has no tests.
  • Prevent logic and type errors: Unlike the enforcement of code formatting in PHPCS, PHPStan can trace the flow of code execution and identify critical errors that would otherwise only be caught at runtime. This is increasingly important as we work to maintain compatibility with the increasingly strict type safety requirements of PHP.
  • Improve contributor experience (for humans and 🤖): PHPStan provides immediate, automated feedback to contributors, helping new, veteran, and even agentic developers catch their mistakes and learn how to navigate the WordPress codebase. This reduces the burden on committers during code review and helps AI tooling use WordPress as accurately as possible.
  • Incremental adoption: PHPStan provides levels of strictness that can be adopted incrementally, as well as ways to ignore rules and baseline errors in preexisting code without interrupting the codebase. This keeps in line with the policy against unnecessary code refactoring.

Taken together, using PHPStan will help the project maintain and improve the quality and correctness of the WordPress codebase, paving the way for faster development, fewer bugs, and the safe adoption of newer PHP features over time.

While not a part of this proposal, PHPStan also offers benefits such as type narrowing, IDEIDE Integrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality. hinting, documentation, and code validation features like generics, callable signatures, integer ranges, and lots more. These enhancements can be implemented as and when appropriate.

Concerns

When the implementation of native TypeScript in Gutenberg was proposed, there were some concerns raised:

  • The use of TypeScript could raise the barrier to entry for contributors.
  • TypeScript may not be here forever (ie. it could be outlasted by the underlying language).

If similar concerns are applied to the implementation of PHPStan:

  • Like any tool, there is an element of learning involved and there is always a risk of raising the barrier to entry, however that should not be a reason to refrain from introducing new tooling that provides an overall benefit to the project. Contributors who have not used PHPStan before may not be familiar with its error messages and may need guidance addressing issues that it reports, but handbook documentation, guidance from others, and general familiarisation over time will help. We’ll likely also find that the new generation of PHP developers is familiar with PHPStan due to its wide usage in many other popular and newer projects.
  • Unlike TypeScript, PHPStan isn’t a language itself that needs to be interpreted or transpiled in order to convert it to the PHP code that runs WordPress. If the PHPStan project were to disappear, WordPress would continue to work, the PHPStan checks could be removed, and another static analyzer could be implemented if necessary. That said, PHPStan is an active and well-maintained project so this shouldn’t be a concern.

You might have heard that PHPStan is only used to check type declarations, but this is not correct. In fact it only takes types into account when you start using it at level 3 or higher, and its scope is far beyond just type safety. Take a look through the PHPStan rule levels to see what it covers.

You might have heard that PHPStan only works for object-oriented codebases, this is also not correct. There is nothing inherent about PHPStan that restricts it to analyzing only OOP code. It works great with functional, procedural, and OOP code, with and without namespaces, and mostly whatever else you can throw at it, including excellent support for incomplete code.

There are two alternatives to PHPStan: Psalm and Phan. All three of these static code analysis tools are mature, popular, and well-maintained. PHPStan is being proposed because it’s the most popular out of these three tools (both inside and outside of the WordPress ecosystem), and because it’s the one that is most familiar to contributors to other official WordPress projects, and contributors and committers to WordPress core. Implementing PHPStan will not prevent developers using Psalm or Phan to scan their plugins, themes, or projects, or indeed to scan WordPress core using those tools too.

What about 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/?

The Gutenberg repo does not use PHPStan, however it would benefit from doing so in the same way that WordPress core will. A proposal to implement PHPStan into the development of Gutenberg can be found here. It’s not strictly part of this proposal, but the teams do need to determine whether this is a prerequisite.

Does this affect end users?

End users and website owners are not directly affected by this change. PHPStan itself does not affect PHP at runtime in much the same way that TypeScript doesn’t affect JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. at runtime. The purpose of this class of tooling is to allow developers to maintain code at a higher standard.

The effect this has on end users, consumers, developers, and web hosts is a higher quality application that is more maintainable, reliable, and correct, and will continue to be so over time. 

Next steps

  • This proposal can stay open for a couple of weeks as several northern hemispherical contributors and committers are enjoying well-earned holidays.
  • Work needs to continue on the pull request that adds the configuration, baseline, and CI.
  • Continued communication needs to happen with the Gutenberg team to determine whether PHPStan scanning in Gutenberg is a prerequisite.
  • A documentation page for the handbook needs to be drafted.

The latest version of PHPStan will be used (currently 2.1.17). This requires PHP 7.4 or greater which means the implementation of PHPStan depends on the minimum supported version of PHP in WordPress being increased to 7.4, which is under consideration for WordPress 6.9. Therefore the 6.9 development cycle needs to be announced before this change can be implemented. In the meantime there is no need to be concerned about PHPStan failures on PHP 7.2 and 7.3 in the pull request.

Further technical details can be found on ticketticket Created for both bug reports and feature development on the bug tracker. #61175.

Elsewhere

If you’re curious about how other projects use PHPStan, here are some links.

PHPStan is used by thousands of WordPress plugins, themes, tools, and projects, and 25,000 packages across the PHP ecosystem.

It’s been in use for years by several other official WordPress projects, including:

It’s also been used previously by individual contributors to remediate many issues in WordPress core, most recently in #63268.

If you are interested in using PHPStan as part of the development tooling in your 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, theme, or project, you should take a look at the phpstan-wordpress package by Viktor Szépe which provides WordPress-specific extensions for PHPStan.

Acknowledgements

Thanks to @justlevine @westonruter @swissspidy @sergeybiryukov and others for their work on PHPStan fixes in recent releases and for helping with this proposal.

#developer-experience, #php

Core Committers Check-in – July 2025

This post summarizes key discussions from the most recent coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. meeting held with project leadership. As with previous check-ins, the goal is to align on key initiatives, gather feedback, and clarify next steps for the WordPress project.

Note: This meeting followed the Chatham House Rule.

WordPress 6.9 Release Planning

Discussion focused on priorities and scope for a 6.9 release in 2025 (pending alignment on final schedule from @annezazu @jeffpaul). The group explored potential directions for 6.9, including:

  • Completing and stabilizing in-progress features such as:
    • Design tools and writing experience improvements
    • 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. bindings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API, and Interactivity API
    • Enhancements to the command palette
  • Early promotion of a canonical AI-related 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, focused on foundational APIs (e.g., the Abilities API), rather than bundling AI functionality directly into core.
  • Continued iteration on infrastructure improvements and smaller UXUX User experience wins.

There was broad agreement to continue discussion asynchronously and collaboratively shape a public 6.9 roadmap post.

Adminadmin (and super admin) Redesign / “MP7” Exploration

A significant portion of the meeting centered around evolving wp-admin. There was alignment on the need for wider user testing through the 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/ plugin ecosystem, though implementation details are still to be worked out.

Key points:

  • There’s early alignment to test the refresh using the Gutenberg plugin (potentially as an opt-in experiment or a separate “MP7-style” plugin).
  • Using a larger testing base was favored over starting a new plugin from scratch.
  • Additional strategies discussed included:
    • Feature callouts in slash.news
    • Outreach via WordCamps and testing cohorts
    • Reviving structured usability testing programs

The redesign discussion also surfaced interest in expanding collaboration tools like block-level commenting and async workflows, some of which are already underway in Gutenberg.

Follow-up conversation is planned in #core-editor to shape implementation plans and clarify MVPs.

Plugin Classifications & Maintenance

The group discussed distinctions between canonical and feature plugins, and how those classifications inform expectations and maintenance.

Key takeaways:

  • Feature plugins are exploratory, short-term, and may eventually graduate into canonical status. But that’s not a guarantee nor the expectation.
  • Canonical plugins are officially supported, listed as authored by WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, and expected to have a directly responsible individual (DRIDRI Directly Responsible Individual - the people who are taking ownership or responsibility for a particular project or feature.).
  • Two additional potential types were suggested:
    • Experimental plugins: can still graduate to feature or canonical status if they prove valuable.
    • Support plugins (ie. jQuery Migrate Helper and Memory Bump): these are temporary support focused tools addressing specific issues and may be retired when no longer needed.

Improving discoverability of these plugin types within the directory was raised as a longer-term goal, along with contextual activation within wp-admin (e.g., activating collaborative editing directly from the editor UIUI User interface), and better recognizing the contributors on the plugin pages in the directory.

Maintenance & Version Support Policy

The group discussed the challenges of maintaining older versions of WordPress, particularly as support is officially dropped for 4.1-4.6 later this month.

Discussion began around when it might be appropriate to trim another group of old versions. The next road block will be dropping support for 4.9.

  • Its current usage (~1.5%) is roughly 0.5% higher than every other version < 5.8 
  • A  number of sites are likely intentionally avoiding the block editor

Points raised:

  • Consider aiming for a general sub-5% usage threshold before discussing deprecation.
  • Support drop timing should be coordinated across PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher/MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. minimums, database health efforts, and comms with hosts.
  • Site Health visibility remains a pain point for users who don’t know their host/provider more visibility may be needed.
  • A yearly support-drop cadence could help standardize communication and reduce confusion after catching up.

The security team will continue this conversation with the goal of bringing forward a clear and thoughtful resolution.

Data Liberation & Importers

There was strong interest in reviving data migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. tooling as a strategic opportunity to support user freedom and growth.

Points discussed:

  • Existing importers focus on legacy platforms (e.g., Movable Type) and are often unmaintained or broken.
  • The importers are often the first plugin someone installs and can make or break whether the user stays with WordPress.  
  • Interest in adding support for platforms like Substack, Squarespace, Wix, and Framer.
  • Approaches include canonical plugins, browser extensions, and API-based importers.
  • Pairing tools with strong documentation and walkthroughs was emphasized as an effective early strategy.
  • This work may also help identify feature gaps in WordPress itself.

The conversation included exploring how importers can influence core improvements, similar to how early Movable Type importers shaped WordPress functionality.

Next steps include creating a shared issue tracker or discussion hub to catalog opportunities and begin prototyping with the North Star metric being the number of sites successfully migrated.

Future of Default Themes

The group revisited the idea of default themes and whether a TT6 release is appropriate this year. There was not a consensus decision, but the following points were raised:

  • Several contributors questioned whether a new theme was necessary this year, citing:
    • Ongoing maintenance burdens for prior themes
    • The opportunity to promote patterns, style variations, and starter templates instead
    • The need to clarify the vision for how the various tools should work together holistically (pattern directory, templates, font library, block plugins, etc.)
  • Others noted that default themes are a valuable way to:
    • Showcase new features
    • Support learning and education efforts
    • Inspire community creativity

While no decision was finalized, there was clear interest in re-evaluating the purpose of default themes and exploring new ways to demonstrate front-end capabilities across the project.

Campus Programs: Credits & Connect

There was a concern shared about the project potentially being overwhelmed with new contributors due to the Campus Credit pilot program. An update on the Campus Credits pilot was given with the University of Pisa:

  • The pilot includes 25–40 linguistics students contributing this fall.
  • A public announcement is planned soon.
  • Onboarding, mentorship, and scoping work are underway to ensure contributors have a positive and productive experience.
  • Early feedback from Pisa has been positive, and expansion into other departments is being requested.

This pilot is distinct from Campus Connect, which is a separate, events-based program already in motion in multiple regions.

Further planning will take place in public to ensure contributors, mentors, and community members have clear expectations and support.

Additional Topics

  • Theme support forums (particularly for 2025) are understaffed. Need to explore ways to improve coverage, AI-assisted support and better contributor onboarding were mentioned as possibilities.
  • Several participants emphasized the need for a structured user testing program, similar to the original outreach program, to improve onboarding and usability insights.
  • Interest in future tooling like WapuGPT, an LLM-powered support assistant trained on WordPress docs, was raised as a long-term idea.
  • Admin banners and notices were flagged for discussion: fake dismissals, non-dismissible notices, and UX fatigue are causing frustration for users and contributors. Further UX guidance may be needed.

Next Steps / Follow-up

  • Kick off admin redesign technical discussions in #core-editor.
  • Share and collaborate on the 6.9 roadmap draft. (cc @annezazu)
  • Draft plugin classification criteria and expectations for canonical, feature, experimental, and support plugins.
  • Continue public discussion on importer strategy and prioritize modern platforms.
  • Explore policy and timing for ending support for WordPress 4.7 and beyond.
  • Begin scoping something theme related to showcase in 6.8 (a “pattern bundle” or style showcase).
  • Re-engage with prior explorations from the Notifications API and WP Notify efforts to assess paths forward for more consistent, dismissible admin notices and improved admin interactions

Thanks to everyone who participated. These check-ins aim to improve visibility and encourage collaboration across WordPress Core and will continue at a roughly once per quarter cadence. Discussion will continue in Make SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. posts, and upcoming roadmap proposals.

Props: @jeffpaul @annezazu @desrosj

Proposal: Introduce Maintenance Mode For Components

This proposal aims to introduce the concept of legacy components and a process of managing them in a way that is intentional and accountable.

Once something is committed and released in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., it comes with an implicit promise of backward compatibility for the foreseeable future. But it’s not clear what to do when a feature becomes outdated, unused, or deprioritized. These features often remain in Core instead of being removed or moved to a 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, where bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reports and feature requests can be more appropriately handled, as was done with PressThis.

In the past, components have been reorganized or removed when no longer relevant, but removing a component is not always appropriate and there’s a missing middle ground.

Defining Maintenance Mode

Maintenance mode would be an official status for components that should continue to be supported, but are no longer actively developed. Components might qualify for this status for reasons such as:

  • Low priority
  • No Maintainer
  • Better, more modern options available
  • Being replaced in the near future

These components would:

  • Continue to receive security updates when necessary.
  • Continue to consider and evaluate all bug reports on an individual basis.
  • Stop accepting feature or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. requests, unless they are necessary to maintain backward compatibility or prevent breakage in new WordPress or PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher versions.

Maintenance mode could be removed from components in the future if conditions change.

What does maintenance mode look like?

When in maintenance mode, components would continue to have maintainers and regular triaging should continue. They would be marked clearly in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and the Components page.

How would maintenance mode be declared for a component?

The process for placing a component in maintenance mode would be flexible and decided on a case by case basis. The process should be transparent and involve open discussions with the contributor community. The process could work like this:

  • A discussion is opened with (or by) current component maintainers about placing a component into maintenance mode. 
  • A call for proposal and call for feedback on Make Core is published detailing why the component(s) are being considered for maintenance mode.
  • The component is placed in maintenance mode after sign off from leadership.

While a proposal to add the maintenance mode label will usually come from maintainers, it can also be proposed by any Core contributor. Contributors can perform regular audits of all components to try and identify any that are appropriate for maintenance mode.

What are the benefits of placing components in maintenance mode?

  • Clarifies which features are actively maintained, helping contributors and developers focus their efforts where they’re most impactful.
  • Reduces triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. noise by lowering the volume of low-priority feature requests (there are currently over 8200 open tickets in Trac).
  • Prevents contributor frustration by setting clear expectations before time is spent on patches that are unlikely to be accepted.
  • Establishes precedent for responsible deprecation of features without requiring immediate removal.
  • Supports long-term maintenance by allowing legacy components to receive targeted attention without open-ended development pressure.
  • Facilitates better communication with users and extenders about Core’s direction and future support levels.

Current Maintenance Mode Candidates

Here are a few components that are possible candidates for the proposed maintenance mode state.

TinyMCE

TinyMCE no longer powers the 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 and only remains in Core to maintain Classic Editor support and backwards compatibility. There’s currently only 5 tickets in the component on Trac, and updating to more recent versions of the library does not have enough benefit to justify contributors’ time and effort. Its low ticketticket Created for both bug reports and feature development on the bug tracker. volume, lack of active development, and functional redundancy make it a strong candidate for maintenance mode.

Customize

The CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. served WordPress well, but has effectively been replaced by the block editor and full site editing. Sites with block themes no longer have access to the Customizer by default. Despite having 184 open tickets, development has slowed significantly with most activity focused on bug triage rather than feature enhancements.

Shortcodes

Shortcodes played a huge role in WordPress’ evolution, but today blocks offer a more modern and flexible alternative. No new features should be added to shortcodes. In fact, the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.’s brittle nature has historically led to bugs from even minor changes (see #58333). There are currently 54 open tickets in this component (5 feature requests and 11 enhancements).

Pingbacks/Trackbacks

Pingbacks and trackbacks are a big part of blogging, so they should remain for the foreseeable future. It could be replaced by Webmentions in the future should that mature a bit. The last enhancement ticket was merged over 5 years ago now (see #36576), and there has only been one feature ticket in the history of the component (#34420).

XML-RPC

XML-RPC is essential to many external apps and services that interact with WordPress, so it can’t be deprecated. But, the spec has remained largely unchanged for over a decade. There have been no new enhancement or feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. tickets closed as fixed since 2017 (term metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. support, see #40916) and 2012 (retrieving post terms, see #18434).

Conclusion

Labeling components as legacy and placing them in maintenance mode helps set accurate expectations, reduce unnecessary churn, and focus contributor efforts on current project priorities. A documented process also gives maintainers a framework for making intentional, accountable decisions about the level of support each component receives.

If adopted, this approach could help scale WordPress Core’s maintenance model while staying true to the project’s principles.

Props @peterwilsoncc, @priethor, @karmatosed, and @4thhubbard for peer review.

#component-maintainers, #components

Proposal: Remove the “beta support” label from PHP 8.3 for WordPress 6.8

Update: This change has been agreed and implemented.

WordPress 6.4 to 6.8 are labelled as having “beta support” for PHP 8.3. The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. software itself is compatible and has been since November 2023, but due to the acknowledgement that WordPress is rarely used in isolation (without any theme or plugins) this support is labelled as “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. support”.

Last month, combined usage of PHP 8.3 and higher surpassed 10% of all WordPress websites. I am proposing two small adjustments to the criteria for removing the “beta support” label from each PHP version:

  1. Remove the “for at least 3 months” clause from the “Enough sites” indicator. 10% of all WordPress sites is somewhere well north of 3 million and the 3 month clause seems unnecessary at that scale.
  2. Allow the label to be retroactively removed from the current major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. There is no need to wait for the next major release to update the support status if its only remaining criteria is based on usage numbers.

With these two small adjustments, the “beta support” label for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.3 can be removed from WordPress 6.8. If there are no objections then I’ll make this change this week.

What does this change mean for users and extenders?

Declaring PHP 8.3 as fully supported will help continue to provide clarity and confidence to users and to encourage web hosts and users to continue updating to newer versions of PHP. Users and extenders of WordPress can be confident using and recommending more up to date versions of PHP when the WordPress project continues to test, support, track, and encourage use of newer versions both in the core software and throughout the ecosystem.

What about PHP 8.4?

PHP 8.4 was released in November 2024 and its usage is currently at 1.5%, therefore its “beta support” status will remain in place for now.

What about PHP 8.5?

Hold your horses, PHP 8.5 is still in development and its release is planned for November 2025.

Thanks to @jorbin for proof-reading and suggestions prior to publishing.

#php, #php-8-0, #php-compatibility

What’s new in Gutenberg 21.1? (2nd July)

“What’s new in 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/…” posts (labeled with the #gutenberg-new tag) are posted following every Gutenberg release on a biweekly basis, showcasing new features included in each release. As a reminder, here’s an overview of different ways to keep up with Gutenberg and the Site Editor project (formerly called Full Site Editing).


What’s New In
Gutenberg 21.1?

Gutenberg 21.1 has been released and is available for download!

This release contains improvements to the Interactivity APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., refinements to 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. tools, and more extensibility features. Below is a curated summary of the most notable changes in this release.

Developers can now add new icons to the Social Links block by registering additional block variations. The pull request description has code examples for anyone interested.

Now you can add links for all your pet’s socials:

ToolsPanel refactoring continues

Similar to the last release, more blocks have had their settings panels updated to a newer UIUI User interface. This includes the Author, AvatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name., Post Navigation Link and Site Logo blocks.

Changelog

Enhancements

Block Library

  • Author Block: Refactor Settings panel to use Toolspanel. (67965)
  • Avatar: Refactor settings panel to use ToolsPanel. (67952)
  • Comments Pagination: Remove unwanted bottom margin from links. (70360)
  • Navigation Block: Flip submenu indicator icon on submenu expansion. (70307)
  • Navigation Block: Rotate submenu indicator icons on submenu expansion. (70442)
  • Navigation Link: Add dropdownMenuProps and a resetAll function. (70505)
  • Post Navigation Link: Refactor settings panel to use ToolsPanel. (70276)
  • Refactor Site Logo “Settings” Panel to Use ToolsPanel. (67972)
  • [ Experimental Form ]: Add example block previews. (70436)

Interactivity API

  • iAPI Router: Add support for new router regions with attachTo. (70421)
  • iAPI Router: Support new styles and script modules on client-side navigation. (70353)
  • iAPI: Export NavigateOptions and PrefetchOptions types. (70315)
  • iAPI: Introduce AsyncAction and TypeYield type helpers. (70422)

Extensibility

  • Social: Allow custom link icons using block variations. (70261)

Bug Fixes

  • CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. data: getHomePage: Do not return object until resolved. (70345)

Block Library

  • Fix : Calendar block: Colors do not change between global styles and theme.json. (70184)
  • Form Block: Apply class names correctly in the block editor. (70394)
  • FormFileUpload: Extend audio accept MIME types for iOSiOS The operating system used on iPhones and iPads. compatibility. (70354)
  • Image: Fix outdated accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) hint on native component. (70346)
  • Image: Fixed resetAll to return image resolution to default value. (70398)
  • Revert “Flip submenu indicator icon on submenu expansion (#70307)”. (70427)
  • Social Links: Allow icon size to be reset and honor theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. styles. (70380)
  • Video Block: Guard against duplicate tracks. (70295)

Interactivity API

  • Fix image lightbox issues in new full client-side navigation logic. (70416)
  • iAPI Router: Fix dynamic imports on new visited pages. (70489)
  • iAPI: Fix captured errors in withScope generators. (70303)
  • iAPI: Fix duplicated nested regions. (70302)
  • iAPI: Fix parsing of comments without siblings. (70304)

Global Styles

  • Fix: Global styles affect all form elements ( Form Block ). (70392)
  • Implement uniform headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. layout. (70464)

DataViews

  • Data forms: Achieve vertical spacing with vertical spacing rather than cell padding. (70435)

Post Editor

Media

  • Invalidate entities when new media is uploaded. (70405)

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

  • Fix: Incorrect style handle in RTL style registration for wp-list-reusable-blocks. (70402)

Data Layer

  • Add private selector support to resolveSelect and suspendSelect. (52036)

Accessibility

Templates API

  • Templates: Add back button & fix focus loss when navigating through template creation flow. (70091)

Performance

Block Library

  • Avatar: Optimize user control query. (70511)

Documentation

  • Add isPostSavingLocked  example to doc block. (70370)
  • Commands: Add stylesheet requirements to README. (70323)
  • Create Block: Add documentation for custom block namespace. (70215)
  • Docs: Fix broken links on Developer.WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. (70473)
  • Fix some typos. (70419)
  • Fix typo folder-structure.md. (70375)
  • block-attributes: Add role attribute explanation. (70361)

Code Quality

  • Patterns: Delete unused property. (70321)
  • TypeScript: Converts HtmlEntities Package to TS. (69326)
  • TypeScript: Migrate deprecated package to TS. (70362)
  • TypeScript: Migrate is-shallow-equal package to TS. (70407)
  • iAPI: Fix the changelog to include PR 70296 in 6.25. (70309)

Block Editor

  • Media List: Use ‘placement’ prop for popover positioning. (70350)
  • Refactor: URLInputButton component to functional reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. component. (70384)
  • Warning: Replace popoverProps.position to popoverProps.placement. (70347)

Components

  • Circular Option Picker: Use ‘placement’ prop for popover positioning. (70359)
  • FormFileUpload: Remove temporary fix for selecting .heic file in Chromium browsers. (70383)

Post Editor

  • PostAuthorCombobox: Simplify ‘onFilterValueChange’ debounced callback. (70512)

Interactivity API

  • iAPI: Minor fixes to the Interactivity and Interactivity Router comments. (70420)

Block Library

  • Social Link: Use placement prop for popover positioning. (70348)

Tools

Testing

  • Test: Improve document settings sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. locator. (70331)
  • Ensure the actual tests environment is used for end-to-end tests. (70280)
  • Skip falling end-to-end tests. (70460)
  • end-to-end Tests: Add test case for Link color support. (69141)
  • end-to-end Tests: Minor code quality improvement in some tests. (70382)

Various

Block Library

  • Remove screencast.com embed block variation. (70480)

First-time contributors

The following PRs were merged by first-time contributors:

Contributors

The following contributors merged PRs in this release:

@alejandrogonzalvo @BugReportOnWeb @DAreRodz @dd32 @ellatrix @himanshupathak95 @iamsandeepdahiya @im3dabasia @Infinite-Null @jsnajdr @karthikeya-io @kushagra-goyal-14 @Maikuolan @Mamaduka @Mayank-Tripathi32 @NidhiDhandhukiya74 @peterwilsoncc @ramonjd @Rishit30G @SainathPoojary @SantosGuillamot @shimotmk @shrivastavanolo @t-hamano @talldan @USERSATOSHI @vk17-starlord @Vrishabhsk @westonruter @yashjawale @yogeshbhutkar

Props @ramonopoly, @isabel_brison and @andrewserong for peer review. Props @karmatosed for visual assets.

#block-editor, #core-editor, #gutenberg, #gutenberg-new

WordPress 6.8.1 RC1 is now available

WordPress 6.8.1 Release Candidate 1 (RC1) is available for testing! Some ways you can help test this minor release:

  • Use the WordPress Beta Tester 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
    • As this is a minor RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). release, select the Point Release channel and the Nightlies stream. This is the latest build including the RC and potentially any subsequent commits in trunk.
  • Use WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ to test: wp core update https://wordpress.org/wordpress-6.8.1-RC1.zip
  • Directly download the Beta/RC version.

What’s in this release candidate?

6.8.1 RC1 is a release candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). for a maintenance release with a focus on bugs introduced in WordPress 6.8. In total, this RC features fixes for 15 bugs throughout Core and the Block Editor.

The following coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tickets and PRs are included:

  • #62718 Automatic updater of WordPress always fails if FS_METHOD is ftpext since 6.6 with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.0+
  • #63005 Replacing certain bulk-edit fields blocks all bulk edits
  • #63269 Duplicate array key `Code` in `_WP_Editors::get_translation()`
  • #63285 Call to undefined function is_super_admin() in /wp-includes/ms-files.php
  • #63287 Unexpected output from apply_block_hooks_to_content_from_post_object
  • #63302 SVG images can’t be uploaded anymore due to a resizing issue
  • #63307 REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.: Returns incorrect post when querying by slug if sticky posts exist
  • #63323 Reduce copy from 6.8 about page
  • #63339 WordPress 6.8 REST API returns all sticky posts regardless of per_page setting
  • #63358 Adminadmin (and super admin) Bar: Restore the Edit Site link to its previous link (link to templates)
  • GB-69958 Use split view for metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes only when canvas is iframed and “Desktop” view
  • GB-70006 Fix ‘wp-polyfill’ script dependents unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression.
  • GB-70001 Author, Author Name 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.: fix PHP warning error when there is no context
  • GB-69998 Keyboard Shortcuts: Revert delete shortcut to access + z 
  • GB-70000 ToggleGroupControl: Fix active background for empty string value

What’s next?

Reminder: the dev-reviewed workflow (double committer sign-off) is required when making changes to the 6.8 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..

The final release is expected on Wednesday, April 30, 2025. This date is subject to change if any issues with RC1 are discovered. Coordination will happen in the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. #6-8-release-leads channel, and releases are always packaged and tested in #core.

A special thanks to everyone who reported issues, helped test, and helped create patches. The success of 6.8.1 depends on proper testing, so please lend a helping hand.

Thanks to @desrosj and @presskopp for pre-publication review.

#6-8, #6-8-1, #6-8-x, #minor-releases, #releases

Proposal: Clarifying Core’s Database Support Policy

TL;DR Over 37% of WordPress sites are running a version of database software that has reached end of life and is no longer receiving maintenance or security updates. To encourage broader adoption of secure and supported database versions, WordPress should clarify that only LTS releases of MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. and MariaDB are officially supported by excluding those with short lifespans or no guarantee of backward compatibility.

As a community, we frequently champion efforts to keep software and tools updated to their latest versions. This typically surfaces for users in the form of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher upgrades, and for contributors with tools like Node.js and npm. Database software is equally important to site health but has historically received far less attention.

The release models followed by supported database types have changed quite a bit since the early days of WordPress. With that comes a need to update the project’s official policy for clarity. A clearer policy lends to a wider understanding of the expectations and requirements for maintaining WordPress sites.

But before getting into the changes being proposed, let’s define the various types of releases and examine current usage data before outlining a few things for discussion.

Note: If you’re already familiar with the release models of MariaDB and MySQL, you can skip the context directly to the proposal part of the post.

Supported Database Software

There are currently two types of database software officially supported for running WordPress: MySQL and MariaDB. While it’s true that SQLite powers Playground, standard installs of WordPress do not currently support SQLite without installing the feature plugin, which is being actively developed and tested.

Release Types

Both software projects have made several changes to the terminology used to reference releases, making it confusing and inconsistent. For the sake of clarity, here are the different terms associated with releases of MySQL and MariaDB.

Note: All asterisks (*) below indicate versions that have reached end of life (EOL) and are no longer supported upstream. Also, EOL does not always equal “unsupported by WordPress” (more on that later).

Long Term Support (LTS)

LTS versions are published by both projects. These are the most common versions found in the wild. They are actively supported for 5 years from the initial release. After initial release, data formats are not changed, no new functionality is introduced, and no features are removed.

While MariaDB aims to release a new LTS version annually, MySQL publishes a new LTS version every 2 years (starting with 8.4). The list of releases labelled as LTS to date is as follows:

VersionProjectInitial ReleaseEOL Date
8.4MySQLApril 30, 2024April 2032
8.0MySQLApril 19, 2018April 2026
11.8MariaDBJune 5, 2025June 2030
11.4MariaDBNovember 22, 2024May 29, 2029
10.11MariaDBFebruary 16, 2023February 16, 2028
10.6MariaDBJuly 6, 2021July 6, 2026
10.5*MariaDBJune 24, 2020June 24, 2025
10.4*MariaDBJune 18, 2019June 18, 2024

The following releases were treated as LTS versions, but were not explicitly labelled as such:

VersionProjectInitial ReleaseEOL Date
5.7*MySQLOctober 21, 2015October 21, 2023
5.6*MySQLFebruary 5, 2013February 5, 2021
5.5*MySQLDecember 3, 2010December 3, 2018
5.1*MySQLNovember 14, 2008December 31, 2013

Innovation Releases

Though both projects use this classification, only the MySQL project actively uses it as described in this section (see the next section for how MariaDB currently uses the designation). Innovation releases aim to provide early access to new features and improvements without having to wait the full 2 years for the next MySQL LTS version to be published.

The following types of changes are included in new innovation releases:

  • New features planned for the next LTS
  • Security fixes
  • Bug fixes
  • New deprecations
  • Removal of features
  • Behavior changes.

These releases are Generally Available and are acceptable to use in production environments. They are published once per quarter (every 3-4 months). When the next innovation release is published, all support for the previous one is dropped, including security fixes. Because the lifespan of each innovation release is extremely short, consistent regular attention is required to remain supported and secure.

The following is a list of MySQL innovation releases.

VersionInitial ReleaseEOL Date
9.3April 15, 2024July 2025
9.2*January 21, 2025April 15, 2025
9.1*October 14, 2024January 21, 2025
9.0*July 1, 2024October 15, 2024
8.3*January 16, 2024July 1, 2024
8.2*October 25, 2023January 16, 2024
8.1*July 18, 2023October 25, 2023

MariaDB used this label for about 2 years. During that time, they also published a new innovation release every quarter. However, their innovation releases were supported for 1 year after initial GA release. These releases also differed from MySQL in that caution was advised when using these. As of the publish date of this post, all MariaDB innovation releases have reached EOL.

VersionInitial ReleaseEOL Date
11.2*November 21, 2023November 21, 2024
11.1*August 21, 2023August 21, 2024
11.0*June 7, 2023June 6, 2024
10.10*November 17, 2022November 14, 2023
10.9*August 22, 2022August 22, 2023
10.8*May 21, 2022May 20, 2023
10.7*February 14, 2022February 9, 2023

Rolling GA (MariaDB only)

Though they’re similar in some ways, MariaDB now has replaced innovation releases with rolling GA releases. Rolling GA releases are published every quarter (3-4 months) and receive no patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. versions (the GA release is final). All support for the previous rolling release is dropped once a new one is published.

The term innovation release is still used but now refers to the preview (X.Y.0) and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). (X.Y.1) pre-release versions for each rolling release. Rolling GA releases are intended for production use, but the innovation releases are not.

Rolling Release VersionsInitial ReleaseEOL Date
12.1 (currently in preview innovation release)TBD
12.0 (currently RC innovation release)TBD
11.7*February 13, 2025May 12, 2025
11.6*November 22, 2024February 13, 2025
11.5*August 15, 2024November 21, 2024
11.3*February 19, 2024May 16, 2024

Major Releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.

MySQL refers to major versions in the same way as WordPress (X.(Y+1)).

For MariaDB, this term has meant different things during different timeframes.

10.3 and earlierX.(Y+1)Every new release
10.4-11.2X.(Y+1)Each version was considered major because of binary incompatibility and the addition of new features. LTS or short-term become more common descriptors as they indicate length of support (similar to WordPress).
Current day *(>= 11.3)(X+1).0Only when the first number changes (similar to PHP).

While the LTS designation did not exist yet, versions 10.3 and earlier were treated in a similar way.

  • Supported for 3-5 years (sometimes longer)
  • Bug fixes and security updates were provided
  • New features were sometimes included in minor (X.Y.(Z+1)) releases, but compatibility was always maintained.

All MariaDB major releases <= 10.3 have reached EOL. They’re listed below for completeness:

MariaDB Major Versions <= 10.3Initial ReleaseEOL Date
10.3*May 25, 2018May 25, 2023
10.2*May 23, 2017May 23, 2022
10.1*October 17, 2015October 17, 2020
10.0*March 31, 2014March 31, 2019
5.5*April 11, 2012April 11, 2020
5.3*February 29, 2012March 1, 2017
5.2*November 10, 2010November 10, 2015
5.1*February 1, 2010February 1, 2015

While some online resources show the LTS label next to these versions, they were never officially labelled as such.

Short-term (MariaDB Only)

This term was eventually replaced by innovation release. This applied to MariaDB 10.4 in addition to the MariaDB versions listed above under Innovation Releases. As of the publish date for this post, all short-term releases have reached EOL.

Current Database Usage Data

Here is the usage data according to the WordPress.org Stats page as of June 18, 2025 summarized in a few different ways:

By Software

VersionUsage
MariaDB – all versions52.8%
MySQL – all versions47.2%

By Version Type

Release TypeUsage
MariaDB LTS (includes old major releases without LTS official designation)51.17%
MySQL LTS (includes old major releases without LTS designation)46.74%
MariaDB Innovation/Short-term/Rolling Releases1.52%
MySQL Innovation Releases0.07%
Other0.5%

By Support Status

Support StatusUsage
EOL versions (MariaDB)11.43%
EOL versions (MySQL)26.01%
Supported (MariaDB)41.56%
Supported (MySQL)21.05%

Observations

There are a few interesting things that stand out from the usage data.

  • As of March 2025, MariaDB now powers more WordPress sites than MySQL. This is particularly interesting because as of January 2024, the split was ~63%/37% in favor of MySQL. Increases in licensing costs and changes to widely used distributions during 2023 and 2024 are likely the considerable drivers of this surge.
  • Over 37% of WordPress sites are running a version of database software that has reached end of life and is no longer receiving maintenance or security updates.
  • The highest adoption of any innovation/short-term/rolling release was MariaDB 11.3, which reached 0.15%.
  • No other innovation/short-term/rolling releases have surpassed more than 0.10% adoption at any given point in time.

Current State of Database Support in WordPress

Despite MySQL and MariaDB having different release models that drop support in different ways in non-sequential order, WordPress has a very binary support policy. As of the publish date of this post, the support policy is as follows:

  • Recommended: MySQL >= 8.0 OR MariaDB >= 10.6
  • Required: MySQL OR MariaDB >= 5.5.5

A few notes:

  • MariaDB 10.5 reached EOL on June 24th. The recommended version was updated to >= 10.6 on June 18, 2025 (see #60319 and #meta-8013).
  • The minimum required version was last bumped in late 2023 (see [57173]).

The policy as currently stated is lacking any guidance around which types of releases are supported. As demonstrated above, this is complicated and convoluted. The policy should be expanded a bit to cover release types and not just versions.

Proposal: Clarify Supported Release Types

While described as production-grade, innovation releases have several shortcomings when considering the majority of WordPress sites.

  • Features and changes included in innovation/rolling releases are considered stable, but they can be modified or even removed entirely in future releases. No functionality can be considered supported until included in an LTS release.
  • Their ephemeral nature makes it very difficult to ensure compatibility with WordPress when released. Depending on how release timelines overlap, there could be 2 (or more) innovation/rolling versions published in between major WordPress releases.
  • Their extremely short lifespans could potentially leave large numbers of sites running insecure versions.
  • Updating database software is often tied to factors out of the site owner’s control (waiting for server distributions to be updated and made available through your hosting, platform compatibility limitations, compliance/licensing requirements, etc.).
  • For both projects, updating these release types is complicated. Updates must be applied sequentially. For example, upgrading from 9.1 to 9.3 is not supported (9.1 must first be updated to 9.2 before updating to 9.3). This is not required when upgrading to the next LTS.
  • Over the last two years, these release types have not shown significant usage, even when combining the numbers across database types.
  • Because the changes in these releases are not guaranteed to be backwards compatible, committing to full compatibility with these releases is not a good use of contributor time and could result in making code harder to maintain.

Changes to the Database Recommendations

This proposal is suggesting that the recommendations for running WordPress be updated as follows:

  • No change: The oldest LTS versions actively supported upstream should continue being used as the recommended minimums.
  • Add to the Requirements page, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress./Hosting/Support/Other? Handbooks: Innovation and rolling GA releases are explicitly not recommended for production sites. 
  • Add to the Hosting Handbook: Hosting companies are explicitly advised not to use Innovation and Rolling GA releases as the default for new sites.

The WordPress PHPUnit testing workflow currently runs the test suite using the most recent MySQL innovation and MariaDB rolling GA releases. This practice helps to make contributors aware of potential incompatibilities and breaking changes so they can be addressed prior to the next LTS version. This practice will continue.

Because of this, it’s reasonable to expect WordPress to have very few (if any) issues when running these releases. However, this is not guaranteed as contributors must weigh the benefits of making changes for the sake of compatibility with the non-zero chance that the feature is changed or removed before the next LTS release.

Because innovation and rolling GA releases are never supported, only LTS versions are eligible as new minimums when considering changes to the minimum required versions of MariaDB/MySQL to run WordPress in the future. 

In summary, someone is free to run innovation and rolling GA releases, but they do so at their own risk.

Other Considerations

As a part of this, ways to further educate and empower the user should also be explored.

  • Should servehappy be expanded to display a dashboard notice to the user when their site is running an outdated or unsupported version of MariaDB/MySQL (see #63634)?
  • Can there be additional context for the database checks in Site Health to detect innovation/rolling GA releases explaining why they should consider using an LTS version instead?
  • Are there ways to enhance WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ to properly advise about these risky release types?
  • Are any metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. changes required to better inform the site that these release types are not explicitly supported?
  • Do the auto-update related classes require any changes?

Working Together

Reliable and supported database software is foundational to the performance, security, and longevity of WordPress a site. Historically, efforts to promote upgrades among hosts and site owners have been limited and inconsistently prioritized. Clarifying the types of database releases that WordPress supports and is compatible with marks an important first step. It enables contributors, hosts, and site owners to move toward more secure and sustainable versions of MariaDB and MySQL.

Props @johnbillion, @flixos90, @l1nuxjedi, and @annezazu for peer review.

#database, #mariadb, #mysql, #site-health

More efficient block type registration in 6.8

WordPress 6.8 introduces a new function wp_register_block_types_from_metadata_collection(), which allows plugins to register multiple 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. types with a single function call.

This function expands on the foundational capabilities of the wp_register_block_metadata_collection() function, which was introduced in WordPress 6.7 to improve performance.

Context

To recap the relevant functionality added in WordPress 6.7:

Plugins can now optionally register a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher “manifest” file, which includes all the metadata for their block types. For any block type that is being registered, WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will now check whether such a manifest file is present covering the block type, and if so, it will use the data from the manifest file instead of reading and parsing the block type’s block.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file directly.

Since the blocks manifest file includes all the block type names, a logical next step after adding support for such a file is to make the requirement for individual block type registration calls obsolete. This is what the new  wp_register_block_types_from_metadata_collection() function implements.

Benefits

By using the new function, you no longer need to add individual register_block_type() calls for every block type that you include in your 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. This improves developer experience, especially when using the latest block development best practices where the block.json file is used as the sole entrypoint for both PHP (server-side) and JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. (client-side). Adding a new block type to an existing plugin is now possible by creating the block’s directory and working exclusively within that directory. You no longer need to remember to register the block type somewhere else in the PHP codebase of the surrounding plugin.

Example

Let’s say you have a plugin with 5 custom block types: “accordion”, “carousel”, “carousel-slide”, “dialog”, and “icon-button”. At the present, this means your plugin’s PHP code may look like this:

$block_types = array( 'accordion', 'carousel', 'carousel-slide', 'dialog', 'icon-button' );
foreach ( $block_types as $block_type ) {
	register_block_type( __DIR__ . "/build/{$block_type}" );
}

With WordPress 6.8, you can now use the wp_register_block_types_from_metadata_collection() function to eliminate the need for the list of block types in the PHP code so that all block types are recognized and registered automatically.

To do that, you need to generate a manifest file for your block types. You can use the build-blocks-manifest command or the --blocks-manifest argument of the build command from the @wordpress/scripts NPM package, which was also explained in the relevant WordPress 6.7 dev note. It can be easily integrated into your build process by changing the scripts in your package.json file as follows:

  • Change the “build” script from wp-scripts build to wp-scripts build --blocks-manifest.
  • Change the “start” script from wp-scripts start to wp-scripts start --blocks-manifest.

With the generated manifest in place, the PHP code above can be simplified to no longer require a hard-coded list of block types:

wp_register_block_types_from_metadata_collection(
	__DIR__ . '/build',
	__DIR__ . '/build/blocks-manifest.php'
);

Backward compatibility with older WordPress versions

As the wp_register_block_types_from_metadata_collection() function is only available in the latest WordPress 6.8 release, you may still want to support older WordPress versions. Fortunately, the function can be easily replaced by a few lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses., as long as you have a generated blocks manifest in place as described above.

Here is a code example that uses the respective best practices for WordPress 6.8, WordPress 6.7, and older versions:

if ( function_exists( 'wp_register_block_types_from_metadata_collection' ) ) {
	wp_register_block_types_from_metadata_collection( __DIR__ . '/build', __DIR__ . '/build/blocks-manifest.php' );
} else {
	if ( function_exists( 'wp_register_block_metadata_collection' ) ) {
		wp_register_block_metadata_collection( __DIR__ . '/build', __DIR__ . '/build/blocks-manifest.php' );
	}
	$manifest_data = require __DIR__ . '/build/blocks-manifest.php';
	foreach ( array_keys( $manifest_data ) as $block_type ) {
		register_block_type( __DIR__ . "/build/{$block_type}" );
	}
}

The @wordpress/create-block NPM package has been enhanced to use the new functions conditionally, using a similar code snippet as shown above.

Summary and further reading

The new wp_register_block_types_from_metadata_collection() function is a very simple but neat way to eliminate individual block type registration calls from your PHP code, allowing you to focus exclusively on working on the block types in your plugin without having to modify anything else in the plugin.

Please see the following links for further reading:

  • TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #62267
  • Relevant WordPress 6.7 dev note about the previous block type registration enhancements

Props to @gziolo, @stevenlinx for review and proofreading.

Update (2025-04-16): As of @wordpress/scripts version 30.14.0, a bug regarding blocks manifest generation was fixed. This post was updated accordingly to recommend the --blocks-manifest argument of the build command in the NPM scripts to use instead of the build-blocks-manifest command in combination with other commands.

#6-8, #dev-notes, #dev-notes-6-8

Dev Chat Agenda – June 25, 2025

The next WordPress Developers Chat will take place on Wednesday June 25, 2025 at 15:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

The various curated agenda sections below refer to additional items. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda or bring them up during the dev chat.

Announcements 📢

None for this week

Forthcoming releases 🚀

WordPress 6.8.2 is underway.

Discussions 💬

The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.

  • Brainstorming suggested by @paaljoachim “The Full Site Editor is fairly new and there are naturally features that could be improved. It would be great with an overview of current FSE plugins that aim to improve what we have today. I find it difficult to locate external FSE plugins. How can be make FSE plugins more visible in the repo?
    This could perhaps also be extended to walk through the current 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/ 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 -> experiments and where these currently are at in their development phase.”

Open floor  🎙️

Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.

Please include details of tickets / PRs and the links in the comments, and indicate whether you intend to be available during the meeting for discussion or will be async.

#6-8, #agenda, #dev-chat, #wceu-25