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.
Facilitator dev chat: @joemcgill – welcoming one of 2024’s new co-team reps for CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.!
Feedback deadline: February 12, 2024. Add comments to the post.
A Hallway Hangout is scheduled on February 20, 2024, at 15:00 UTC to further discuss it and next steps.
Actionable proposal. Potential for cross-team involvement in furthering it.
Forthcoming Releases
Maintenance releases
@jorbin reports there are currently no updates on a 6.4 release.
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
@marybaum made a request for contributors to fulfill roles of Mission Control, CommittercommitterA developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component., Security, and MarComms for the release parties, especially 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 on Tuesday.
List of new updates on 6.5 including ones requiring input together with their deadlines, next 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, and more.
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 dependencies discussion
You can also view discussions taking place in #core-upgrade-install channel on Slack. This has been highlighted as a potentially very valuable feature for 6.5 and was merged into ‘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.’ on Tuesday. Note this is the last dev chat before Beta 1.
The discussion focused on @desrosj‘s first point in the update: “When a plugin’s dependencies are unmet, the plugin is deactivated, and the user is only informed of this if they visit the plugin page, and only if they visit on the same request that the deactivation occurs on. It is my opinion that plugins should not be deactivated if dependencies are suddenly unmet. This could be very unexpected for anyone unfamiliar with the concept of dependencies in the context of software. Instead, the WSOD protection should be allowed to do its job, allowing the site owner to receive an email, and see a path forward to correcting the issue.”
@azaozz asked if it was better for a plugin to throw a fatal error and trigger “fatal errors protection” in WordPress?
@jorbin: highlighted whatever decisions are made they need to be ones that reinforce the trust users have in WordPress and in auto updates.
@desrosj: There are also some scenarios where things may reasonably continue working without the dependency, but that would break or become missing currently. This would especially be true for anything that displays content. The content would just go missing without the site owner knowing.
@azaozz: A plugin that stops working either because it was auto-disabled, or because it is missing a dependency is a bad thing that needs to be fixed.
A discussion on the use of emails to admins followed, Perhaps sending another email to the admins to alert users. View the discussion on Slack.
@jorbin: suggestion to highlight all the ways that a plugin could end up with unmet or mismet dependencies and what the expectation would be in each of them
@christopher allford : For a feature that has sat in discussion for so long I think pushing through with a minimal implementation (sans the consent-less deactivation) is a great first step. That will naturally incite discussions about iteration (such as sending dependency information in update metadata to let WordPress opt-out of updating incompatibilities).
Summary of two main concerns:
How do we ensure we’ve identified and resolved any issues with this feature during beta so we ship something that does not hurt user confidence in upgrades?
How can we better communicate these changes so folks can be prepared?
Wider discussion surrounded:
How we determine that a large feature is “ready” to ship?
How are can we better communicate when a feature needs further testing after being merged. For example, Is a dev-note enough or should there be some other way to communicate these changes?.
Highlighted posts
The full list of posts from the last week in core can be read on the agenda at this link.
Also, this section provides updates on the core-editor and the Developer blog, including the latest topics that need writers.
Open floor
Anyone can ask for a ticketticketCreated for both bug reports and feature development on the bug tracker. or PR to be discussed during an open floor. To help us provide good feedback, please include a link to the issue you want to discuss in the dev-chat agenda notes prior to the meeting.
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between January 29 and February 5, 2024.
66 commits
117 contributors
79 tickets created
8 tickets reopened
56 tickets closed
TicketticketCreated for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.
Code changes
Administration
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): Use the default cursor style for labels and disabled form controls – #59733
Mock 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-partyAPIAPIAn 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. response in WP_REST_Plugins_Controller_Test – #59647
Some improvements to the Props Bot workflow – #60417
Test against MySQLMySQLMySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. 8.3 – #59779
Remove redundant unregister call in blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. bindings tear down – #60282
Bundled Themes
Twenty Eleven: Fix typo in twentyeleven_widgets_init() description – #60383
Twenty Fifteen: Fix typo in css/blocks.css – #60383
Twenty Twenty-Three: Rename Comments template part – #56999
Coding Standards
Remove unnecessary access and internal annotations from two functions in WP_REST_Templates_Controller – #60358
Rename the $ID parameter to $post_id in trackback() – #59650
Rename the $expires_offset variable in cache_javascript_headers() – #59650
Add allowed_blocks field to block registration and 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/. – #60403
Add viewStyle property to block.json for frontend-only block style – #59673
Add deprecated functions from interactivity core blocks – #60380
Fix PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher warning in Layout block support – #60327
Fix 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. font settings in unit testunit testCode written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. – #60341
Refactor the way block bindings sources are handled – #60282
Remove shadow support via direct attribute – #60377
Sanitize nested array in theme.json properly – #60360
Update WordPress packages 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/ 16.7 RC3 – #60315
Update the WordPress packages to the Gutenberg 16.7 RC2 version – #60315
Update the minimum compatible version of Gutenberg – #60315
fix small typos in block bindings API docblocks – #60282, #60386
introduce dimensions.aspectRatio block support – #60365
reduce specificity of block style variation selector – #60312
General
Add tests for array_is_list polyfill added in r57337 – #55105
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API
Fix CDATA lookalike matching invalidinvalidA resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. CDATA – #60406
Fix void tagtagA 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.) nesting with next_token – #60382
Reset parser state after seeking to bookmark – #60428
HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. API
I18Ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.
Add type declaration to new method missed in [57518] – #59656
Delete .l10n.php files when deleting a theme – #59656
Ensure .l10n.php files are deleted when upgrading language packs – #59656
Fix plural forms parsing in WP_Translation_File – #59656
Improve singular lookup of pluralized strings – #59656
Improve singular lookup of pluralized strings – #59656
Load new translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. library in wp_load_translations_early() – #59656
Revert [57386] pending further investigation – #59656
Support loading .l10n.php translation files on their own – #59656
Upgrade/Install
When populating options, maybe_serialize instead of always serialize
Media
Prevent local edits during media upload – #58783, #23374
Add route for single styles revisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. – #59810
Support assigning terms when creating attachments – #57897
Note: This post was updated to correct the format used in one example and remove references to the wapuu w.org username (not officially associated with the project). A note was also added under a list saved as a synced pattern to indicate the contents of the list may change over time. 2/2/2024 – @desrosj
In January 2022, a proposal was published on this blog to implement a new process within any 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/ repository under the WordPress organization to ensure anyone and everyone contributing to the project receives due thanks in the form of “props.” The post is still almost entirely accurate and it’s recommended you read that in full. Here are some highlights.
One of the greatest things about open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. is that contributions come in many shapes and sizes. Anyone can contribute regardless of skill set, experience, time zone, or background. There are countless ways for someone to get involved with open source projects.
WordPress is no different. Contributors submitting code modifications are only a small subset of the larger community. Recognizing all types of contributions is essential to establishing a healthy contributor base, and the responsibility falls on the project’s maintainers. Contributors who feel recognized and valued are more likely to continue contributing.
There is an established and documented policy on the TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. side of the project to ensure that everyone contributing to a changeset receives credit (or “props”). This method has been in place for over 12 years, making generating the list of props for each release scriptable and straightforward. The process is unique to the project but frequently receives positive feedback from others in open source.
Since being merged into WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. in version 5.0, there has yet to be an equivalent process for the contributions on GitHub. The process is manual, does not account for non-code contributions, and often results in contributors not receiving credit for their work.
The post documents the state of props practices and related processes in detail for both Trac/SVN and GitHub. No major changes have been made to these practices since the publish date of that post.
After taking into account all of the feedback received from that proposal, a new policy is now in place for maintainers.
New requirement for 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/ GitHub merge commit messages
Starting today, it is required that GitHub merge commit messages for Gutenberg include credits for all contributors following the same guidance as Core SVN commits:
Props should be given to all those who contributed to the final commit, whether through patches, refreshed patches, code suggested otherwise, design, writing, user testing, or other significant investments of time and effort.
In Core SVN, this is done as Props x, y, z. In GitHub, this will be done using Co-authored-by trailers. To avoid having personal emails in the commit log of the project (or having to know which personal email someone has associated with their GitHub account at a given time), a contributor’s GitHub and 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/ usernames should be used in the following format:
This practice defines a consistent expected pattern that can be reliably parsed by a script to collect contributions for a repository from a GitGitGit is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. log in the same fashion as the Core SVN repository.
In order to make this new practice easier for committers and maintainers, a new tool has been merged into the code bases.
Introducing Props Bot
Props Bot is a new GitHub Action that will compile a list of contributors for a given pull request. The bot will leave a comment with a list of contributors formatted for use in both Trac SVN and GitHub.
The comment will be continuously updated as new activity occurs. Additionally, the bot can be manually run by adding the props-bot label to the pull request.
Types of activity included:
Anyone who publishes commits to the PR’s 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"..
Anyone who left a review or responded to a review on the PR.
Anyone who commented on the PR.
Anyone who created an issue that is attached to the PR.
Anyone who commented on issues attached to the PR.
As of [57517] in wordpress-develop, and 91450bd in WordPress/gutenberg, Props Bot is now available. 🎉
The bot relies on an active connection between a WordPress.org and GitHub account. For a step-by-step guide on connecting these accounts, please check out the new page in the Core Handbook.
The bot can be used in any GitHub repository, not just ones under the WordPress organization. However, it’s required for the Gutenberg repository, and official WordPress repositories are strongly encouraged to use it since it will allow the project to appropriately credit contributors in WordPress releases more easily.
What doesn’t Props Bot do?
While the basics of collecting contributors is handled by Props Bot, there are still some things not yet handled by Props Bot:
Manually include someone who has not directly interacted with the PR or linked issues.
Contributors who only interact on Trac tickets relevant to the PR need to be manually included.
Only the first 100 comments are currently checked (see props-bot-action 41).
There is one additional step that all contributors should take, even if you have previously connected your accounts.
An added benefit of this new practice is that all props given using this new format will be shown on your GitHub profile’s activity graph. However, this depends on your w.org Git email being added as an alias to your GitHub account (example: desrosj@git.wordpress.org). This can be done by visiting the Settings > Emails page on GitHub.
Note: You’ll see an orange “unverified” notice next to your @git.wordpress.org email after adding it as an alias in GitHub. In the future, email forwarding may be configured to allow these emails to be verified. See this Making Systems request for more information.
How are unlinked contributors handled?
When unlinked contributors are detected, Props Bot will 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.” them in the comment, requesting they establish a connection and link to the handbook page.
Any unlinked contributors are noted in the message provided by Props Bot as a way to associate the person’s contributions with their w.org account should they connect their accounts after the PR is merged. This should be included in the merge commit message.
Contributors without a connected w.org account can not be credited in the w.org Credits 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. and will not have their contributions show up on their GitHub profile.
As a Core CommittercommitterA developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. or repository maintainer, what do I need to do?
The list of Co-authored-by trailers must be preceded by a blank line.
Co-authored-by trailers should be the last thing in a commit message.
The unlinked contributors must come before the Co-authored-by trailers.
Unlinked contributors should be entered in one line preceded by Unlinked contributors:, each one separated by a comma and a space (, ), and a period after the last one. Example: Unlinked contributors: nacin, matt.
Usernames must not start with an @ (at) sign.
When manually adding someone, please only use their GitHub and WordPress.org usernames in the following format: Co-authored-by: githubusername <dotorgusername@git.wordpress.org>.
The only accounts that are allowed to be noted with a non-w.org email are bot accounts (dependabot or github-actions). It’s important to leave these bots as listed by the GitHub generated Co-authored-by trailer so future contributors know which bots were involved in the changes.
If there are contributors already noted with Co-authored-by in the suggested commit message, verify they are also included in the list provided by Props Bot before removing. These will be in GitHub format and should be converted to the above w.org format. Deleting the GitHub formatted ones will ensure an accurate contributor count for each commit, but it’s not required. Non w.org emails will be ignored by the props parsing scripts.
If a contributor’s w.org username is unknown, add their GitHub username to the “Unlinked contributors” list.
If there are Signed-off-by trailers in the suggested commit message, leave them in place above Co-authored-by trailers. These serve a different purpose and are ignored in the context of collecting props.
Note: The above list is a synced pattern. As it’s improved over time, the changes will be reflected in this post. The above list may be different than what was originally published.
If you don’t see a Props Bot comment on your PR, you may need to pull in the latest changed in trunk.
The action does not currently support using the @v1 notation in the value of uses for a step. For now, using trunk is recommended to help test Props Bot.
The Action has no tests. Contributions are more than welcome!
Because this practice was not in place during the 6.5 release cycle, the previously documented process will be used one more time. The timing of this change is such that the work for 6.6 in the Gutenberg release is about to begin, giving us an entire release cycle using this process and allowing the 6.6 release to switch to automating props collection from the Gutenberg repository.
Summary
While these changes do not solve contribution tracking for every team, every workflow, and every tool that’s to make WordPress, this new practice, combined with the Props Bot action, will bring a consistent standard and level of attribution that can be parsed more easily across more areas of the project.
This is version 1 of this change. All feedback and testing is welcome. There will likely be some refinements required after wider testing!
A WordPress release is a sum of all the contributions made during each release cycle, and use of this Props Bot will help us more accurately thank every contributor. ❤️
Props for Props Bot Contributions
A post about props would not be complete without some props! Big props go out to @dharm1025 for helping to get the initial code converted from a generic 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/. file to a GitHub Action. Thank you to @jeffpaul and @jorbin for working closely to refine the action, create the new handbook pages, modify existing ones as needed, and test the bot. And thanks to @dd32 for creating the underlying w.org API endpoint to return w.org profiles for GitHub usernames making this possible.
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).
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between January 22 and January 29, 2024.
48 commits
64 contributors
60 tickets created
4 tickets reopened
67 tickets closed
TicketticketCreated for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.
Update third-party GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions – #59805
Twenty Twenty-Four: Change font family slug to lowercase – #60325
Coding Standards
Add missing escaping functions to WP_Customize_Control and WP_Customize_Nav_Menu_Location_Control – #60324
Add missing escaping in Custom_Image_Header::step_2() – #59278
Fix some spaces on 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.-supports background
Remove unnecessary access and internal annotations from two functions in WP_REST_Templates_Controller – #60358
Use strict type check for in_array() in get_hooked_block_markup() – #60279
Docs
Add missing full stop in WP_Comment_Query::parse_query()DocBlockdocblock(phpdoc, xref, inline docs) – #60323
Fix a few typos in wp-includes/pomo/po.php – #60346
Fix typo in _get_block_template_file() DocBlock – #59651
Improve various globals documentation, as per docblock standards – #59255, #59651
Typo correction in wp_internal_hosts docblock – #60363
Editor
Add Block Bindings APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. helpers – #60282
Add original_source and author_text to the templates 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/. – #60358
Define the labels of the pattern categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.taxonomyTaxonomyA taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. – #60322
Ensure PHPUnit10 compatibility for ThemeJson unit testunit testCode written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. – #60305
Fix 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. application of custom root selector for styles – #60343
Fix back to items label capitalization for the pattern categories – #60322
Set show_tagcloud to false for Pattern Categories – #60119
Unset reference used in foreach statement – #60326
Update the ThemeJson unit test to cover custom CSSCSSCascading Style Sheets. feature – #60294
Update the WordPress packages to 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/ 16.7 RC2 version – #60315
fix classname output on blocks without layout – #60292
fix fluid font division by zero error when min and max viewport widths are equal – #60263
Amend PHPDocPHPDoc(docblock, inline docs) for hooked_block_{$hooked_block_type}filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. – #59572, #60126
Introduce a new hooked_block_{$block_type} filter – #59572, #60126
General
Add $schema property to block and theme JSON files – #60255
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API
Scan all syntax tokens in a document, read modifiable text – #60170
I18Ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.
Add missing variable in string replacement – #59656
Improve edge case handling in WP_Translation_Controller – #59656
Introduce a more performant localization library – #59656
Rename WP_Translation_Controller::instance() method to get_instance() – #59656
Media
Redirect inactive attachment pages for logged-out users – #59866, #57913
Script Loader
Clarify in docs that wp_get_inline_script_tag() and wp_print_inline_script_tag() can take non-JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. data – #60331
Load the modules to the footer in classic themes – #60240
Only emit CDATA wrapper comments in wp_get_inline_script_tag() for 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/. – #56313, #60320
Script Modules API: Rename wp_module to wp_script_module – #56313
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.
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.
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed 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.
35 commits
62 contributors
67 tickets created
10 tickets reopened
72 tickets closed
TicketticketCreated for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.
Introduce functions to check whether WordPress is serving a 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/. request – #42061
Build/Test Tools
Remove leftover trailingslashit() calls in WP_Textdomain_Registry tests – #58919
Expand “imagemin” Grunt task to cover default themes – #58996
Fix var types of parameters in sanitize_option() and sanitize_option_{$option} – #60214, #59651
Format new_admin_email_content placeholders as a list – #60262
Editor
Support deferred 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. variation initialization on the server – #59969
Embeds
Ensure the deprecated function print_emoji_styles isn’t used – #59892. See: #58775
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.
I18Ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.
Cache list of language file paths in WP_Textdomain_Registry – #58919
Correctly invalidate language file paths in WP_Textdomain_Registry – #58919
Do not use trailingslashit in WP_Textdomain_Registry – #58919
Fix duplicate determine_locale() tests added in [57286] – #58696
Prevent PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher warning in WP_Textdomain_Registry – #58919
Media
Inline image CSSCSSCascading Style Sheets. width to backfill width and height attributes – #59352
Redirect inactive attachement pages for logged-out users – #59866, #57913
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/. localization on install page – #58696
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.
Following up on the last call for volunteers, I’m pleased to announce the release squad for the upcoming WordPress 6.5 has been put together in collaboration with project leadership.
The release squad formation is as follows:
Release LeadRelease LeadThe community member ultimately responsible for the Release.:Matt Mullenweg
Core TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads:Ahmed Kabir Chaion, Jb Audras, Rajin Sharwar
This release squad introduces an experimental Default Themes Lead role based on the need to update past default themes due to changes introduced in releases.
As a reminder, the next milestone is WordPress 6.5 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, scheduled for February 13th. You can check the WordPress 6.5 Development Cycle page for a more comprehensive schedule.
Thanks, everybody, for volunteering for this and upcoming release squads! There are already a handful of volunteers for 6.6 and 6.7; this will help set up the 6.6 release squad as soon as 6.5 is launched. Those who volunteered as cohorts, would like to learn the ropes for future releases, or follow the process in general, are welcome to join us in the #6-5-release-leads Slack channel.
Let’s work together on yet another successful WordPress release!
Thanks to @chanthaboune and @cbringmann for collaborating in the squad formation and reviewing the post.
You must be logged in to post a comment.