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.
Summary posts covering content from November 2023: What’s new for Developers, November 2023 and What’s New on Learn WordPress, November 2023 edition. More developer-focused posts are available on the Developer Blog. The next editorial meeting has been moved to December 14, 2023, 13:00 UTC in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-dev-blogblog(versus network, site) channel on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
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.
Tickets or Components help requests
Please add any items for this part of the agenda to the comments – tickets for 6.5 will be prioritized. If you can not attend dev chat live, don’t worry, include a note and the facilitator can highlight a ticketticketCreated for both bug reports and feature development on the bug tracker. if needed.
Open floor
If you have any additional items to add to the agenda, please respond in the comments below to help the facilitator highlight them during the meeting.
Dates for Dev Chat
The last Dev Chat in 2023 will be on December 27, and the first in 2024 will take place on January 4.
In May, a proposal was published with a suggestion to retire some of the older, lesser used default themes. With the release of Twenty Twenty-Four, there are now 14 default themes maintained by the project, making it difficult to effectively maintain all of them. Additionally, retroactively adding support for new 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 features is important to ensure that users can unlock the power of the block editor while using these themes. This is becoming increasingly harder to do in a timely manner with the high standard of quality our users deserve.
After some good discussion in the comment section, Matt (@matt) joined in and clarified that the original intention for each default theme was to maintain them forever. He issued a challenge to rethink how the team approaches the maintenance of these default themes to make them easier to maintain, and more future-compatible.
In response to that request, I submitted “Improving the maintenance of older default themes” as a topic for the Community Summit in August. This topic was accepted, and a fantastic session took place with many of the top theme-focused contributors from the community in attendance.
I highly recommend reading the raw notes in their entirety before responding to this proposal and participating in this discussion, but for the sake of including the context of the important takeaways from that discussion, here are next steps and potential action items that were identified:
Consider having a Theme Wrangler for every release.
Explore moving default themes to 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/ (with sync to SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.), moving only the most critical issues from tracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. to move over.
Explore creating style variations and patterns based on past default themes, as a way to “blockify” the older themes.
Explore setting up visual regressionregressionA software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. testing for default themes
How do we improve the feedback 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. from people building themes in GB?
Improve default theme docs.
All of these are reasonable next steps and worth exploring further as potential changes. However, after considering this topic some more and discussing with @chanthaboune, it’s become clear that the first step to any solution to this problem is cleaning up after ourselves. At the heart of the problem is not a tooling or philosophy problem, it’s a bottleneck of available contributor time with an interest in supporting these themes.
At the time of publishing, there are 436 open tickets in the Bundled Theme component, 53 of which have not received any response. This list of outstanding tickets needs to be properly groomed and addressed before any tooling changes can be considered.
Creating a Theme Task Force
This post proposes the creation of a contributor working group with the goal of tackling the Bundled Theme component ticketticketCreated for both bug reports and feature development on the bug tracker. backlog, focusing on one or two themes at a time and using their best judgment to:
TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. the list of open tickets for the Bundled Theme component.
Address bugs in a future-proof way.
Individually evaluate enhancements and feature requests, closing any that are no longer relevant or not supportive of project priorities.
One criticism of how default themes are maintained has been that updates are always released at the same time as WordPress major and minor releases. After researching and investigating why this is the case, no specific reasons were discovered that indicated this is a requirement.
Recently, there have been a few occasions where updates to default themes were released independent of WordPress ones, and these have gone quite well. It is recommended that this practice continues as a part of this proposal in an effort to more efficiently progress through this large backlog of tickets. Theme updates can be released as often as necessary. Theme updates accompanying WordPress major and minor releases are not barred, but rather welcome when deemed necessary as supplemental to any other updates published by this group.
While each theme receives increased individual attention, the state of support for the block editor and all of its features will be audited and evaluated.
Once this ticket list is under control, further discussion can be had around potential tooling changes (GitHub vs SVN), frameworks or methodologies that can be implemented to make maintenance easier, etc.
Summary & Volunteers
In total, default themes account for over 10% of all WordPress installs. While some are less used, the active sites for each of them represent site owners and end users that deserve our attention and consideration. In order to better support them in a future compatible way unlocking the block editor, this house keeping initiative is a necessity.
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.
Since 2010, WordPress has released a new default theme every year but one. Each default theme (though sometimes stylistically opinionated) is meant to provide a solid and flexible foundation that site owners can use to build out their new WordPress site.
Though only the three most recent bundled themes are included in new WordPress installs, all 13 of the default “Twenty” themes are currently actively maintained. The level of effort to support 13 themes is not insignificant, especially in the times of the rapidly evolving 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 burden of maintaining these themes has historically fallen on the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. team to ensure they continue to receive any needed updates.
Because there are so many, it’s not uncommon for it to take several months before older default themes properly support newer features added in WordPress Core. Additionally, themes created prior to the existence of certain APIs are often unable to fully take advantage of these new features (global styles, block patterns, etc.).
Trimming the number of default themes actively supported will allow contributors to be more effective at providing the best possible experience in modern WordPress through the block editor for sites using newer default themes. It also helps clear the path for work on new block theme-focused experiments and initiatives (such as the Community Themes Initiative) attempting to refine the role that themes will have in the block editor era.
This post summarizes the current state of bundled themes in WordPress before proposing new support states for bundled themes, as well as two potential ways to decrease the total number of themes receiving regular updates.
Documentation and Data
Before proposing any changes to the bundled theme support policy, it’s important to fully document the current state of bundled themes, how they are maintained, and the bundled theme life cycle (which can roughly be divided into three stages).
Bundled Theme Life Cycle
Build Out: Once per year, a new default theme is announced and planned in coordination with a major version of WordPress (typically the final one of the calendar year). A small team of contributors buildeachthemeoutonGitHubGitHubGitHub 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/ over the course of 1-3 months before it’s merged into the WordPress Core SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. code base for release and future maintenance.
Active Default Theme: The theme is released with the next major version of WordPress where it receives its time in the spotlight being activated as the default for all new sites. The original theme authors typically continue to work on improving the theme and fixing bugs during this stage. Active default themes are usually the first bundled theme to receive support for new features added to Core. Every effort is made to ensure full support when the next version of WP is released within reason and where appropriate. The active default theme ideally shows the full capability of what WordPress can do. Note: “active” default theme is currently not an officially recognized designation.
Maintenance: The next default theme is built and merged into Core and activated for new sites. The previous theme continues to be maintained, but those involved with creating it often are not able to keep up with maintaining it long term, or are assigned to other projects and initiatives. Bundled Theme component maintainers and other 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. become almost entirely responsible for maintaining the theme, in addition to all others that came before it.
Defining Maintenance
Maintenance means many things in different contexts. Here is an incomplete list of typical maintenance currently required by and performed on bundled themes in no particular order:
Ensuring compatibility with new versions of PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher.
Fixing reported bugs.
Adjustments to code utilizing pre-existing WordPress APIs and functions to prevent additional bugs.
Deprecations related to jQuery and other 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/. Library updates.
Utilizing new functions, APIs, or best practices as necessary.
Changes required to adhere to new and more modern web standards and requirements.
Adding support for new features in the block editor and throughout Core.
Updating npm dependencies and build scripts.
Security updates.
Curating changelog updates.
Bundling, testing, and pushing releases to the theme directory.
Along with these maintenance tasks, there are some factors that need to be considered and make
When themes are built, they target support for specific browsers and versions. This does not change over time and the support policy is “locked in” for the life of the theme. As an example, older bundled themes likely still contain code that specifically targets IE6-9. It’s usually not worth the effort and risk to remove this code because it’s impossible to anticipate the impact in the wild, especially for any child themes that have been created.
The minimum version of WordPress required for default theme when released is set to the version of WordPress it is initially released with and does not change. As an example, Twenty Ten still technically supports back to WordPress 3.0.
Shipping patterns in themes that support WordPress 5.0 and up is particularly complicated since valid block syntax changes over time (see #53617 for an example).
Adding support for new features is not always straightforward and takes a substantial amount of time to test, especially for older themes (see #56487 for an example).
Current Default Theme Usage
Another important factor to consider before making any changes to a support policy is overall usage. Here is a rough breakdown of the active install counts for the “Twenty” default themes (according to 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/) as of April 26, 2023 (note: this does not include sites running child themes of any “Twenty” themes):
Twenty Ten: 90,000+ installs (~0.3%)
Twenty Eleven: 100,000+ installs (~0.4%)
Twenty Twelve: 90,000+ installs (~0.3%)
Twenty Thirteen: 50,000+ installs (~0.2%)
Twenty Fourteen: 100,000+ installs (~0.35%)
Twenty Fifteen: 100,000+ installs (~0.45%)
Twenty Sixteen: 100,000+ installs (~0.7%)
Twenty Seventeen: 700,000+ installs (~2.5%)
Twenty Nineteen: 200,000+ installs (~1%)
Twenty Twenty: 600,000+ installs (~2%)
Twenty Twenty-One: 800,000+ installs (~3%)
Twenty Twenty-Two: 800,000+ installs (~3%)
Twenty Twenty-Three: 1M+ installs (~3.5%)
Some interesting findings:
Twenty Thirteen is the least used default theme at roughly 50,000 installs (0.2%).
Twenty Fifteen and older are all active on less than 0.5% of all WordPress sites each. Cumulatively they account for slightly more than 2% of all sites.
Twenty Sixteen and older all have less than 1% of all installs.
Twenty Twenty-Three is currently the most used default theme active on 1M+ sites.
Twenty Twenty through Twenty Twenty-Three all have roughly 2% of all sites or more each, cumulatively accounting for nearly 12% of all sites.
Twenty Seventeen through Twenty Twenty-Three accounts for 15% of all sites.
Defining and clarifying the different default theme states
This proposal is also a good opportunity to refine and clarify what the different states of bundled themes are before deciding if any default themes should be retired. Currently, there is only “actively maintained”. In order to retire older themes, there needs to be a new retired state defined. It would also help to have an intermediary state (similar to long-term support or LTS) where some support and maintenance is performed, but not all.
Actively supported state
This state is for all themes included with new WordPress installs (three most recent). Ensuring the themes in this state are fully compatible with the latest version of WordPress when released is top priority. Themes in this state will receive:
All types of 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.
All types of compatibility fixes (PHP, WP, etc.).
Support for all new features added to WordPress (when they are relevant).
Security updates.
Changes to utilize new functions or APIs.
Changes to adhere to best practices or modern web standards.
Maintained state
This state is for all themes that have not yet met the requirements for retirement but are no longer included with new WordPress installs. Themes in this state will receive:
All types of bug fixes.
All types of compatibility fixes (PHP, WP, etc.).
Security updates.
Retired theme state
These themes have met the requirements for retirement and are no longer actively maintained. Themes in this state will receive:
No new enhancements, features, or bug fixes.
Security updates.
In addition, the “Tested up to:” value will no longer be updated with each WordPress release. Any tickets currently open on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. for a theme being placed in the retired state will be scrubbed and closed.
Retiring older bundled themes
Regardless of which methodology is used to identify when themes should be retired, the following points should be considered:
Policies can always be altered as themes and WordPress continue to evolve. What constitutes a theme currently evolving being re-explored. Any support policy set after discussion can always be revisited in the future with new context.
A review of the actively supported themes will be conducted annually. After a new default theme is built and released, the list of default themes will be reviewed using the criteria chosen from this proposal. When a theme qualifies for retirement, a proposal will be made on the Making WordPress blogblog(versus network, site). Barring any compelling evidence that the theme should continue to remain in maintenance state, the open tickets for it will be scrubbed and closed appropriately and the theme will be retired after the next major WordPress release.
Proposed Criteria for retiring bundled themes
The following criteria is proposed as the requirements to retire a bundled theme:
Themes must be supported for a minimum of 5 years. Even if a bundled theme is not widely used, it must be actively supported for at least 5 years.
Themes must be active on fewer than 1% of all WordPress sites (as determined by WordPress.org data).
Themes that would be retired today with this criteria:
Twenty Ten
Twenty Eleven
Twenty Twelve
Twenty Thirteen
Twenty Fourteen
Twenty Fifteen
Twenty Sixteen
Themes that would be moved to maintained status
Twenty Seventeen
Twenty Nineteen
Twenty Twenty
Themes that are actively maintained (currently shipped with WordPress)
Twenty Twenty-One
Twenty Twenty-Two
Twenty Twenty-Three
This proposal uses a minimum percentage of active installs as the criteria for retiring default themes.
While percentages like 1% may seem low, it’s important to call out that when applied to WordPress installs, even 1% equates to a few hundred thousand sites. As more new WordPress sites are created and this number is greater, the policy can be revisited and altered if necessary (see above).
Pros
Brings the number of actively supported themes from 13 to 6.
Drops support for themes with an outdated aesthetic (less emphasis on visual elements, content visually “contained” within a boxed layout, etc.).
Results in both fully block-based themes (2) and some classic-style themes (4) being actively supported or maintained.
Establishes a clear criteria for an annual review going forward.
Reduces the maintenance burden for 3 themes by refining what it means to be maintained vs. actively maintained.
Cons
A non-zero number of WordPress sites currently use these themes (roughly 730,000).
Conclusion
This post presents a thoroughly refined recommendation as a result of feedback from several contributors listed below. However, it is only a proposal and is not concrete. Adjustments can be made to this proposal based on feedback from contributors in the comments below. If you have any thoughts, please do leave them below!
Unless there is a need to republish a modified version of this proposal for further feedback, after a consensus is reached and any needed approval from leadership to implement this proposal is received, the following action items would need to be addressed:
The Making WordPress Core handbook should be updated in the appropriate places to outline the annual process to review for retirement candidates.
Contributors should scrub all tickets for themes being retired and either close them out with a message why, or complete them before the theme retirement date.
A post on WordPress.org/news announcing the retirement of any themes being retired and clarifying what that means.
Any other action items identified while discussing this proposal.
Review a discussion around changing the order of the sidebar items in the Site Editor (and why it might make more sense in the future with improved blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme switching!).
In the meeting or in the comments for async contributions, @annezazu asks if folks can please emoji reactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. with feedback to give a sense of whether she is on/off track: = good, = okay, = bad. For anything other than green, feel free to thread a comment during the meeting with feedback or link the item and add it to the comments below.
Please also add your thoughts to the discussion on the future of the core-editor chat.
Forthcoming release updates
WordPress release: 6.4
Any new issues?
New updates on 6.4.x release team or dates for 6.4.2?
For those who were missing the core contributor profile badge and should have received it after 6.4, profiles have been updated. Slack update. should have it now.
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. Check out the tickets discussed at the bug scrub on November 28, 2023. Next scrub: December 5, 2023 at 19:00 UTC in the core SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.
Tickets or Components help requests
Please add any items for this part of the agenda to the comments – tickets for 6.5 will be prioritized. If you can not attend dev chat live, don’t worry, include a note and the facilitator can highlight a ticketticketCreated for both bug reports and feature development on the bug tracker. if needed.
Open floor
If you have any additional items to add to the agenda, please respond in the comments below to help the facilitator highlight them during the meeting.
a) Reminder from last week: Josepha has asked in the Team Reps channel for highlights from the last year, if you have any item you feel should be included about core’s achievements or items in progress, please add them to the comments on this post for @webcommsat and @hellofromtonya who are preparing the bullet points to send for core. Please do share any comments on this agenda.
b) Nominations for Core Team Reps: 2024 edition – reshare of the draft post to gather suggestions on timings related to the end date for nominations and the end of the voting period. The voting tool to use and whether an embedded voting block in discussion with other teams would be available for this edition to be finalized.
Please do consider whether you could stand for the core team repTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. for next year.
Following the conversation in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. chat a few weeks back (Oct. 25, Nov. 1), here are some proposed dates for releases in 2024. These are open to adjustment, but the current dates attempt to account for major holidays and WordPress events.
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 on Feb. 13, final release on Mar. 26 (WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia Mar. 7-9)
6.6 – Beta 1 on Jun. 4, final release on Jul. 16 (WordCamp Europe Jun. 13-15)
6.7 – Beta 1 on Sep. 24, final release on Nov. 5 (WordCamp US still TBD)
Given that 2024 will hold a bulk of the work for Phase 3, I expect that 6.5 and 6.7 will be focused on those Collaborative features. I would like to propose that 6.6 be held specifically for maintenance and general polish of the software (as was wished for earlier this year).
Leave your thoughts in the comments on timing, focus, or anything that you think is key to discuss! And as always If you’re interested in participating in a squad and want to know more, you can 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.”@davidbaumwald, @hellofromtonya, @jeffpaul, @priethor or any former release squad member you know!
This post kicks off the formal election process with a call for nominations for the 2024 CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team Reps. For 2023, Tonya Mork (@hellofromtonya) and Abha Thakor (@webcommsat) have served as the elected Core Team Reps.
The Roles
In the WordPress 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. project, each team has on average one or two representatives, abbreviated as reps. For the historians out there, the roles goes way back to 2012.
Historically with the Core team, the team repTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. duration was around a year, though some reps stuck around longer if there was a particularly good fit.
It is not called “team lead” for a reason. It’s an administrative role. While people elected as team reps will generally come from the pool of folks that people think of as experienced leaders, the team rep role is designed to change hands regularly.
This role has a time commitment attached to it of at least a one or two hours a week.
writing regular Core team recaps and posting it in the Updatesblogblog(versus network, site).
writing the Week in Core post. In 2023, this has been kindly continued to be done with thanks to previous team rep @audrasjb.
keeping a watch on the moving parts of the team to report for quarterly updates (example).
How the election works
Please nominate people in the comments of this post. Self-nominations are welcome. The deadline is 14 December 2023 at 23:59 UTC.
After that, a poll will be opened for voting. It will stay open for two weeks and close on 15 December 2023 at 23:59 UTC. The new reps will start their role in January 2024.
Disclaimer: if you are nominated, please don’t feel like you have to agree to say yes. The election poll will only include the names of the people who have agreed to be nominated. So feel free to reply with a “Thank you, but no thank you”.
If you have any questions, please feel free to ask in the comments or speak to the current team reps. Finally for reference, these are the 2020, 2021 and 2022 nomination posts.
This hallway hangout is a continuation of prior hallway hangouts in the FSE Outreach Program about release specific updates. In this session, we’ll talk through some of what’s to come in the next WordPress release with a proposed schedule for March 26th. This is being shared early to help encourage more folks to tune in and to build some excitement for this next release.
How to join
If you’re interested in joining, the Hallway Hangout will happen on 2024-01-16 21:00 . A Zoom link will be shared in the core-editorSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel before starting and all are welcome to join, whether to listen or participate, for as long or as little as you’d like. This will be recorded and recapped.
Agenda
At a high level, expect this to take the form of a free flowing demo/presentation going through as many release priorities as possible. @annezazu and @saxonafletcher will take point to demo and share what’s being worked on. Others might jump in to share as well depending on the roadmap post for 6.5 and where work stands by that point in the release cycle.
As a reminder, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind. Depending on how large the session is, we may not get to all questions live on the call but we can always include follow up in the recap.
At a high level, we will go through the following agenda:
Quick intros (what each person does/focuses on)
Review of WordPress performance improvements throughout 2023
Retrospective sharing field data for the cumulative performance impact of the team’s work in 2023
Discussion around interpretation of metrics
A look ahead to 2024 plans
As a reminder, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind along with any questions or items you want to discuss around this important area of the project, especially since the agenda is intentionally loose to allow for it.
WordPress 6.4 introduces 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.HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. (#53987), a feature that provides an extensibility mechanism for Block Themes. This is the first step in emulating WordPress’ Hooks concept that allows developers to extend Classic Themes using filters and actions.
Specifically, the Block Hooks 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. allows a block to automatically insert itself relative to instances of other block types. For example, a “Like” button block can ask to be inserted before the Post Content block, or an eCommerce shopping cart block can ask to be inserted after the Navigation block.
Tenets and current limitations
There are two coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. tenets of Block Hooks:
Front-end insertion should happen as soon as the 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 containing a hooked block is activated. In other words, the user isn’t required to insert the block in the Editor manually. Similarly, disabling the plugin should remove the hooked block from the front end.
The user has the ultimate control over any automatically inserted blocks. This means that a hooked block is visible in the Editor, and the user’s decision to keep, remove, customize, or move the block will be respected and reflected on the front end.
To account for both tenets, tradeoffs had to be made. Block hooks are limited to templates, template parts, and patterns (i.e., the elements that define the layout of the theme). For patterns, this includes those provided by the theme, from Block Pattern Directory, or from calls to register_block_pattern.
Blocks cannot be hooked into post content or patterns crafted by the user, such as synced patterns or theme templates and template parts that the user has modified.
Furthermore, as of WordPress 6.4, you can’t automatically insert blocks that have a save function, or block validation errors will occur. In colloquial terms, this means that Block Hooks work with Dynamic blocks, not Static blocks. Refer to this article on the difference between the two.
Using Block Hooks
You can implement Block Hooks in two different ways: in a block’s block.json file or using the new hooked_block_typesfilterFilterFilters 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.. While simpler, the block.json method provides a more limited implementation, so let’s review that first.
block.json
The block.json method allows you to hook a third-party block unconditionally, meaning that the block will be inserted relative to all instances of the target (anchor) block provided the abovementioned limitations.
In the block’s block.json file, include the blockHooks property. This property takes an object where the key (string) is the name of the block you want to hook into, and the value (string) specifies its position. Possible positions are:
before – inject before the target block.
after – inject after the target block.
firstChild – inject before the first inner block of the target container block.
lastChild – inject after the last inner block of the target container block.
In the example above, the block will be inserted before every Verse block that appears in an unmodified template, template part, or pattern. It will also be inserted after every Spacer block, etc.
When using the block.json method with firstChild or lastChild, a Setting SidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. panel titled Plugins will be added to the target block in the Editor. This allows the user to toggle on and off the hooked block.
Below is an example of a Like button block that is hooked to the lastChild position in the Comment Template block.
hooked_block_types
The hooked_block_types filter provides more flexibility. It allows you to hook any Dynamic block unconditionally, like the block.json method, or conditionally based on the template, template part, or pattern where the target (anchor) block is located.
The callback function for the filter accepts four parameters:
$hooked_blocks(array) – An array of hooked blocks.
$position(string) – The relative position of the hooked block: before, after, first_child, or last_child.
$anchor_block(string) – The name of the anchor block.
$context(WP_Block_Template|array) – The block template, template part, or pattern the anchor block belongs to.
Below are a few examples using the Like button block plugin (ockham/like-button) built to demonstrate Block Hooks functionality in a third-party block. The pattern example does require the Twenty Twenty-Four theme.
function example_block_hooks( $hooked_blocks, $position, $anchor_block, $context ) {
// Template/Template Part hooks.
if ( $context instanceof WP_Block_Template ) {
// Hooks the "Like" button block before the Post Title in the Single template.
if (
'core/post-title' === $anchor_block &&
'before' === $position &&
'single' === $context->slug
) {
$hooked_blocks[] = 'ockham/like-button';
}
// Hooks the Login/Logout link block after the Navigation block if the context of the template part is a header.
if (
'core/group' === $anchor_block &&
'last_child' === $position &&
'header' === $context->area
) {
$hooked_blocks[] = 'core/loginout';
}
}
// Pattern hooks.
if ( is_array( $context ) && isset( $context['slug'] ) ) {
// Hooks into the Post Meta pattern in the Twenty Twenty-Four theme.
if (
'core/post-terms' === $anchor_block &&
'after' === $position &&
'twentytwentyfour/post-meta' === $context['slug']
) {
$hooked_blocks[] = 'ockham/like-button';
}
}
return $hooked_blocks;
}
add_filter( 'hooked_block_types', 'example_block_hooks', 10, 4 );
It’s important to note that $context will be an object of type WP_Block_Template for templates and template parts and an array for patterns. If you want to insert blocks conditionally using this parameter, make sure to check the parameter type before applying hooking blocks.
You will also note that you can only specify the name of the block that is being hooked. There is no way to set the attributes of the hooked block, so only the default instance of the block is inserted. Future improvements to Block Hooks will likely account for this limitation and others, providing a robust way for developers to extend Block Themes.
For more information on what additional features are currently being worked on, stay tuned to the tracking issue for Block Hook improvements.
You must be logged in to post a comment.