WordPress 6.8.1 Release Schedule

Since WordPress 6.8 was released last week, contributors have kept a close eye on incoming reports to the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Support Forums, TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., and the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. The volume and severityseverity The seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs. of tickets mean that the maintenance release should be prepared perspicaciously.

Schedule

Date/TimeEvent
Tuesday, April 22, 2025Continued triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., testing, and committing/backporting fixes.
April 24, 2025 at 18:00 UTCBug Scrub. WordPress 6.8.2 Milestone will be opened, and some tickets may be punted.
Friday, April 25, 2025 at 15:00 UTCBug Scrub.
Monday, April 28, 2025 at TBA UTCWordPress 6.8.1 RC1
Wednesday, April 30, 2025 at TBAWordPress 6.8.1 General Release

Specific times for RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). and General release will be announced in the 6.8 Release Leads room and will be based on availability of individuals helping with the release.

Targeted Fixes

The following are the high priority items that cumulatively make a minor releaseMinor Release A 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. necessary:

WordPress 6.8.1 is intended as a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fix only maintenance release. Other tickets besides the major ones above will be included provided they are issues introduced during the 6.8 cycle or intentionally deferred at the end of the 6.8 cycle. You can follow trac report 4 or the 6.8.x editor tasks board for other fixes.

Get Involved with 6.8.1

Bug Scrubs will happen in the #core room during the times posted above. Each of the open tickets is going to require development work along with testing and review. You can also run your own scrubs to help ensure that all of the correct tickets are fixed in this release. Additionally, some locales have strings in 6.8 in need of translation.

General coordination for the release will happen in the #6-8-release-leads channel and decisions around code for the release will be made in the #core room.

Props to @jeffpaul, @audrasjb, @joemcgill for assistance with this post.

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

Dev Chat Agenda – April 23, 2025

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

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

Additional items will be referred to in the various curated agenda sections below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda.

Announcements 📢

Worth saying once more! WordPress 6.8 “Cecil” is now available! 🐣

WordPress 6.8 was released as scheduled and it was named after the legendary jazz pianist Cecil Taylor.

Forthcoming releases 🚀

WordPress 6.8.1

@michelleames posted a Call for 6.8.x Release Managers. Getting involved with minor releases is a great way to start being more active in the release process. Highly recommended!

A calendar with bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs will be posted soon.

Highlighted posts ✨

Read about the WordPress 6.8 performance improvements.

Discussions 💬

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

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.

Performance Chat Summary: 22 April 2025

The full chat log is available beginning here on Slack.

WordPress Performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets

Performance Lab PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (and other performance plugins)

  • No immediate updates or blockers were reported for the Performance Lab plugin suite.
  • @flixos90 shared that work is beginning on a new View Transitions feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. (issue #1963). This plugin aims to provide a WordPress-specific APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. for enabling cross-document view transitions.
    • Development will start with a few experimental PRs, similar to the approach taken with the Web Worker Offloading plugin. A public release will only happen once an MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia is ready.
    • For those curious about the planned approach, @flixos90 pointed to an experimental PR opened against CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.: wordpress-develop#8370, which will serve as the basis before being ported over to plugin form.

Open Floor

  • @flixos90 removed the milestone due dates from the performance plugin repo, following the team’s decision to move to an on-demand release schedule. Due dates will now be set only when a specific plugin release is planned.
  • @flixos90 shared an adapted GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions workflow originally created by @shyamgadde to bump the “Tested up to” version in readme.txt without triggering a full deployment. The updated version works for single-plugin repos and can be reused by most plugins on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. Example: bump-tested-up-to-dotorg.yml
    • @flixos90 is planning to write a blogblog (versus network, site) post to promote the workflow.

Our next chat will be held on Tuesday, May 6, 2025 at 15:00 UTC in the #core-performance channel in Slack.

#core-performance, #hosting, #performance, #performance-chat, #summary

Summary, Dev Chat, Apr 17, 2025

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @audrasjb. 🔗 Agenda post.

Announcements 📢

Forthcoming releases 🚀

WordPress 6.8.1

@jorbin proposed to lead the next minor releaseMinor Release A 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. and to host a first bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub right after the devchat.

There has been discussion about the need for a WordPress 6.8 retrospective post. Several people have pointed out the lack of interest of this kind of initiative in recent releases. Members of the 6.8 release squad are still welcome to share their thoughts. @jeffpaul pointed out that the goal is to find ways to ensure the next release cycle is easier than the last: What should be stopped (because it doesn’t help); what should the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team start doing (because it would be helpful); what should be changed (because iterating would be better). Ideally the release squad could put together a Make/Core blogpost and invite people to comment to share their thoughts.

Discussion about the WordPress 6.8.x cycle

With no other major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. scheduled in 2025, 6.8.x is going to be a long cycle, comparable to cycle 4.9.x.

@jeffpaul and @michelleames published a Make/Core post to gather nominations for folks to help lead the 6.8.x minors.

@jeffpaul: “If folks find something and are not certain if it should be part of 6.8.1 (or any future minor release), then please drop a link in #6-8-release-leads […] to help further triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors..”

@audrasjb asked whether the Core team should open milestones 6.8.2 and 6.8.3 on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., but @jorbin pointed out that it’s better to avoid having multiple milestones open for minors except when the current one is on the RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). step.

