Contribute to Core at WordCamp Europe Contributor Day 2023

What does the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team do?

Core is made up of contributors from many different areas and teams across WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. Because Core is made up of many different components and parts, there is a ton of overlap with the other Make teams (polyglots, themes, plugins, metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., etc.). It is an exciting and dynamic place to observe or contribute.

The team holds a weekly developer chat in the Make WordPress #core channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. every Wednesday at 20:00 UTC.

New Contributor Meetings are held in the same channel on the 2nd and 4th Wednesdays just prior to the weekly developer chat at 19:00 UTC.

What areas of Core will I be able to work on at WordCampWordCamp WordCamps 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. Europe 2023?

The Core team and the Core WordPress software is segmented in a number of ways. While there will be some community leaders present representing some specific parts of the Core team, you can contribute to any of these segments at Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. and there will likely be several contributors experienced in these areas. These are the most common ways that you’ll see Core divided.

Components

Currently, there are 62 components and sub-components within Core. These represent overarching categories of functionality within the code base. Some examples of these are Database, External Libraries, TaxonomyTaxonomy A 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., Feeds, etc. A handful of components also have sub-components. For example, Embeds, Gallery, and Upload are sub-components of the Media component.

Focuses

In TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., there are also several focuses. Focuses are disciplines or concepts that span many components, or even the entire Core code base. Some examples of these are accessibility, coding-standards, rest-api. Contributors that specialize in these focuses often work with many different component maintainers.

Sub Teams

There are also a few contributor groups that are still technically under Core, but operate as their own team. Some examples of this are Editor, Performance, AccessibilityAccessibility Accessibility (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). These sub teams will each be represented by table leads at contributor day.

Preparing for Contributor Day before leaving home

Register for a WordPress.org profile and the WordPress.org Slack instance

The large majority of the communication around contributing to the WordPress open sourceOpen Source Open 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. projects happens on WordPress.org or in the WordPress Slack instance. Your first step should be to register for both in that order.

There are 5-minutes videos to help you get started with the tools of communications. The Marketing Team with other contributors has been making different versions on this in a number of languages.
Set up a WordPress.org and Slack account for the Make WordPress Channel.

A majority of the Core components and sub teams also have their own channels within the WordPress Slack instance.

Install required software to contribute to the code

For those who would like to contribute by way of writing or checking code, the most popular method is by having a local development environment installed on your system.

Installing local environments are likely to be easier and quicker before you arrive at the conference venue. Conference WiFi can often be unreliable or be over-burdened. Getting set up before the event can help reduce the time you will spend installing and setting up the software on the day. You can then get onto more interesting things when you are at the conference!

In order to contribute to Core from a development perspective, you will need the following software installed on your machine:

  • GitGit Git 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/. or SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. (whichever you prefer)
  • NodeJS (WordPress currently requires NodeJS 14.x)
  • npm (comes bundled with NodeJS)
  • Composer (optional, but highly recommended)

Additionally, you will need to choose one of the following:

Note: There are other tools that can be used to set up a local development environment (such as Local), but the two above are the ones maintained and have official support.

Decide how you’re going to work with the codebase

There’s a few options for you to work with the wordpress-develop codebase.

Note: if you chose the Vagrant/Virtualbox/VVV option above, the default is the third option below, but you can change that later.

Forking WordPress/wordpress-develop on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/

This option will allow you to submit and work within a pull request on GitHub. When using this option, all of the configured automated testing will run on your code to help verify your change. You can read more about this option in the Core Handbook.

Using WordPress/wordpress-develop directly

With this option, you’ll clone the wordpress-develop repository locally and use that as your codebase. You won’t be able to push any changes or submit pull requests, but you will be able to create patches with your changes to submit on Trac.

Using SVN to check out WordPress

With this option, you’ll checkout the `trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.` branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of the develop.svn.wordpress.org repository to use as your local WordPress site. Any changes you make need to be submitted as patches.

Docker Option

