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.
This Dev Chat continues the experiment to focus chat time on discussions related to open CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. proposals and release issues, rather than repeating links already highlighted in the curated agendas.
Following announcement of yesterday’s 6.4.3 release, @jorbin noted that there was one issue of note, but that there were workarounds available at this time. @jorbin further gave props to those who helped facilitate the release.
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. Publish Date
@jorbin was under the impression that neither the dev blogblog(versus network, site) team nor 6.4 release leads were interested in moving forward with the proposal. @webcommsat shared that 6.4 docs release leads didn’t see 6.4 as the deadline, and discussions were continuing. @joemcgill agreed that the proposal wasn’t release specific, but rather an adjustment to timing of when field guide information is released. @hellofromtonya also added that the dev blog team has opened a discussion to track the second part of the proposal.
@jeffpaulreferred to @chanthaboune‘s comment of where best to separate field guide content based on audiences, suggesting the proposal could be adjusted accordingly. @jeffpaul added that some folks have difficulty processing field guide information to determine what is relevant and actionable, which @hellofromtonya agreed should be explored. @webcommsat agreed with the notion to target field guide content to particular audiences, but also to look at how it relates to other new content produced for the release.
@ironprogrammer asked if the field guide info would be more easily consumable if it was split into a canonical structure, such as wordpress.org/6-5/field-guide/, with subpages that match particular areas or audiences.
@webcommsat noted that segmentation between audiences has grown, and suggested it’s a good time to use teams’ audience-specific insights to improve the field guide format. She added that exploring how best to utilize the limited people and time for the Docs team would be an important factor in implementing improvements. @jeffpaul agreed with concerns around challenges in gathering/publishing content, but noted that the issue should be considered as separate from the proposal.
@jorbinshared that the original published field guide was the result of an overly long email sent to 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 developers.
First-time Docs Co-Lead@estelaris 🎉 asked about adding additional comments to the proposal. @jorbin noted that Make/Core comments close automatically after 180 days (~6 months). @costdev shared that adding the #keep-comments-opentagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) would reenable them, but recommended removing the tag once an updated timeframe for feedback has been reached. @jorbinupdated the Core handbook to reflect this info.
@joemcgill pointed out that the team should review all current channels where field guide-related content is published, to check whether only updating the field guide [in one place] would sufficiently improve the broader sharing of release updates to the community. He suggested engaging with the Docs and Marketing teams to move forward, and @estelaris noted she would begin by sharing with Docs. @webcommsat suggested looping in Training as well. @laurlittle noted that the Marketing team could brainstorm on the proposal for future releases, if not 6.5.
In response to @joemcgill, @webcommsat noted that there have been past lists of channels and audiences, and suspects more current info should be available. She also suggested it might be helpful to have a single post that links out to the various user groups identified earlier, and to link to that post from the About page.
@jorbin referred back to @jeffpaul‘s input and asserted that the dev blog and other team areas might be better places to communicate field guide information, as opposed to Make/Core. @hellofromtonya asked if, considering this perspective, the proposal was actionable by the Core team, or if the proposal should be re-worked as a cross-team collaboration. @jorbin suggested that the teams publishing the field guide info would take on the proposal.
@joemcgill noted that it can be difficult to know the status of a proposal, suggesting some way of flagging these posts. @marybaum suggested a visual system to convey “stalled”, “live”, etc, and @joemcgill raised the idea of 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. pattern. @desrosj shared that in past proposals (example) he has added status info to the top of the post, assuming the status was clear.
@hellofromtonya wrapped up the discussion based on the chat, concluding that the proposal be marked closed (“not accepted”), or must be picked up by another team(s).
Actions:
Part 1: Move Make/Core field guide publication ahead one week, aligning with last scheduled 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., rather than RC1. Not accepted ❌
Part 2: Start publishing a simplified field guide to the WordPress Developer Blog. Not accepted ❌
Other teams to explore revising and adopting this proposal:
@laurlittle to raise the proposal to Marketing for possible brainstorm.
@webcommsat to 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. in Training to gauge their interest in furthering the proposal.
To highlight in dev blog.
Open Floor
@hellofromtonya reminded everyone that 6.5 Beta 1 is approaching fast: February 13 (less than two weeks).
This DevChat starts with an experiment to shift the chat to synchronize discussions on open coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. proposals and release issues rather than reproducing links highlighted in the curated agendas.
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.
The API is well beyond the proposal stage, with nothing actionable in discussion.
Actions:
The proposal should be considered “accepted”.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API: Introduce WP_HTML::tag() for safely creating HTML
This PR was raised along with the question of how items should be added to the agenda. It was clarified that topics can be added as comments to the previous week’s chat summary, or to the current week’s agenda post (typically published on Tuesdays). And of course, any item can be raised during the open floor section of Dev Chat.
@dmsnell indicated that the PR for consideration is a scaled back version of a larger templating system proposal, which will not be ready for 6.5. The PR adds a helper utility, WP_HTML::tag(), to conveniently generate single HTML tags with attributes. The impetus for this feature is to provide Core and extenders a safer way to generate HTML tags, compared with reliance on proper usage of functions such as esc_attr(), which might be overlooked and introduce HTML injection vectors.
@jorbin would prefer that any new APIs be used by Core itself, and that there be accessory patches prepared that demonstrate how the function integrates and operates in Core. It was also suggested that a Make/Core proposal would help with gathering broader input.
@azaozz pointed out that enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. tickets in TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. are another form of “proposal”, and can also result in healthy discussion. He suggested starting the discussion in Trac, and then utilizing a Make/Core proposal if the ticketticketCreated for both bug reports and feature development on the bug tracker. isn’t sufficient to establish consensus.
@jorbin shared the remaining open tickets for this milestone, which are scheduled for review and commit prior to a Thursday (Jan 25) 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).:
#60025 – This needs additional review and testing. Any help is appreciated
#59866 – @peterwilsoncc and I have been work on the one and I should have an update in the next 12 hours.
@oglekler pointed out that there are several early 6.5 tickets that need attention, asking for review as some might have the potential to be completed in time for 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..
@hellofromtonya indicated that the 6.5 cycle is past the “early part of alpha”, suggesting these may need to be punted if they truly require a long runway for soak time and discussion.
@azaozz agreed that the early keyword indicates a need for comprehensive testing, and possible reconsideration of the milestone if the testing hasn’t occurred. He also suggested that while not required, it might be preferable to fix old/known bugs during alpha, and allow beta testers to focus on “new” bugs introduced from Beta 1 and onward.
@jorbin suggested two interpretations of early; i.e. actually early in the alpha cycle, or just before Beta 1.
@hellofromtonya noted that since Beta 1 is the puntpuntContributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.) milestone for enhancements/features, that in her perspective, early should apply to early in the alpha cycle. She cited changes to WP_Query as an example where early would apply.
@afragen observed that it doesn’t seem that many early tickets are committed early in the cycle.
In order to expand topics in the Contributor Mentorship Program, @oglekler invited Core contributorsCore ContributorsCore 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 share interesting and important ideas, tickets, and issues related to Core over in the #contributor-mentorship channel or via DM.
WordPress 6.4.3 Release Candidate 1 (RC1) is available for testing! Some ways you can help test this minor release:
Use the WordPress Beta TesterpluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party
As this is a minor RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). release, select the Point Release channel and the Nightlies stream. This is the latest build including the RC and potentially any subsequent commits in trunk.
6.4.3 RC1 features 5 fixes in Core as well as 16 fixes for 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.
The following coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. tickets from TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. are fixed:
The following block editor issues from 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/ are fixed:
The dev-reviewed workflow (double committer sign-off) is now in effect when making changes to the 6.4 branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..
The final release is expected on Tuesday, Janury 30th, 2024. Please note that this date can change depending on possible issues after RC1 is released. 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-4-release-leads channel.
A special thanks to everyone who helped test, raised issues, and helped to fix tickets. With this release candidate, testing continues, so please help test!
These will focus on open proposals in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and release items.
Next week’s dev chat, a discussion opportunity is identified for this open proposal on core relating to major release Field Guides.
Could you help curate a Call for Volunteers to review the open proposals on Make/Core and create a list of unresolved ones to discuss during Dev Chat meetings?
On TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between January 15 and January 22, 2024:
New core contributor meeting – if you were not able to attend and would like to find out more, check out the link to the meeting in Slack on January 24, 2024 which includes useful information on getting started and the contributor mentorship program. The deadline for applications for the second cohort for the program is Wednesday, February 7, 2024.
Section Styling: some questions remain around CSS specificity to unblock this work. Whether that problem can be resolved determines whether this will be included in the release.
Font Library: biggest work continues to be the Font Library: refactor REST API which needs feedback. Please help review if you have experience with the 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/. and review the merge criteria for this feature..
Data Views: the default layout has been set to table layout for template, template parts, and patterns after feedback from design. A PR is in progress to stabilize the new Data Views for Patterns ahead of the release with the grid layout as the default.
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.: work continues for a public launch with 6.5 with great optimism that it will make the cut off.
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
Any other updates?
Phase 3 media library meeting will take place on Thursday, 8 February 2024 at 00:00 GMT in the #core-media channel. The Media Component team is coordinating a meeting with the Editor team and other interested stakeholders to work on planning for the proposed Phase 3 Media Library.
Core-editor improvement – revisions in the site editor. This is a useful post for understanding some of the changes and new features to current revision functionality in the Site Editor aimed for 6.5 and the wider work in this area.
Important milestones in the Editor for 6.5 – useful post for contributors working or wishing to support the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository with the scheduled 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 for WordPress 6.5 scheduled for February 13, 2024.
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.: 6.4.3
Any other updates?
Earlier today there were four open tickets – update in 6.4 release leads channel.
positive feedback and highlighting that people can self-nominate their ability to help triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. those open default theme issues
promote the call to encourage people to be active in triaging and resolving those 436 Bundled Theme tickets
advised the idea has been accepted: t’s rallying a group of folks to get through and clean out the Bundled Theme component backlog on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
three self nominations and more expected to be confirmed by end of the week
aim to start before the end of January 2024, currently 437 tickets in the Bundled Theme component
Jonathan will be leading the team as a mentor and someone with commit privileges, and other committers are welcome to help as well)
the week to week working arrangement will be depends on the team’s availability. Stay tuned!
confirmed the new theme task force group will remain under core team purview. More detail on this in the comments section of the post. More contributors for the Themes team welcome to help out too. “It’s a balance though, My goal here was to allow those contributors to continue exploring what new themes look like while this team handles cleaning up some of our cruft and backlog for pre-existing ones.”
expecting ‘as a side effect, cleaning out the backlog also will effectively “retire” these themes in some ways, and going forward, the majority of the tickets will be 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 support related (hopefully).’
Actions:
more volunteers needed and will increase the speed can go through the outstanding tickets in the component
Context: This proposal was started in 6.4. With 6.5 underway, thinking the learnings from 6.4 could be built upon for how to continue improving the Core merges from 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/ during 6.5. Core Editor and Core chats are now combined into Dev Chat as an experiment.
Discussion:
@joemcgill raised the question of the right venue to push this forward. “In my opinion, the current status quo is error prone and unsustainable (as well as taking a lot of manual overhead from contributors).”
@hellofromtonya: I’m not sure either what the “right venue for pushing this forward” is. Needs a discussion with both Core and Core Editor folks to figure out the needs and how to improve these workflows. Seems earlier the better 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. 1 is fast approaching
@jorbin suggested one way to mitigate the issue would be nominating the release team, or at least the editor tech, for the next release before the current release ships. An interim editor tech to help get the ball rolling while an official team has not been announced. @joemcgill agreed having an identified set of release leads for 6.5 to discuss how they want to handle things for this release would help. The Community Summit conversation was very helpful. A working group to continue that conversation and come back with concrete proposals would be helpful, if a release team is not the right venue. A working group had positive feedback in the dev chat discussions as these workflows are continuously improving and span more than one 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.. @jorbin suggested @tellthemachines should be given right of first refusal to continue leading the effort since she kicked off the proposal.
Ideas included: a proposal needed to address the identified set of problems, a hallway hangout similar to the ones @annezazu and others have done.
Actions:
Wait for response from @isabel_brison about leading the working group. Done ✅ After DevChat, Isabel responded and is interested in leading the working group.
As a follow-up from @joemcgill‘s questions last week, @hellofromtonya has added the Core merge criteria/expectations to its Trac ticketticketCreated for both bug reports and feature development on the bug tracker.. The critieria is the same as in 6.4, except Tonya is suggesting returning to the expectation the feature is merged before or by Beta 1.
Query raised on the criteria aspect of “running on wp.com, and not being reliant on any specific host testing this. @hellofromtonya: The reason for wp.com is: it’s a normal workflow in Gutenberg as it gains a huge amount of sites running it. @jorbin
Question: Is this anything beyond what we’d normally expect of a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.? @hellofromtonya: Same expectations except for 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/. part of it , as I’m suggesting a maintainer needs to give a thumbs-up to its design.
jorbim: I don’t want to discourage that in any way, I just wonder if we would ever set a requirement like “Is running on Altis with no major issues”
Actions:
Update the criteria from the discussion. Done ✅
Gather expectations from the REST API maintainers and then update the criteria accordingly. Done ✅
How was the first experimental new DevChat?
@jorbin said: “I think one of the most productive meetings in a while”
@afragen shared there was no extra time to raise other tickets for discussion.
What to change?
Next week, reserve 10-15 minutes for open forum / floor discussion.
.. the versions of Node.js and npm required for WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development are now 20.x and 10.x.
In order to continue contributing to WordPress through wordpress-develop or WordPress/Gutenberg, you’ll need to upgrade the version of Node.js installed on your machine to one that’s greater than or equal to 20.10.0 (currently the most recent generally available version 20.x version). This should also update npm to the correct, expected version appropriately (10.2.3 or higher is required).
Release Updates
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.: 6.4.3
No pressing issues – okay to wait “a few weeks for the next minor.”
Reminder to “milestone any tickets” needing addressing.
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
Next milestone: 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 is Feb 13th.
Tickets / Issues that need assistance
#60227@jonsurrell asked for feedback to use an external library for testing the HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.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..
#60025@jorbin requested help (it’s in the 6.4.3 milestone) and noted:
#58719@justlevine asked is for feedback and decision criteria for bumping the minimum PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher version to 7.2.
@bph shared the following 6.5 features being developed 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/ that need testing and feedback:
As we are now 43 minutes into the meeting and it’s been almost all link sharing thus far, I wonder if perhaps 2024 should be the year we explore some alternatives for this meeting? I’m not sure that a link dump is doing it
socializing to folks leading/working on feature projects or specific items targeted in a current major release that devchat is a good place to come and share blocks/problems/areas for feedback they have. Chatting through those things synchronously can help find alternate paths forward for those things that are of importance to the project.
advance those conversations towards an acceptance or finding iterative ways to improve those proposals.
When to start? Experiment starts next meeting.
Call for Volunteers to review the open proposals on Make/Core and create a list of unresolved ones to discuss during the DevChat meeting.
Font Library – avoid merge roadblocks
@joemcgillasked for Font Library update and plan to avoid the roadblocks experienced during 6.4. See the discussion in the Slack thread which includes Core merge criteria.
WordPress 6.4.3 is scheduled to be the next maintenance release for the 6.4 version. Its release will follow the following preliminary schedule:
25 January 2024 – 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). made available and announced here on the make/coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. site.
30 January 2024 – Final release made available.
Specific times will be decided in advance and adjustments to the schedule may be made. All adjustments will be noted in this post.
Minor or Maintenance releases of WordPress are intended as 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.-fix releases. Currently, four bug fixes have been merged into the 6.4 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". with seven additional tickets intended for this release. If you have a ticketticketCreated for both bug reports and feature development on the bug tracker. that you think should be considered, please put it in the milestone or if you lack bug gardening capabilities, add a comment here. Note: except in extreme situations, only bug fixes will be considered and generally only bugs that have been introduced during the 6.4 cycle.
Final note: Some default themes are also receiving updates, but these will be happening separately even though the tickets are in the 6.4.3 milestone. See #60267 for more information. Update: The theme updates have been released
Get involved with 6.4.3
Bug Scrubs will happen in the #core room during the follow times:
Each of the open tickets is going to require development work along with testing and review. You can also run scrubs to help ensure that the correct tickets all are fixed in this release. Additionally, while the intent is for no new strings in this release, some locales have strings in 6.4 in need of translation.
General coordination for the release will happen in the #6-4-release-leads channel and decisions around code for the release will be made in the #core room.
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. will be led by @mikachan, @joemcgill, and myself (@jorbin).
WordPress 6.4.2 Maintenance & Security Release: 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. addresses a handful of CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. bugs, as well as a preventive security update. Props to the minor release squad for getting this shipped!
Redesigning Developer Resources and a call for testing: Your feedback is requested to help move forward on improving the design and information flow for 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/’s Dev Resources content.
Create Tours for Make P2s: All team blogs have this new 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 activated…how can your team use it?
Coming to 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/ 17.3, you can explore partially synced patterns behind an experimental flag by enabling the “Connections” experiment when the time comes.
Progress update on having the navigation overlay as a separate template part that can be individually customized.
PR to Add layout classes to legacy Group inner container merged (requires a PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higherbackportbackportA 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.) as part of an overall effort to bring appearance tools to classic themes.
The 6.5 roadmap is slated to ship this week barring any last minute feedback.
Release Updates
Next minor release: 6.4.3
@jorbin indicated that work is underway to put a squad together for this release.
👉🏻 Volunteers interested in helping on the 6.4.3 minor release 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
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? Bug scrubs post. Next scrub: December 19, 2023 at 19:00 UTC in the #core Slack channel.
Component Maintainer Updates
Disable autoload for large options
@flixos90 requested a second opinion and general feedback on the approach envisioned in https://core.trac.wordpress.org/ticket/42441. In order to differentiate between whether an autoload value for an option was set as a default or explicitly chosen, it is proposed to add new possible values for that database column. For additional context, comment:20 may be helpful, and a PR implementation already exists.
While personally supportive of the effort, Felix added that such a change will require a 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., and plugins specifically focused on autoloading may need to cater for the change. It was clarified that only plugins that enhance autoloading specifically should be affected. @azaozz agreed that this approach was sound, and should be fully backwards compatible. Additional discussion moved to the Trac ticket.
Also from the agenda comments, @antonvlasenko asked for feedback on a proposal (GB 56487) to [temporarily] disable the WordPress-Docs ruleset from Gutenberg. Core doesn’t use these rules, so this change would simplify the backporting process from Core, improving parity between the repos. Feedback on the issue or accompanying PR is greatly appreciated.
There is no specific target date for WordPress 6.4.3 yet, but that doesn’t mean work can’t be done to ensure that all the correct bugs are targeted for it and that work progresses towards fixing them. To assist with this, some initial scrubs will be held at the following times:
Anyone else that wishes to host a scrub for 6.4.3 is welcome. Please comment here with the time you would like to hold one and I will edit the post to include it. As the documentation on leading bug scrubs states:
Leading a Bug Scrub is something any interested community member can do.
This post summarizes the feedback received from the WordPress 6.4 retrospective. Thank you to those who contributed their feedback via the retrospective survey and comments on the post. For ease of reading, feedback has been synthesized. Full feedback is available for review in the anonymized form responses and comments to the original post.
Please remember that the following feedback are suggestions to bear in mind for future releases rather than action items for implementation.
What would you keep?
The Community needs/“wishlist.”
Blogblog(versus network, site) post per new feature or major change, e.g., performance improvements or the HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Tag processor.
Release team formation and announcement during the previous release cycle for easy coordination.
Having a co-lead per release focus to allow for complimentary time-zone coverage.
Weekly health checks.
What would you add?
Additional minor releases between majors.
Iteration on Twenty Twenty-Four for Twenty Twenty-Five to reduce fragmentation.
Earlier merging of stable 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/ features into WordPress 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..
Equal focus on old tickets 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 with new features.
Feature the Pattern Directory in 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.
A dedicated session in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for testing the release.
A focus on cohort involvement for sustained contribution beyond a 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.’s development cycle.
More underrepresented release squads and opportunities for synchronous meetings in different time zones.
What would you remove?
Underrepresented release squads.
Minimum Core code contribution for Editor Tech role.
Increased documentation and training for new contributors to the release process.
Allow only “blessed tasks,” with enhancements/features that have received a first commit 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 to continue to Beta 2 et al.
How did the collaboration feel?
This section included ways for one to indicate how much they agreed or disagreed with a statement around collaboration.
Would you like to be part of future release squads?
16.7%: I haven’t been part of the squad but I would like to try in the future.
8.3%: I have been part of a release squad and I will gladly repeat.
41.5%: I have been part of a release squad before and will do so again, although maybe not next year.
8.3%: I am reluctant to participate again, but I would be open to it if responsibilities and processes were clearer.
8.3%: Maybe later, I’m not sufficiently experienced yet.
8.3%: I have been part of a release squad and would like to repeat, but unfortunately I don’t have the time for near/midterm future.
Takeaways and next steps
Respondents felt that following the development cycle as a new contributor was challenging.
Future WordPress Contributor Mentorship programs will mirror major releases so new contributors have mentored experience with ample documentation and support to find contribution onboarding opportunities.
The shorter development cycle, while previously requested, felt too short for ample feature development and testing.
6.4 was, for all intents and purposes, a success in bringing underrepresented gender voices, skill sets, and points of view into WordPress’s development cycle. 2024 will not include specific release squads to allow for more broad contributor involvement.
Maintenance will be one focus alongside new features for the WordPress 6.6 release in response to a call for more maintenance in major releases.
You must be logged in to post a comment.