@joemcgill suggested that once any immediate issues that need to ship in a 6.8.1 release are addressed, the Core team could have a broader conversation about how they want to operate for the rest of the year, given that only minor releases are expected. His preference would be to identify a few volunteers to put together a proposal that we can get feedback on before finalizing the process, with a few things we need to consider: How does the ongoing development of JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. package in the GB pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party affect how the Core team plan minor release updates, etc. ; How much change do the Core team allow in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. during this period, given that large changes make it more difficult to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. fixes to the 6.8 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". ; What types of tickets are “allowed” to be shipped in a minor over the rest of the year, since no more major releases is expected this year.

@jeffpaul pointed out that the Core team had a decent precedent (4.9.6, with privacy features) that expanded what can happen in minors. If there are ways to expand beyond that that won’t break things (e.g. updater), then let’s explore those but there may still be relatively hard constraints.

A minor release is intended for bugfixes and enhancements that do not add new deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. files and are at the discretion of the release leadRelease Lead The community member ultimately responsible for the Release. with suggestions/input from component maintainers and committers.

Source: Releasing Minor Versions in the Core Handbook

@joedolson suggested the team should consider that the first couple point releases could be reserved to new issues only, the same as most minor releases, and once those are settled, the scope of minors can start to be expanded. But the drift between trunk and minors could be difficult to manage, especially if the scope of what can go into a minor is too restrictive. @audrasjb confirmed that it’s exactly what was done during cycle 4.9.x: the cycle started with bug fixes introduced in version 4.9, the the Core team started to introduce enhancements with 4.9.5 and all along the rest of the cycle.

For now, there is a hard rule, though: No new file can be introduced in a minor release.

@jorbin encouraged Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. to publish their own ideas on their own blogs so then all the ideas can be shared and the Core team could come up with a plan.

@joemcgill volunteered to to coordinate a proposal for Make/Core, unless more guidance is given. He would welcome ideas that folks want to share (please feel free to reach out with him).

Open Floor 💬

Core Trac Workflow Keywords Issue

The discussion concerns an issue raised by @sirlouen on MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. about a conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. between the "needs-testing" and "needs-testing-info" keywords in search results on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Meta Trac (Ticketticket Created for both bug reports and feature development on the bug tracker. 7935). This problem makes reports, especially for the testing team, more difficult and leads to incorrect information. Two solutions were suggested: renaming one of the keywords or improving the search algorithm. The conversation continues in the Trac comments.

@sirlouen wanted to run a poll/survey to close this ticket in the next Core Test meeting (23rd April), but he would like to have the consensus (and the awareness) from the core team that this is going to happen, and It’s going to bring a change in core. This item is scheduled for discussion during the next dev chat.

#6-8, #core, #dev-chat, #summary

Call for 6.8.x Release Managers

WordPress 6.8.0 was released April 15,2025. Following this release, work will continue with regular, planned maintenance or minor releases. While the work of a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. team includes people filling approximately 16 different positions, maintenance release teams generally are considerably smaller, often 1-3 people. Minor releaseMinor Release A 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. managers are responsible for:

  • Triaging bugs in coordination with committers and component maintainers.
  • Drafting announcements for the release.
  • Preparing for and running release day activities.
  • Updating the documentation on minor releases so that it gets better each time.

Members of the 6.8 release cohort are encouraged to stay on as release managers for maintenance releases, but it is not required to have been on a major release squad in order to be on a minor release team.