Below are the basic steps to get started with the local Docker environment:

  1. Clone your repository of choice from the previous section. If you’re using a fork that you created, the command will look like this: git clone git@github.com:{your GitHub username}/wordpress-develop
  2. Run cd wordpress-develop to move into the directory created by the git clone.
  3. Run npm install to install dependencies
  4. Run npm run env:start to start the development environment
  5. Run npm run env:install to set up clean installation with the user adminadmin (and super admin) and the password password
  6. Run npm run build:dev to run a build.

You can now load WordPress:

Frontend: http://localhost:8889

Backend: http://localhost:8889/wp-admin/

  • Username: admin
  • Password: password

You will find these steps and more details in the project’s README.md file.

Varying Vagrant Vagrants option

You will find detailed instructions for how to get started on the project’s website.

Other tips

  • Running npm installvagrant up, or npm run env:start can be networknetwork (versus site, blog) intensive. Run these at home before you leave for the event and confirm everything’s working as expected. Depending on what you work on during Contributor Day, you may need to run these commands again. But having dependencies, virtual boxes, and containers cached locally will greatly decrease the time they take to run at the event.
  • Try creating patches or a PR ahead of time. If you’re able to start working on a ticketticket Created for both bug reports and feature development on the bug tracker. before the event, contributors at the event can give you feedback on your work so far.
  • Read about finding bugs to fix and identify any you are interested in prior to heading to the event.
  • The ‘good first bugs‘ report in Trac is a great place to find easier tickets to get your feet wet. There’s also a similar list of “good first issues” for Gutenberg.
  • There is also now support for GitHub Codespaces to contributor to Core.

Helpful links

Below are a handful of other helpful links that will help you be better prepared for Contributor Day.


Many thanks to all the contributors who helped with materials for this post – as ever with WordPress, it is a real team effort! Special thanks to @desrosj who collected much of the preparation information, to @wpscholar for sharing his more detailed document from a previous WordCamp, and to @webcommsat who pulled together the material from different editions. Thanks also to @sergeybiryukov, @jeffpaul and @webcommsat for review and contributions, and to @audrasjb, @paulbearne, @mark99, @vimes1984, @meher, @oglekler for contributions and review for material used from previous editions of this post. Thanks to @davidbaumwald, @joemcgill for review of the checklist.

After WordCamp Europe, a version of this post will be added to the Core Team Handbook.

#contributor-day

WordPress 6.4 Development Cycle

WordPress 6.4 will be the third major release of 2023. The following release team and its cohorts are contributors who answered the call for leadership volunteers and interest. This release aims to galvanize participation and shared ownership for those that identify as gender-underrepresented in the WordPress open sourceOpen Source Open 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. 

This post is shared earlier than in past releases to encourage new contributors to engage now and shadow the 6.3 release and consider whether you, too, would like to join the merry 6.4 cohort of contributors.

Release team

All release decisions will ultimately be this release team’s to make and communicate while gathering input from the community.

Release Cohort 

The Release Cohort are those contributors who committed to assisting the release team and supporting the goal of the gender-underrepresented lead release by spearheading efforts in their respective focuses. All contributions from all community contributors are welcome, whether you are part of a cohort or can contribute to a single PR. 

Release Schedule

April 7, 20236.4 Pre-planning post.
June 5, 2023Developer Cycle post.
July 18-25, 2023Alpha Begins, Trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. is opened. 
September 26, 2023BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1. From this point on, core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. will focus on testing and fixing bugs discovered during beta testing. Begin writing Dev Notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and the About page (SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. archive, ZIP download).
October 3, 2023Beta 2. Test the beta release, fix bugs discovered during beta testing, and continue writing Dev Notes and the About page (Slack archive, ZIP download).
October 10, 2023Beta 3. Test the beta release, fix bugs discovered during beta testing, and continue writing Dev Notes and the About page (Slack archive, ZIP download).
October 17, 2023Release candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1. Publish the Field GuideField guide The 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. with Dev Notes, commit the About page, begin drafting the release post, hard string freeze, and branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". for the release. (Slack archive, ZIP download).
October 24, 2023Release candidate 2. Update the About page images and continue drafting the release post (Slack archive, ZIP download).
October 30, 2023Release candidate 3. Update the About page images and continue drafting the release post (Slack archive, ZIP download).
November 6, 2023Dry run for release of WordPress 6.4 and 24-hour code freeze (Slack archive).
November 7, 2023WordPress 6.4 is released (Slack archive, ZIP download)!

