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.
Hosting companies and interested contributors are encouraged to join the distributed testing program where anyone can get involved with and report the results of the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. automated test suite back to WordPress.
WordPress 6.4 performance improvements (to be added to the Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.).
Update to the core commit message format: It has been updated to take into account backportbackportA 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. and follow up commits. There is also a change on where “props” is used in the commit message.
@webcommsat emphasized that developers with 6.4 knowledge can really help with reviews and contributions toward End User docs. The sooner the documentation is published, the sooner it can benefit the community.
And some items from last week’s cancelled chat to touch on:
A proposed schedule for 2024 major releases has been shared by @chanthaboune, proposing dates for 6.5, 6.6, and 6.7. Please share your thoughts on timing, focus, or anything else relates to these releases in the post comments.
@jeffpaul called on potential 6.5/6.6/6.7 leads to share their thoughts on this post.
Accessibility improvements in the 6.4 release: Check out this rundown of a11yAccessibilityAccessibility (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) items addressed in 6.4.
Shareable performance testing utils: Join the discussion to explore ways that projects can incorporate performance testing as part of their development workflow.
And finally, some reminders ⏲️:
Call for 6.4.x Release Managers: Work on improving 6.4 continues after the main release, so please consider joining the 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. squad to help keep 6.4 healthy.
Call for volunteers to help with 6.4 end-user documentation: The Docs team is looking for volunteers to revise end-user docs (HelpHub) for 6.4. Check out the post and learn how to pitch in! Wait…did I mention this already? Yep — but it’s so important for our user community ❤️.
Release Updates
Next minor release: 6.4.2
@jeffpaul noted that if minor release squad volunteers can be found soon, that there’s a possibility of shipping a 6.4.2 minor release before year’s end. He requested feedback on whether there are any urgent/important items that need to be addressed soon.
@jorbin has been watching the (6.4) minor release issues report, and noted that #59847 seems the most urgent. He also pointed out nice-to-have editor package backports in #59828. If volunteers can be found to support the release, then he suggested a target of the week of November 27, 2023.
@joemcgill noted that #59847 is nearly ready, and requested feedback on the related PR.
👉🏻 Volunteers who can help with the 6.4.2 minor release (and determine timing) should drop a note in #6-4-release-leads.
Next 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.: 6.5
The development cycle page has been created. It will be populated after discussing release timings and the finalization of the squad.
Are you able to help with future 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. scrubs? Check out the 6.5 scrub schedule.
@jorbin asked that 6.5 ticketticketCreated for both bug reports and feature development on the bug tracker. scrub participants keep an eye out for regressions that should be moved to the 6.4.2 milestone, to get fixes delivered to users more quickly.
@webcommsat shared a link to the November 14 scrub for anyone looking at tickets async, and called on contributors to help with patches and writing of tests. 🙏🏻
@jeffpaul expressed worry about losing touch with 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/ development without regular meetings and sought alternative ways to stay updated. @jorbin suggested incorporating editor updates into existing meetings, particularly emphasizing involvement from major release editor leads.
@webcommsat highlighted the usefulness of core-editor summaries and proposed integrating regular updates into the dev chat agenda. @ironprogrammer raised the question of where the editor summary would originate if the meetings themselves were cancelled. @jeffpaul suggested obtaining editor updates during dev chat to ensure communication of updates and blockers across the project.
The idea of carving out an official “editor updates” section in dev chat was considered, and @jorbin suggested seeking volunteers from the #core-editor channel to participate in the chat. @annezazu volunteered to take on the responsibility and discussed potential ways to share editor updates, including during the meeting or through agenda posts. The need for asynchronous options, given different time zones, was acknowledged.
@webcommsat suggested having a dedicated section for editor updates on the dev chat agenda post, and plan for asynchronous sharing. @annezazu volunteered to make the meetings and incorporate asynchronous sharing, considering her near term availability across time zones. The importance of avoiding disruptions during meetings was discussed, as was the possibility of maintaining #core-editor office hours for specific questions related to the editor.
2024 Core Team Reps Nominations
@webcommsat gave a reminder for #core contributors to have a look at the draft post: Nominations for Core Team Reps: 2024 Edition. The dates/timing may need revising, and team reps are looking into the possibility of having the voting poll embedded into the post to make it easier to vote. Please share your feedback in #core and CC @webcommsat and @hellofromtonya.
WordPress 6.4 Retrospective
@cbringmann shared WordPress 6.4 Retrospective, and asked that anyone who has contributed to the release to reflect and share their thoughts on the release process (instructions in the post). A follow-up post will be published in December.
Writers are needed for the remainder of the items on the to-do list. Call to be shared in dev chat when possible. Wider calls to encourage people to add to the relevant GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue if they can assist with collaborating on these items.
At the moment, the queue for items for discussion or topics for approval is empty.
@greenshady to add some new topics for next month’s meeting.
@webcommsat: From early signs of what could be in 6.5, I think there will be quite a few use case blogs to come out of there in the future.
@milana_cap: to propose a few 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/ topics.
@marybaum: potentially one on using the post-content 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. inside the Cover block, and a topic related to a block theme.
@ogleckler: proposed a topic on design in Figma for blocks. Discussion followed in the meeting: @webcomms suggested sharing the idea with the Design team and with the release contributors who worked with Figma for potential interest in scoping/ key inclusions, or to take it up to write. Strong interest in the editorial group about a post on designing a block theme in Figma. New issue created for the Dev Blogblog(versus network, site) to take this forward.
@webcommsat proposed that in general, adding ideas for topics to the board makes it:
easier to raise awareness and target potential contributors
adding a basic scope /inclusions from discussions in the editorial group
there have been a couple of discussions in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and documentation during the release journey about use case of features. Some of these would be potentially good dev blogs. Helping scope out some of these topics can help people commit to taking them on or to better understand the next steps. This has been seen with other new topic proposals
agreement from the group on this and promoting potential contributors to add ideas to the board
@webcommsat with @codente and @nalininonstopnewsuk have been marking items up from the 6.4 release documentation tracker where there has been some interest already in writing about particular items and will encourage these ideas for the Dev Blog board.
Open floor
1)@greenshady raised a conversation about resolving how writers upload images to their draft posts.
Issue: Slack convo. In this instance, the published post was missing two images. They later had to be pulled from the original Google Doc and the post updated. Two older posts needed the same solution too where an image URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org was added which was no longer valid.
Solution: make sure folks are uploading images to the Developer Blog WordPress install and not hotlinking from Google Docs or elsewhere. I updated two older posts in the past week where this was done and the image URL was no longer valid.
Further questions: any guidance needed on checking images uploaded have been checked for virus/malware? The system does not allow upload of svg files for this reason.
Actions:
add further instruction in the contributing guide for writers, the checklist on GitHub, and to prompt checks when they are ready for the post to be edited. @greenshady to add a ticketticketCreated for both bug reports and feature development on the bug tracker. for these additions.
@webcommsat requested to add to the checklist/ guide for images to be given a useful name and alt text to be added when uploaded. All agreed and a sub section on images suggested, and to include guidance on image sizes, image naming and alt attributes.
2) Discussion around using using the /blog URL instead of /news for the Dev Blog
Clarification shared that this would not change the URL, just add a redirect from /news to /blog.
@ndiego shared: The reasoning behind using /blog is to match the brand name, “WordPress Developer Blog”. This would be too build on the branding cultivated in the past year around this name.
Discussion points:
only news items on the blog are the round-ups
concern that ‘blog’ url might give an impression that it is personal opinion rather than posts from the project WordPress. Alternative suggestions for its name were suggested, including “guides”, “tutorials”, “guidelines”, “journal”, “writings”, “Developments”, but not felt to cover the breadth of content, would need a rebranding exercise, and would mean potential duplication/ overlap with Learn WP content. Suggested a way of addressing reservations about url ‘blog’ could be to add further clarification in the purpose and writing guidelines so that it was clear to potential writers that articles were not personal blogs.
@webcommsat highlighted that there is a wider discussion to be continued on overlap and working alongside Learn WordPress in both directions.
@ndiego clarified the specific aim of the redirect question is to help people find the Developer Blog not to change or widen its current scope. He confirmed it is about search and helping people find it. There are people typing in developer.wordpress.org/blog and wonder why it didn’t go to the WordPress Developer Blog.
@greenshady raised that /news was not the preferred option originally to match the scope, but there was an issue early on where there was a potential plan to reserve /blog . The option to use /blog is now possible from the information shared by Nick.
Solution proposed:
to go ahead with the redirect and there by keep both /news and /blog in use, subject to further discussion with @bph on her return
relook at the published purpose/ guidelines for writers to make sure there is no potential misunderstanding for submissions/ writing. This is turn would save time for this group, writers and reviewers. Add a list of the type of articles that appear on the blog to assist contributors to know how to target pitches, articles and language, as well as helping give some next steps for new writers.
3) Trying to avoid duplications of series names in the Developer Blog and other parts of the project, e.g. Learn WP @webcommsat highlighted this topic to avoid confusion from both audience and search engine perspectives, especially where items are not cross-linked.
For example, there is a “What’s New for Developers” series on the Blog, so it would be better to avoid having the exact replica title in other public-facing resources from the project. Where one communication is a follow-up to an existing one elsewhere in the project, it should reference it to help people find similar resources and help their learning journey. There may need to be some manual proactive cross-linking.
Solution proposed:
cross-linking to be encouraged, and this can help for search in terms of authenticity and credibility of information about WordPress, and in terms of readers’ journeys.
avoiding exact duplication or too similar naming of titles. Specific titles that cross link should be less likely to cause confusion, eg Hallway hangout – What’s New for Developers in 6.4 covered topics from the article series on the Blog, and cross-referenced in the event itself. Suggested that posts about a forthcoming event or write-ups would benefit the user / attendee with cross-referencing.
the discussion also highlighted how more synchronization between Learn WP and the Dev Blog might be helpful
a recommendation to add excerptExcerptAn excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. to posts, which makes it so much easier for users, and shorter search result descriptions in the P2P2A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. and the internet too.
This is a summary of a Hallway Hangout that was wrangled in the #accessibility channel after a prior hallway hangout on improving 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) in the Site Editor and took the new form of a concrete working session to address a specific problem. It was first announced on October 1st and was open to all.
To kick off, Joe asked Alex to talk through the current pain points and differences between modes. As Alex said, navigation mode is a hackedhacked together feature. The biggest problem we have, the navigation mode is a dynamically updating button. Everytime you press your arrow key or tab key when you’re in navigation mode, it dynamically re-renders. This is a challenging problem to handle with screen readers because it’ll ignore this. For Windows, there’s also a longstanding issue where the arrow keys don’t actually send the keyboard events through the browser so tab is the only viable key. Conversely, List View is much simpler in the way you can navigate with keys and it’s wrapped in a navigation role. You are able to expand rows, have control over what you’re looking at, etc. Another current problem with navigation mode, it’s not entirely clear when there are inner blocks. Alex started to work on this but stopped to focus on list view.
What are the consequences if we stripped out navigation mode and used list view as the primary way of browsing through blocks?
To date, there has been no modal, tips, etc for keyboard users in the editor. People who are used to this would have no idea it has changed and we need a way to communicate that change, perhaps using a similar approach to the change in template parts to the patterns section.
Andrea, who helped implement navigation mode, offered some historical context. He shared that if we are going to use navigation mode, we’re going to reintroduce a major issue that existed before introducing the two modes. Imagine that a post contains dozens of blocks. If you want to navigate these blocks in the post content area with the tab key, you are going to have to go through all of the dozens of blocks including the interface of each 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. (dozens of tab stops). Nav mode was originally meant to reduce the number of tab stops when navigating through the blocks in a way that each block was only one tab stop rather than multiple then pressing enter gives the ability to switch the block to edit mode where you can navigate inside the block. This was the original implementation and it made sense when there were no inner blocks.
Joe noted that List View works the same way where you can go block to block. When you use the tab key you are going through all of these elements. However, there are still a lot fewer elements than going through the blocks themselves. We should be willing to compromise to some degree. Arrow key navigation in List View also does work. It’s 100% accessibility and there are a total of three tabbable elements in list view: tab panel, close button, and list view area itself.
Alex would like to find a better way to manage focus between block editor and block 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. but that’s a broader discussion. Jerry and Alex have worked on this but it’s a long battle.
Trying List View + Focus Mode for container blocks as an experiment
Anne pitched trying getting rid of navigation mode and use list view + focus mode as an experiment 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/. We could then do a call for testing and get a sense of what the experience might be like more practically. Folks were very much onboard with trying this out, especially since in the long run this would reduce the number of mechanisms to maintain.
The question of how many people are used to using navigation mode came up though, especially since the feedback folks are worried about is more about non screen reader users. Anne is going to try to get some initial data from WordPress.comWordPress.comAn online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/.
Mobile concerns
Rich chimed in that the current primary use for that view is on mobile devices as this makes it easier to select child first nested blocks so it’s easy to tap onto. We never really got to the bottom of this on the call as we all pulled out our phones to investigate and couldn’t figure out how to even evoke the mode.
Locked blocks and inert
We discussed how to explain disabled blocks in List View which relates to a broader discussion on alternatives to inert. There’s no good way to explain to a blind user what a template looks like when editing a smaller portion like a page. Anne showed an option to toggle on/off a template preview when editing a page in the Site Editor and we discussed a few ways we could enhance that feature to save it as a preference/have it be persistent in some way.
Focus mode concerns
We discussed Focus Mode and adding it to Container Blocks. A big piece to figure out is how the back button works and ensuring it returns you to where you’d expect in the Site Editor experience.
Gutenberg as a framework concerns
Alex brought up an excellent point around Gutenberg being used as a framework, like with Blocks Everywhere, and how navigation mode is built into it as a package. We need to consider this in removing the navigation mode and it might be that it remains for third party usage.
Congratulations to all who helped make WordPress 6.4 available! Now that it has been successfully released, I invite all who contributed to reflect and share our thoughts on the release process to learn, iterate, and improve for future releases.
Anyone is welcome to participate in this retrospective, so please take a few moments to complete the form or leave public feedback in the comments below. The survey is not anonymous, allowing for outreach should further clarification be needed; please note that your email address will not be shared or used for any other purpose.
The form and comments will be open until November 30th, 2023, with anonymized results available in a follow-up post in December 2023.
Again, thank you for your contributions to 6.4 “Shirley,” and for taking the time to help make future releases even better!
@swissspidyTranslationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. performance:
Published blog post about merging the feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.
@flixos90 I updated https://github.com/WordPress/wordpress-develop/pull/5267 yesterday, which improves performance of parsing `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.` files on every page load for sites using a persistent object cache, and I then opened an equivalent 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/ PR https://github.com/WordPress/gutenberg/pull/56095 (since that change should be implemented and tested in Gutenberg first)
PR is ready for review! You can use either PR for testing (as they are the same) but the Gutenberg one is the one that needs to be prioritized
@joemcgill Work is ongoing on our Template Loading focus. The most important thing for this week is probably to address #59719, which will unblock several of the other pieces of work.
@joemcgill I’ve also been tracking a 6.4 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. that was related to our earlier server response time work #59847
JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. & CSSCSSCascading Style Sheets.
@flixos90 A few months ago, I had been exploring a PL module for the new Speculation Rules 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., which allows “speculative prerendering”. TL;DR when you hover over a link, it prerenders the relevant content under certain conditions so that when you actually click, the page loads instantly.
I yesterday updated the PR, which is still only a draft: https://github.com/WordPress/performance/pull/733 But there have been recent developments in the spec and it is likely going to be available in Chromium without requiring an Origin-Trial, at which point it may be worth advancing this further. Right now you can test it through the Origin-Trial if you like, instructions are on the PR.
I have also added a few new “learn more” resources to the PR description that may be worth reading to get familiar with the purpose and behavior of the API
@joemcgill I’m in the early stages of looking at how we can improve the way WP calculates the sizes attributes of images. I’m currently looking at whether we can add this information during 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. rendering, using the WP_HTML_Tag_Processor and the theme.json layout settings. I hope to have some ideas to share in the next few days.
@westonruter For image loading optimization, the pull request for the storage component is ready for review: https://github.com/WordPress/performance/pull/878 – next I’m working on the optimization piece to applied the stored page metrics that have been detected.
@swissspidy We‘re now measuring more stuff in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. performance tests, like localized setup and memory usage
@luisherranz I’d like to mention that @cbravobernal and I have started experimenting with possible APIs to support modules and import maps in WordPress.
We have started in Gutenberg, as we want to test them out in the frontend (with the Interactivity API) and the Editor (with the work @jsnajdr is doing on Block Lazy Loading).
The goals of this initiative and the report of our progress are here:
There are a couple of experiments already, and we plan to do a third one. It’d be great to have your feedback and insights
@flixos90 Great to see this move forward! Would you say the most useful way for us is to review the different PRs and their approaches? Are there other concrete questions where feedback is needed?
@luisherranz I’d say that for now, starting to get your opinion on those PRs or even the tracking issue would be great.
the distributed testing program where hosting companies or anyone can get involved with and report the results of the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. automated test suite back to WordPress.
WordPress 6.4 performance improvements (this will be added to the Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.). @swissspidy has also published his own post on how to get started with WordPress performance https://pascalbirchler.com/wordpress-performance-testing/
An update to the Field Guide with a new dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.: Main query loop handling for block themes in 6.4.
Post on an update to the core commit message format. It has been updated to take into account backportbackportA 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. and follow up commits. There is also a change on where ‘props’ is used in the commit message.
Reminder from last week’s schedule dev chat: (not all these may be featured in the dev chat on November 15 depending on time available).
A proposal for 2024 major release timings has been shared by @chanthaboune. This includes proposed dates for 6.5 to 6.7. Thoughts on timing, focus, or anything else relates to these releases can be added to the comments. In addition, depending on other items, the Dev Chat facilitator can give time during the meeting for a live discussion.
Call for 6.4x release managers – any update on any future 6.4.x or release manager/ team call can be shared during the meeting or added in the comments if the timing of the meeting is not suitable.
Forthcoming release updates
WordPress release: 6.4 – any issues
Reference information: – Field Guide for 6.4 – All Developer Notes relating to 6.4 can be found using this tag.
Next major WordPress release: 6.5
The development cycle page has been created. It will be populated post the discussion on release timings and the finalization of the squad.
Are you able to help with future 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. scrubs? The next bug scrubs post.
Bug scrub on November 14, 2023. The list of tickets in milestone by the scrub. Start of the scrub for those looking at tickets async.
Tickets or Components help requests
Please add any items for this part of the agenda to the comments – tickets for 6.5 will be prioritized. If you can not attend dev chat live, don’t worry, include a note and the facilitator can highlight a ticketticketCreated for both bug reports and feature development on the bug tracker. if needed.
Open floor
If you have any additional items to add to the agenda, please respond in the comments below to help the facilitator highlight them during the meeting.
This was due to be shared at last week’s dev chat. Bringing it again to November 15, 2023: Nominations for Core Team Reps: 2024 edition – @webcommsat to reshare the draft post and timings. To continue exploring and with 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. to embed a voting 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. within the post to make it easier for voting. Thanks to @ironprogrammer on testing and helping move this option forward, which may also assist other teams in the future.
This post will list 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. scrub sessions dedicated to move things forward towards 6.5. This post will be taken forward by the 6.5 release coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. leads once they are in place. This post is being published early to provide a place to list bug scrubs and raise greater awareness and time on tickets for future releases, some of which may be aimed at 6.5.
The full 6.5 Release Schedule will be populated as planning for the release progresses.
Everyone is welcome to join to help triage tickets, explore tickets to contribute to by creating patches, writing or conducting tests, providing code reviews, and more. Things to keep in mind:
all features and enhancements should be in the 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. before BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 and most bugs and all strings need to be there before 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)
If you are working on a 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., it is helpful if you can please plan your contribution to give enough time for other contributors to make suggestions, review and test.
Dates will be added as the development cycle progresses
Release Candidate Bug Scrubs (if needed)
Focus: issues reported from the previous 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)..
Dates will be added as the development cycle progresses
Check this schedule often, as it will change to reflect the latest information.
Regular component scrubs and triage sessions
For your reference, here are some of the recurring sessions:
Have a regular component scrub or triage session? PingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.”@audrasjb, @oglekler or @marybaum@webcommsat on Slack to have it added to this page.
You can start your own triage sessions
Decide what you want to work on
6.5 triage session are our priority and moving forward tickets which already are scheduled for the release is most needed task. If you want to lead some of them, they can be added on this schedule.
But if you are interested in particular component or user focus, for example to take care about RTL-tickets, this will be most welcome too.
Especially interested can be the session to scrub old tickets. We are continuously closing new tickets with the same topic in favor of existing ones and because these tickets are looking complicated just because they’re age not, so many contributors are eager to work on them, but there are actual treasures hidden among very difficult or tricky topics.
Ping@oglekler or one of the 2023 core team reps @hellofromtonya or @webcommsat on Slack with the day and time you’re considering as well as the report or tickets you want to scrub. Note: when the 6.5 core triage leads are confirmed, contacts in this section will be updated.
Useful reports and information
More will be added as the development cycle progresses
Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the core handbook.
Thanks to @oglekler for helping to put together this agenda and peer review, and to previous contributors to this to release bug scrub posts for the information reused in this post.
Here is the agenda for this week’s performance team meeting scheduled for Nov 14, 2023 at 16:00 UTC. If you have any topics you’d like to add to this agenda, please add them in the comments below.
WordPress 6.4 is the third 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. of the year that delivers a better user experience to site visitors by improving performance of the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. software. This version improves server response time by ~4% over version 6.3.2. This, combined with additional frontend optimizations, leads to improvements to Largest Contentful Paint (LCP)—an important Core Web Vital. For example, Twenty Twenty-One (a classic theme) shows an improvement of ~4% for LCP and Twenty Twenty-Three (a 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. theme) shows a ~9% LCP improvement when run on WordPress 6.4 compared with 6.3.2 based on benchmarks conducted by the WordPress Performance team.
This release caps off an ambitious year of work for the Performance Team, with major improvements made in each release. You can read more about those improvements in the performance improvement summary posts for version 6.2 and version 6.3. While version 6.2 focused on server side improvements, and 6.3 focused more on client side improvements, this release was focused on continuing server side improvements while further optimizing and extending the improvements that were made earlier in the year. Meanwhile, the team continued iterating on the tools and methodologies used to measure and report on performance.
Performance highlights for this release
An overview of the performance enhancements in this release is included in the WordPress 6.4 Field Guide and you can read details about the following highlights in their individual dev-note posts:
Previous performance benchmarks reported for each release were taken by @flixos90 (the performance release leadRelease LeadThe community member ultimately responsible for the Release.) on his own computer, using a standardized set of best practices and tools. This release we have attempted to automate the process in order to establish a reproducible methodology that can be used by any contributor using a standard set of tools.
The process for this release uses the compare-wp-performanceGitHubGitHubGitHub 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, originally developed by @swissspidy, which sets up two standard test sites using wp-env inside of a GitHub worker, takes a set of metrics based on 100 requests, and reports them in the action summary (example). To account for variance between each run, this is done 5 times and the median values are used for reporting purposes.
Revisiting previous releases
Since the testing environment has an important impact on performance benchmarks, we wanted to revisit the previous versions from this year and apply the same methodology for comparison. Each of the following metrics show the percentage the metric either improved (negative numbers) or got worse (positive numbers) between versions.
WordPress 6.2.3 vs 6.1.4
Twenty Twenty-One
LCP: +2.87%
Server Timing -4.21%
Twenty Twenty-Three
LCP: -4.72%
Server Timing -18.15%
WordPress 6.3.2 vs 6.2.3
Twenty Twenty-One
LCP: -10.82%
Server Timing -3.34%
Twenty Twenty-Three
LCP: -14.23%
Server Timing -10.21%
WordPress 6.4.0 vs 6.3.2
Twenty Twenty-One
LCP: -3.95%
Server Timing -4.05%
Twenty Twenty-Three
LCP: -9.06%
Server Timing -4.59%
Detailed data can be found in this spreadsheet, with links to the individual GitHub workflows.
Future improvements
While the methodology used for this release is an improvement over the previous process, there is much room for improvement, including finding ways to stabilize the metrics collected during benchmarks for releases and during development, improving the test content and use cases we test for these benchmarks, testing different configurations and environment characteristics (e.g., PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions, persistent object cache, etc.).
Props
Props to @joemcgill for taking the time to write this extensive and detailed post, and @flixos90 for review.