Since 6.9 is not currently scheduled until 2026, we are not asking folks to lead minor releases for 9+ months. Rather, we are looking for folks who could help lead for shorter periods of time, like 3 months. If folks are able to lead for a longer period of time, that’s wonderful, but we expect to rotate folks in and out every 3 months so that no single person has to shoulder the work through to the next major release.

If you are interested in volunteering to be a release manager for the 6.8 maintenance releases, please comment on this post.

Thanks to @jeffpaul, @jorbin, @joedolson for reviewing this post before publication.

WP_Query changes in WordPress 6.8

WordPress 6.8 includes some caching optimizations that may affect themes and plugins using the WP_Query::get() method and the WP_Query::$query_vars property.

In #59516, WP_Query was optimized to improve cache hits for queries with equivalent arguments.

This enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. improves performance for sites that run equivalent queries with a different order of arguments. The impact will be most noticeable on sites without a persistent cache, as these equivalent queries would run multiple times on a single page request, whereas they will now run once.

As such theme and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors making use of filters within WP_Query (source code: GitHub, trac) are recommended to check their code for compatibility with WordPress 6.8. An example of code that would be affected by this is using equality to check for the contents of an array:

$query = new WP_Query( array( 'post_type' => array( 'post', 'page' ) ) );

add_filter( 'posts_where', function ( $where, $query ) {
        // True in WordPress 6.7, false in WordPress 6.8
        // WordPress 6.7 returns array( 'post', 'page' )
        // WordPress 6.8 returns array( 'page', 'post' )
        if ( array( 'post', 'page' ) === $query->get( 'post_type' ) ) {
                // Modify WHERE clause.
        }

        return $where;
}, 10, 2 );

When comparing the contents of two arrays for equivalence, it is recommended to use the code empty( array_diff( /* arrays */ ) ) rather than equality comparisons. See this example for a demonstration.

Standardized arguments.

The most common example of where these changes will improve performance is when querying multiple post types:

$q1 = new WP_Query( [ 'post_type' => [ 'post', 'page' ] ] );
$q2 = new WP_Query( [ 'post_type' => [ 'page', 'post'] ] );
$q3 = new WP_Query( [ 'post_type' => [ 'page', 'post', 'post' ] ] );

In WordPress 6.7 and earlier, these queries would each result in database queries as they were not seen as equivalent in the resulting database query and cache key.

To standardize equivalent queries, WP_Query now sorts and type casts arguments as appropriate. For each of the queries above the post types are sorted alphabetically and any duplicates removed. In WordPress 6.8 the ::get() method and ::$query_vars property will differ from the arguments passed to $q1 and $q3:

$q1->get( 'post_type' ) // returns [ 'page', 'post' ]
$q2->get( 'post_type' ) // returns [ 'page', 'post' ]
$q3->get( 'post_type' ) // returns [ 'page', 'post' ]

$q1->query_vars['post_type'] === [ 'page', 'post' ]
$q2->query_vars['post_type'] === [ 'page', 'post' ]
$q3->query_vars['post_type'] === [ 'page', 'post' ]

For items that accept values as either an integer or a string, these have been sorted and typecast as appropriate, for example author__not_in => [ '2', '1' ] becomes author__not_in => [ 1, 2 ]. A full list of affected arguments can be found in the commit message [59766].

Due to differences in the code paths when the post type and status are passed as a string, these are not type cast to an array 

$q4 = new WP_Query( [ 'post_type' => 'post' ] );
$q4->get( 'post_type' ) // returns 'post'

These changes are part of an ongoing effort to improve the performance of WordPress. The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team are monitoring the changes for any major issues that may occur, see #63255

Props @joemcgill and @jorbin for their review of this post.

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

X-post: A New Cadence for WordPress Core

X-comment from +make.wordpress.org/project: Comment on A New Cadence for WordPress Core

WordPress 6.8 performance improvements

This post is the latest in a series of updates focused on the performance improvements of major releases (see 6.76.66.56.46.3, and 6.2).

WordPress 6.8, “Cecil” is the first and likely only major version WordPress released in 2025. It includes numerous significant performance improvements to the editing and browsing experience, spearheaded by the speculative loading feature. The release pays special attention to performance in the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, frontend interactivity, block type registration, and query caching.

This post summarizes the performance changes since the 6.7 release, both in terms of enhancements and concrete metrics. For a comprehensive overview of new features and enhancements beyond just performance, please explore the WordPress 6.8 Field Guide.

Key improvements

In total, there were 24 performance related improvements included in this release: 1 feature, 14 enhancements, and 9 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes. This section summarizes a few highlights among them.