How to contribute

To get involved in WordPress core development, head over to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., and shadow a 6.3 ticket by subscribing to and watching how contributors patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., test, comment, and commit as part of the release cycle. Need help? Check out the Core Contributor Handbook.

If you want to dive deeper into the upcoming WordPress versions, join the weekly meetings in the #core Slack channel, which occur next every Wednesday at 20:00 UTC, and the editor-focused meetings in the #core-editor Slack channel, every Wednesday at 14:00 UTC.

Proposal: Retiring Older Default Themes

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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. The burden of maintaining these themes has historically fallen on the CoreCore Core 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

  1. 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 build each theme out on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ over the course of 1-3 months before it’s merged into the WordPress Core SVNSVN Subversion, 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.
  2. 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.
  3. 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 Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. 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 PHPPHP The 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 JavaScriptJavaScript JavaScript 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.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/) 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes.
  • 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 TracTrac An 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.

Props @jeffpaul, @flixos90, @poena, @annezazu, @jorbin, @chanthaboune, @joemcgill, @azaozz for contributing to this post through providing feedback and proof reading.

#bundled-theme, #themes

Gutenberg 15.9.1 is now available

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 15.9.1 has been released and is available for download!

This minor version includes two fixes.

Custom fonts are back again visible on the editor (51178)

There was a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. on Gutenberg 15.9 that prevented the fonts to be loaded on the editor.

Social icon colors now correctly reflect changes in Global Styles (51020)

Social Icons colors where not changing with styles variations.

Contributors

Props to @hellofromtonya and @ndiego for their contributions and to @cbringmann for proofreading.

#core-editor, #gutenberg

WordPress 6.3 Planning Roundup

Following the planning proposal, this post summarizes the release schedule and squad composition for the next major WordPress release – 6.3. The proposal saw an overwhelmingly high number of volunteers; thank you to everybody who raised their hand to participate and help make WordPress the amazing project it is. 🤝

WordPress 6.3 Schedule

The schedule remains as originally proposed. There was some discussion around the date for BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2 and the US Independence Day: while the planned date stays the same, the final Beta 2 date can be adjusted by the release squad depending on the availability of contributors around that date.

MilestoneDate
Alpha (trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. open for 6.3 release)March 9, 2023
Beta 1June 27, 2023
Beta 2July 3, 2023
Beta 3July 11, 2023
Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1July 18, 2023
Release Candidate 2July 25, 2023
Release Candidate 3August 1, 2023
Dry RunAugust 7, 2023
WordPress 6.3 General ReleaseAugust 8, 2023

WordPress 6.3 Release Squad

Thanks once again to everybody that volunteered for the release squad! Considering all applications for the different roles, a release team has been assembled with input from project leadership to ensure all aspects of the release are properly covered.

The release team has been expanded in a few areas. In particular, the Core and Editor Triage Lead roles have been increased compared to past releases, allowing the squad to run bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs in different time zones and triage all around the world!

Unfortunately, even such a big release squad cannot accommodate all raised hands. Contributors are more than welcome to ride along with the release process on the #6-3-release-leads SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel, especially in preparation for participating in 6.4 and future release squads. However, all release decisions will ultimately be the release team’s to make.


Props to @chanthaboune and @cbringmann

#6-3, #planning

Editor chat summary: 31 May, 2023

This post summarizes the weekly editor chat meeting (agenda for 31st of May meeting) held on Wednesday, May 31 2023, 03:00 PM GMT+1 in Slack. Moderated by @andraganescu.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 15.9 has been released

Key project updates:

No updates of Key Projects during the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor meeting.

