The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
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
Milestone
Date
Alpha Begins
Immediately (trunktrunkA 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)
BetaBetaA 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
Tuesday, October 21
Beta 2
Tuesday, October 28
Beta 3
Tuesday, November 4
Release Candidaterelease candidateOne 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). 1
Tuesday, November 11
Release Candidate 2
Tuesday, November 18
Release Candidate 3
Tuesday, November 25
Dry Run
Monday, December 1
Final Release
Tuesday, 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-leadsSlackSlackSlack 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 LeadThe community member ultimately responsible for the Release. – Matt Mullenweg
Release Coordination – helps manage timelines, cross-team collaboration, and status updates
Tech Leads – oversees coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development (including GutenbergGutenbergThe 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/), triagetriageThe 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.
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 PHPPHPThe 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 coreCoreCore 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 SnifferPHP 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 StandardsThe 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.
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 GitHubGitHubGitHub 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, IDEIDEIntegrated 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.
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 GutenbergGutenbergThe 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/?
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 JavaScriptJavaScriptJavaScript 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 ticketticketCreated 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.
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 pluginPluginA 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.
This post summarizes key discussions from the most recent coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.committercommitterA 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:
BlockBlockBlock 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 APIAPIAn 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., HTMLHTMLHyperText 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 pluginPluginA 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 UXUXUser 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 GutenbergGutenbergThe 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.orgThe 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 (DRIDRIDirectly 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 UIUIUser 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 PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher/MySQLMySQLMySQL 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 migrationMigrationMoving 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 SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., P2P2A 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.
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 CoreCoreCore 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 pluginPluginA 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 bugbugA 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.
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 enhancementenhancementEnhancements 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 PHPPHPThe 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 TracTracAn 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 triagetriageThe 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 blockBlockBlock 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 ticketticketCreated 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 CustomizerCustomizerTool 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 APIAPIAn 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 requestA 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 metaMetaMeta 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.
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 coreCoreCore 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 “betaBetaA 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”.
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.
Allow the label to be retroactively removed from the current major releasemajor releaseA 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 PHPPHPThe 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’s new in GutenbergGutenbergThe 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).
This release contains improvements to the Interactivity APIAPIAn 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 blockBlockBlock 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 UIUIUser interface. This includes the Author, AvatarAvatarAn 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
CoreCoreCore 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 iOSiOSThe operating system used on iPhones and iPads. compatibility. (70354)
Image: Fix outdated accessibilityAccessibilityAccessibility (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.jsonJSONJSON, 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 parsing of comments without siblings. (70304)
Global Styles
Fix: Global styles affect all form elements ( Form Block ). (70392)
Implement uniform headerHeaderThe 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
Fix: Update post-publish panel to use taxonomyTaxonomyA taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. label instead of hardcoded “Tags”. (70410)
Media
Invalidate entities when new media is uploaded. (70405)
PluginPluginA 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)
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.orgThe 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)
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 reactReactReact 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)
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 sidebarSidebarA 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)
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 TesterpluginPluginA 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 candidateOne 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.
6.8.1 RC1 is a release candidaterelease candidateOne 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 coreCoreCore 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 PHPPHPThe 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
#63307REST APIREST APIThe 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
#63339 WordPress 6.8 REST API returns all sticky posts regardless of per_page setting
#63358Adminadmin(and super admin) Bar: Restore the Edit Site link to its previous link (link to templates)
GB-69958 Use split view for metaMetaMeta 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 testCode 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 blockBlockBlock 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 branchbranchA 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.orgThe 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/SlackSlackSlack 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.
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 MySQLMySQLMySQL 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 PHPPHPThe 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.
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:
Version
Project
Initial Release
EOL Date
8.4
MySQL
April 30, 2024
April 2032
8.0
MySQL
April 19, 2018
April 2026
11.8
MariaDB
June 5, 2025
June 2030
11.4
MariaDB
November 22, 2024
May 29, 2029
10.11
MariaDB
February 16, 2023
February 16, 2028
10.6
MariaDB
July 6, 2021
July 6, 2026
10.5*
MariaDB
June 24, 2020
June 24, 2025
10.4*
MariaDB
June 18, 2019
June 18, 2024
The following releases were treated as LTS versions, but were not explicitly labelled as such:
Version
Project
Initial Release
EOL Date
5.7*
MySQL
October 21, 2015
October 21, 2023
5.6*
MySQL
February 5, 2013
February 5, 2021
5.5*
MySQL
December 3, 2010
December 3, 2018
5.1*
MySQL
November 14, 2008
December 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.
Version
Initial Release
EOL Date
9.3
April 15, 2024
July 2025
9.2*
January 21, 2025
April 15, 2025
9.1*
October 14, 2024
January 21, 2025
9.0*
July 1, 2024
October 15, 2024
8.3*
January 16, 2024
July 1, 2024
8.2*
October 25, 2023
January 16, 2024
8.1*
July 18, 2023
October 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.
Version
Initial Release
EOL Date
11.2*
November 21, 2023
November 21, 2024
11.1*
August 21, 2023
August 21, 2024
11.0*
June 7, 2023
June 6, 2024
10.10*
November 17, 2022
November 14, 2023
10.9*
August 22, 2022
August 22, 2023
10.8*
May 21, 2022
May 20, 2023
10.7*
February 14, 2022
February 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 patchpatchA 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 candidateOne 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 Versions
Initial Release
EOL Date
12.1 (currently in preview innovation release)
TBD
12.0 (currently RC innovation release)
TBD
11.7*
February 13, 2025
May 12, 2025
11.6*
November 22, 2024
February 13, 2025
11.5*
August 15, 2024
November 21, 2024
11.3*
February 19, 2024
May 16, 2024
Major Releasemajor releaseA 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 earlier
X.(Y+1)
Every new release
10.4-11.2
X.(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).0
Only 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.3
Initial Release
EOL Date
10.3*
May 25, 2018
May 25, 2023
10.2*
May 23, 2017
May 23, 2022
10.1*
October 17, 2015
October 17, 2020
10.0*
March 31, 2014
March 31, 2019
5.5*
April 11, 2012
April 11, 2020
5.3*
February 29, 2012
March 1, 2017
5.2*
November 10, 2010
November 10, 2015
5.1*
February 1, 2010
February 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
Version
Usage
MariaDB – all versions
52.8%
MySQL – all versions
47.2%
By Version Type
Release Type
Usage
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 Releases
1.52%
MySQL Innovation Releases
0.07%
Other
0.5%
By Support Status
Support Status
Usage
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, CoreCoreCore 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-CLIWP-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 metaMetaMeta 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.
WordPress 6.8 introduces a new function wp_register_block_types_from_metadata_collection(), which allows plugins to register multiple blockBlockBlock 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.
To recap the relevant functionality added in WordPress 6.7:
Plugins can now optionally register a PHPPHPThe 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 CoreCoreCore 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.jsonJSONJSON, 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 pluginPluginA 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 JavaScriptJavaScriptJavaScript 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:
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.
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 CodeLines 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:
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:
TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker.#62267
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.
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 ticketticketCreated 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.
The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the CoreCoreCore 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 GutenbergGutenbergThe 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/pluginPluginA 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.
You must be logged in to post a comment.