Speculative loading for near-instance page loads

In #62503, the speculative loading feature was added. It can notably improve the Largest Contentful Paint (LCP) performance and, depending on the configuration, lead to truly instant page loads. To accomplish this, the feature uses the Speculation Rules API, a web platform APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. that allows defining rules for which kinds of URLs to prefetch or prerender, and how eagerly speculative loading should occur. By default, URLs are prefetched when the user interacts with a link to them (“conservative” eagerness). For an additional performance boost, up to the instant page loads, the configuration can be adjusted through filters or by using the canonical Speculative Loading plugin.

Please refer to the Speculative Loading dev note for details on the feature’s behavior and how to customize it.

Asynchronous Interactivity API event listeners by default for smoother interactions

In GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ issue #64944, the foundation was set for asynchronous event listeners by default for the Interactivity API. Running event listener logic asynchronously helps avoid long tasks in the browser, which can notably improve the Interaction to Next Paint (INP) performance and thus ensure the website responds to user interactions without any delays. WordPress 6.8 does not actually implement this change just yet, but it prepares for the change to launch in a following release by introducing a withSyncEvent() utility function that needs to be used by any Interactivity API store action that is attached to an event and needs to run synchronously.

Please refer to the Interactivity API best practices dev note for details on how to use withSyncEvent() and how to avoid deprecation warnings.

Smarter WP_Query cache key generation for increased cache hit chance

In #59516, the logic around generating a cache key for post queries via WP_Query was improved to increase the chance for a cache hit. In other words, it reduces the need to run SQL queries for queries that are sure to yield the same results even though their query variables may technically differ. In particular, any query variables that expect arrays in which the order of items does not matter are now being normalized prior to generating the cache key.

count_user_posts() caching to avoid potentially slow queries

In #39242, caching was added to the count_user_posts() function to avoid a SQL query that in certain setups could previously occur on every page load. On sites with many registered users, this query can be slow, which is why caching its results can lead to a notable server-side performance boost. While this primarily applies to WP Adminadmin (and super admin), certain themes also call this function, so it can have a notable impact on the website’s frontend performance as well.

get_option() performance regressionregression A 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. from WordPress 6.4 identified and addressed

In #62692, a performance regression due to a problem introduced in WordPress 6.4 in the get_option() function was identified and fixed. The lookup of a non-existent option was leading to an unnecessary wp_cache_get() call that would always evaluate to false. For large WordPress sites, this could significantly increase the load on caching servers. The fix ensures the unnecessary wp_cache_get() call no longer happens, leading to a constant number of wp_cache_get() calls per non-existent option, even if it is requested many times.

Performance metrics

The performance benchmarks for the WordPress 6.8 release show a small regression in both server-side performance and client-side performance across block themes and classic themes.

The median Largest Contentful Paint (LCP) time, which is the metric most representative of the overall performance, increased by 3.40 ms (1.76%) for Twenty Twenty-One, 2.65 ms (1.92%) for Twenty Twenty-Three, and 10.05 ms (1.73%) for Twenty Twenty-Five. The increased time signifies a decrease in performance, albeit a small one.

While it is natural that every new feature or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. can incur a performance cost, ideally the regression needs to be investigated for whether there is a specific change that is primarily responsible for it or whether it is simply due to the accumulation of several new features and enhancements with a minor performance cost. At first glance, it might be the latter because a similar degree of regression can be noted more or less across all metrics.

It is worth noting that the performance metrics do not benefit from the new speculative loading feature, since it only helps with performance when navigating from one URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org of the site to another URL of the site. Because the benchmarks rely on individual requests to specific URLs though, speculative loading does not trigger. In other words, it is fair to assume that the actual performance impact of WordPress 6.8 for users navigating through a WordPress site is more positive than the benchmarks indicate.

How release performance is measured

The performance measurements used for the overview are based on benchmarks conducted using an automated workflow on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ action runners. Benchmarks were taken from the homepage of the Twenty Twenty-One, Twenty Twenty-Three, and Twenty Twenty-Five themes, comparing WordPress 6.8-RC3 with WordPress 6.7.2, which was the latest version of 6.7 available as of the 6.8 release.

Under the hood, the automated workflow collects performance metrics from 100 runs for both Web Vitals and Server Timing metrics using CLI scripts from the WPP Research repo.

Full benchmark data

What’s next?