Task Coordination

Task coordination was not held due to low attendance.

Open Floor

@alexstine

Looking to get early feedback on Writing flow: Try arrow press confirmation before switching blocks – a change that would bring much better keyboard accessibilityAccessibility Accessibility (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) to all editors. Please add your thoughts. Positive or negative, I want to hear. If you think it should be done differently, happy to hear that too.

@mamaduka

Last week I published a proposal for the new registerBlockSupport APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. and looking for some feedback – Proposal: The registerBlockSupport API

@cbravobernal

Any help with this regression will be highly appreciated – Fonts not loading in page/site editor with Gutenberg 15.9 RC1

Read complete transcript

#core-editor, #core-editor-summary, #gutenberg, #meeting-notes, #summary

Command Center: Request for feedback

As the Site Editor and WP-Adminadmin (and super admin) get more and more features, the need to navigate quickly and efficiently across them is becoming increasingly important. Visual editors and code editors alike are adopting the command center as a solution to this problem, with examples such as Visual Studio Code for desktop applications and Notion in the web applications spectrum.

Prototype

Initially proposed as part of the WP-Admin experience revamp post, an early prototype of a command center has now been implemented as an experiment in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, starting in Gutenberg 15.6. Once enabled in Gutenberg > Experiments, you can navigate to the Site editor and hit the cmd + k (or ctrl + k on Windows and Linux) shortcut to open the command center, run commands and quickly access frequently used actions.

Initially implemented in the Post and Site editors, the command center is meant to be added to all of WP-Admin in the future.

We would love to hear your feedback on this feature and its APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.:

  • How does the user experience feel? (The feature will be tested in the FSE Outreach Program).
  • Are the APIs (detailed down here) capable enough to address third-party use-cases?

To follow progress and provide feedback, please refer to this issue on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/: https://github.com/WordPress/gutenberg/issues/48457.

API

Note: The following API is available in Gutenberg trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. and will be included in the next Gutenberg release. As it’s an early prototype, both design and API changes are possible before the API lands in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in the next WordPress release.

One aspect worth highlighting is the proposed API to interact with the command center. The command center has been developed as an independent @wordpress/commands package. It offers APIs to render and register commands dynamically. These extension points allow plugins to inject any commands of their liking and opens the door for interactions with LLMs, as outlined in this previous post.

There are two ways to register commands: static commands and dynamic commands.

Static commands

Static commands can be registered using the wp.data.dispatch( wp.commands.store ).registerCommand action or using the wp.data.useCommand ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. hook. Both methods receive a command object as an argument, which provides a unique name, a label, an icon, a callback function that is called when the command is selected, and potentially a context.

Example:

wp.commands.useCommand( {
	name: 'add new post',
	label: __( 'Add new post' ),
	icon: plus,
	callback: () => {
		document.location.href = 'post-new.php';
	},
} );

Dynamic commands

Dynamic commands, on the other hand, are registered using “command loaders.” These are needed when the command list depends on the search term entered by the user in the command center input. For example, when a user types “contact”, the command center need to filterFilter Filters 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. the available pages using that input.

Example:

function usePageSearchCommandLoader( { search } ) {
	// Retreiving the pages for the "search" term
	const { records, isLoading } = useSelect(
		( select ) => {
			const { getEntityRecords } = select( coreStore );
			const query = {
				search: !! search ? search : undefined,
				per_page: 10,
				orderby: search ? 'relevance' : 'date',
			};
			return {
				records: getEntityRecords( 'postType', 'page', query ),
				isLoading: ! select( coreStore ).hasFinishedResolution(
					'getEntityRecords',
					[ 'postType', 'page', query ]
				),
			};
		},
		[ search ]
	);

	// Creating the commands
	const commands = useMemo( () => {
		return ( records ?? [] ).slice( 0, 10 ).map( ( record ) => {
			return {
				name: record.title?.rendered + ' ' + record.id,
				label: record.title?.rendered
					? record.title?.rendered
					: __( '(no title)' ),
				icon: icons[ postType ],
				callback: ( { close } ) => {
					const args = {
						postType,
						postId: record.id,
						...extraArgs,
					};
					document.location = addQueryArgs( 'site-editor.php', args );
					close();
				},
			};
		} );
	}, [ records, history ] );

	return {
		commands,
		isLoading,
	};
}

