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.
WordPress 6.8.2 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 (RC1) is available for testing! Some ways you can help test this minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.:
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 ReleaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. channel and the Nightlies stream. This is the latest build including the RC and potentially any subsequent commits in 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..
Use 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 test: wp core update https://wordpress.org/wordpress-6.8.2-RC1.zip
6.8.2 RC1 is a release candidate for a maintenance release with a focus on bugs introduced in WordPress 6.8 and small enhancements or bugfixes. In total, this RC features fixes 20 issues throughout Core and 15 for the Block Editor.
#14110 – Expose height and width attributes to ‘wp_get_attachment_image_attributes’ filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.
#42007 – rpc.pingomatic.com still using HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.
#47595 – Re-evaluate whether comment form should still get the HTML5 novalidate attribute
#61941 – Removing app.screencast.com as an oEmbed provider
#62995 – Uploading Mac screenshots results in broken images, due to question marks inserted in filenames
#63029 – Better align restore revision buttons on mobile devices
#63073 – Twenty Twelve: theme’s figcaption styles do not apply in the editor
#63254 – Introduce development mode for 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 styles
#63377 – Pin specific 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 version for E2E tests in 6.6 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".
#63390 – Add version number tests for package-lock and composer files.
#63424 – Twenty Sixteen: Quote block Plain style has border in the editor
#63520 – Twenty Fourteen: Latest Comments block link color does not belong in Content 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.
#63543 – Environment variable WP_CONFIG_PATH should be set on cli container in wordpress-develop env
#63564 – Dev environment should incorporate enhancements from wp-env for speed and non-interactive usage
#63588 – do_blocks(): Free up transient memory leak
#69633 – Navigation Link: Improve performance by only requesting entities when selected
#69698 – Query LoopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop.: Don’t overwrite the ‘query.inherit’ attribute value
#69741 – Block Editor: Remove truncation from media tab preview tooltips
#69985 – Image: Avoid stale URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org when reselecting the same image from the library
#70020 – Post Template: Don’t rely on the default ‘ignore_sticky’ REST 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/. value
#70043 – MediaPlaceholder: Fix RegressionregressionA software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. with media URL input type to allow a local URL path
#70051 – DOM: Add summary element to focusable elements
#70054 – Button: Limit scope of width style for link
#68741 – Details: Enable all non-interactive formats
#70056 – Details Block: Fix keyboard 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) issues and allow list view selection to show up inner blocks
#70078 – URL: Handle HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. entities and ampersand in ‘cleanForSlug’
Reminder: the dev-reviewed workflow (double committer sign-off) is required when making changes to the 6.8 branch.
The final release is expected on Tuesday, July 15, 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.2 depends on proper testing, so please lend a helping hand.
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.
WordPress 6.8.2 RC1 is scheduled on Tuesday 8, 2025.
Discussions 💬
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.
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.
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.
Over 15 small pull requests have been submitted under #63268, addressing code quality issues revealed by PHPStan. While a few contributors have been handling most of the reviews and commits, additional committers are invited to help reduce the workload. Coordination has so far been informal, with contributors commenting on tickets and pull requests to avoid overlap.
PHPUnit Test Suite Updates
Ongoing work on #53010 (namespacing test classes) and #62004 (updating for PHPUnit 10–12 compatibility) aims to modernize the test suite. These tasks are considered related to the ongoing PHPStan efforts. A suggestion was made to form a dedicated team to accelerate progress, though the main blockerblockerA bug which is so severe that it blocks a release. remains limited commit time and unresolved technical feedback.
PHPStan Integration into CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.
A proposal is in progress to formally integrate PHPStan into the Core test suite. Current efforts are manual and 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.-based. The upcoming proposal will aim to provide a sustainable and automated approach for ongoing code analysis.
MultisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site Privacy Tools and Feature PluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. Consideration
#43738 suggests extending personal data export/delete tools to support networknetwork(versus site, blog)-wide functionality. Discussion focused on whether the scope of the enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. justifies building a feature plugin. While the feature could be useful for multisite operators, it was noted that it does not address a critical GDPR requirement and may not meet the criteria for core inclusion. Prototyping the feature as 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 was recommended to assess usage and value.
Handling of .git-blame-ignore-revs
The .git-blame-ignore-revs file, used to exclude formatting-only commits from blame output, was discussed. While a few entries have been added manually, the file is not systematically maintained. Suggestions were made to either update it regularly or de-prioritize it due to limited practical impact.
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.
“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)
The full chat log is available beginning here on Slack.
WordPress Performance TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
@westonruter mentioned that the PR adding fetchpriority support for scripts (PR #8815) needs additional reviews if it is to land in the next minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.. But if WordPress 6.9 really is coming later this year then, the feature may be better suited as a major enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. for WordPress 6.9.
@flixos90 suggested that if WordPress 6.9 is going to be released this year, ticketticketCreated for both bug reports and feature development on the bug tracker.#61734 should be moved from the 6.8.2 milestone to 6.9, as there would no longer be a reason to allow enhancements in a minor release.
@westonruter noted that he added this topic to the agenda for the 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 later that day, asking whether the temporary relaxation of the minor release policy should be reconsidered if WordPress 6.9 is happening this year.
@flixos90 emphasized the need to start triaging tickets targeted for WordPress 6.9, noting many lack assigned owners or updates. Prompt action was encouraged to ensure timely progress.
@rollybueno raised questions regarding caching improvements for the ticket #63045.
@flixos90 acknowledged the point about using more readable cache keys but noted that this would break a convention used consistently throughout WordPress Core. He suggested that this requires further discussion to decide if breaking that convention is worthwhile and, if so, whether other cache keys across Core should also be updated for consistency.
Performance Lab 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 (and other performance plugins)
@flixos90 shared that he addressed feedback on View Transitions PR #2037, and it is now ready for another round of review.
He also announced plans for a new release of the View Transitions plugin soon, highlighting several significant enhancements and 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. fixes currently pending in open PRs.
@mukesh27 shared an update regarding the Auto Sizes plugin, confirming successful smoke testing and announcing the release of Auto Sizes version 1.5.0, which improves calculation of image sizes in nested blocks such as Group and Columns.
Open Floor
@b1ink0 asked for volunteers to lead the upcoming Performance Bug Scrub scheduled for July 8, 2025. Interested contributors were invited to sign up on the schedule spreadsheet.
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.
From @sirlouen – Should this ticket https://core.trac.wordpress.org/ticket/43738 be considered a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.? It might be too big for a report, but small for a feature plugin. Is it worth the effort? Discussion appreciated.
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.
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.
You must be logged in to post a comment.