Once WordPress 6.8 has been used for at least a month, additional research should be conducted to assess its performance impact in the field by using CrUX data. This will clarify to what extent the regression shown by the benchmarks is an actual reason to worry or not. Additionally, the performance impact of the speculative loading feature should be assessed as part of that, to see how much it influences LCP in practice.

Other than that, the focus of the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team remains to iterate on the performance of WordPress by identifying areas of improvement and addressing them. With the reduced major release cadence following the 6.8 release, it may be even more important to focus on all the little things that can be done to improve performance—they add up. Minor releases will continue to ship as necessary, and as mentioned in the linked post there will be a more relaxed barrier for inclusion of enhancements. In other words, WordPress Core continues to provide lots of opportunities for improving its performance.

Props @joemcgill for review and proofreading.

#6-8, #core, #core-performance, #performance

Dev Chat Agenda – April 17, 2025

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

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

Additional items will be referred to in the various curated agenda sections below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda.

Announcements 📢

WordPress 6.8 “Cecil” is now available! 🐣

WordPress 6.8 was released as scheduled and it was named after the legendary jazz pianist Cecil Taylor.

For now, 6.8 is identified as the last major release of the year.

Forthcoming releases 🚀

WordPress 6.8.1

@jorbin proposed to lead the next minor releaseMinor Release A 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. and to host a first bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub right after the devchat.

WordPress 6.9

No ETA at the moment.

Highlighted posts ✨

Discussions 💬

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

  • WordPress 6.8.1:
    • Is there any 6.8 release leadRelease Lead The community member ultimately responsible for the Release. who want to help releasing 6.8.1? Any new person who want to be onboarded on this first post-6.8 release?
  • WordPress 6.8.x:
    • @audrasjb suggests a discussion about how to handle tickets currently located in milestone 6.9 and how to dispatch them (when needed) in the next 6.8.x minor releases: should bug gardeners and component maintainers move them to minor releases related milestones? Should we have dedicated bug scrubs? Should we open 6.8.2 and 6.8.3 milestones right now?
    • Given the 6.8.x cycle is going to be quite long, should we publish a call for release leads for the next coming months?
  • Handbook improvements:
  • Minor topic: Time permitting, @audrasjb would like to start a discussion about how contributions are taken into account.

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.

WordPress 6.8 Release Day Process

Preparation for the WordPress 6.8 release is underway.

This post shares the release process, including the timeline and how you can help.

Release Timeline Overview


24-Hour Code Freeze

A mandatory 24-hour code freeze will be in effect for the 6.8 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". after the Dry Run finishes on April 14th.

What does this mean?

No source code for 6.8.0 (i.e., in the 6.8 branch) can be changed during these 24 hours.

What happens if a critical bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. is reported during this period?

The release squad will meet with committers and maintainers to determine if the issue is a blockerblocker A bug which is so severe that it blocks a release..

  • If yes, another RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). release happens, and the release process restarts (meaning the Dry Run repeats, and then the 24-hour code freeze clock restarts).
  • If not, then the bug is targeted for 6.8.1.

The Release Party

The WordPress 6.8 Release Party will start on Tuesday, April 15, 2025 at 15:00 UTC in the #core Slack channel.

The release party walks through the steps in the Major Version Release process if you want to follow along.

Please note: releasing a major version requires more time than releasing a betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. or release candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)..  There are more steps in the process. If any last-minute issues need addressing, those issues will take more time, as well.

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the available server configurations. If you have any of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. will also need testing.

You can start this early by running the WordPress 6.8 RC4 packages, which are built using the same method as the final packages.

During the release party, you will get access to several ways to help test the release package.

Tips on What to Test

In particular, testing the following types of installs and updates would be much appreciated:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ or one-click installers.
  • Test upgrading from various versions.
  • Remove the wp-config.php file and test a fresh install.
  • Test single site and multisitemultisite Used 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/networknetwork (versus site, blog) (both subdirectory and subdomain) installations.
  • Does it upgrade correctly?  Are the files listed in $_old_files removed when you upgrade?
  • Does multisite upgrade properly?

Testing the following user flows on both desktop and mobile would be great to validate each function as expected:

  • Publish a post, including a variety of different blocks.
  • Comment on the post.
  • Install a new pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme, or upgrade an existing one.
  • Change the site language.
  • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

For a more in-depth list of what features to test, make sure to check the Help Test WordPress 6.8 post.

Props to the following for help contributing to this post: @michelleames, @marybaum, @joemcgill, @desrosj.

#6-8, #development, #dry-run-2, #releases