useCommandLoader( {
	name: 'myplugin/page-search',
	hook: usePageSearchCommandLoader,
} );

Contextual commands

Commands can be contextual. This means that in a given context (for example, when navigating the site editor, or when editing a template), some specific commands are given more priority and are visible as soon as you open the command center. And when typing the command center, these contextual commands are shown above the rest of the commands.

At the moment, two contexts have been implemented:

  • site-editor This is the context that is set when you are navigating in the site editor (sidebarSidebar A 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. visible).
  • site-editor-edit This is the context that is set when you are editing a document (template, template part or page) in the site editor.

As the usage of the Command Center expands, more contexts will be added. 

To attach a command or a command loader to a given context, it is as simple as adding the context property (with the right context value from the available contexts above) to the useCommand or useCommandLoader calls.


The command center and its API will be valuable additions to WordPress Core, and any feedback you have to offer will be greatly appreciated.

Thank you for your continued support and contributions to WordPress.

Props @annezazu and @priethor for the post review. and @jameskoster for the video

#gutenberg

Editor Chat Agenda: 31st May 2023

Facilitator and notetaker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, May 31 2023, 03:00 PM GMT+1. This meeting is held in the #core-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

What’s new in Gutenberg 15.8? (May 17)

Key project updates:

Task Coordination.

Open Floor – extended edition.

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • If you have an update for the main site editing projects, please feel free to share as a comment or come prepared for the meeting itself.
  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

get_page_by_title() deprecated

In WordPress 6.2, the get_page_by_title() function has been deprecated in favour of using WP_Query (#57041). Unlike the deprecated function, WP_Query can only be run after plugins and pluggable functions have loaded, on the plugins_loaded action or later.

Due to limitations with the deprecated functions database query, it could return different results depending on the database version and/or engine used. Switching to WP_Query will ensure you receive the same results regardless of the setup of your server.

To achieve an equivalent database query via WP_Query, the following arguments can be used.

$query = new WP_Query(
	array(
		'post_type'              => 'page',
		'title'                  => 'Sample Page',
		'post_status'            => 'all',
		'posts_per_page'         => 1,
		'no_found_rows'          => true,
		'ignore_sticky_posts'    => true,
		'update_post_term_cache' => false,
		'update_post_meta_cache' => false,
		'orderby'                => 'post_date ID',
		'order'                  => 'ASC',
	)
);

if ( ! empty( $query->post ) ) {
	$page_got_by_title = $query->post;
} else {
	$page_got_by_title = null;
}

The same result can also be achieved via the get_posts() wrapper for WP_Query(). In this case, you can replace the code with the following:

$posts = get_posts(
	array(
		'post_type'              => 'page',
		'title'                  => 'Sample Page',
		'post_status'            => 'all',
		'numberposts'            => 1,
		'update_post_term_cache' => false,
		'update_post_meta_cache' => false,			
		'orderby'                => 'post_date ID',
		'order'                  => 'ASC',
	)
);

if ( ! empty( $posts ) ) {
	$page_got_by_title = $posts[0];
} else {
	$page_got_by_title = null;
}

Ensuring the page is accessible

Due to the database query used by get_page_by_title(), it was possible the result returned from the database was not intended to be accessible by the user and that linking to the result would lead to a File Not Found error.

The code above reproduces this behaviour. If you wish to avoid this edge, then leave the post_status parameter out of the code above will resolve your issue.

Props to @afragen@spacedmonkey, @milana_cap, @bph@webcommsat for proofreading.

#6-2, #dev-notes

Performance Chat Agenda: 30 May 2023

Here is the agenda for this week’s performance team meeting scheduled for May 30, 2023 at 15:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat