The next default theme
A new default theme is usually included in the last major release of the year.
The lead designer and lead developer are part of the release squad. The design is selected and approved by project lead Matt Mullenweg before the development of the theme starts.
For the past 3 years, the development of the theme has been open to all contributors.
Ways to contribute to the default theme:
Suggesting features
You can suggest features that you want the theme to include.
The theme follows the same release cycle as WordPress core. A feature suggestion needs to be submitted as early in the release as possible for the developers to have time to consider and work on implementing your suggestion.
Testing and reporting issues
The earlier the testing starts, the better chance that theme is released with as few bugs as possible.
Testing the accessibility of the theme should be prioritized.
Contribute with code
You can help develop new features and solve issues that have been reported. You can review pull requests and review existing code for potential problems.
Contribute by writing copy and documentation
Every theme needs a theme description. Copy also needs to be written if the theme includes starter content and block patterns.
It is important that all text that is used for custom options and instructions is relevant and easy to understand.
The default theme has an official support page which needs to be complete for Release Candidate 1.
When writing text for the theme, use sentence casing and not title case.
When possible, keep texts consistent with previous default themes.
Helpful tips for theme squad leads
Orientation
One of the most important things when creating the default theme is knowing who to contact when you have questions about the release, and also who you can contact for commits.
For information about the release cycle, beta releases and release candidates, see: https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/#pre-beta-1
Meetings
Decide how often and when to hold meetings. Meetings take place in Slack in the #core-themes channel. You can schedule separate bug scrubs or you can do this as part of the meeting. You can also decide if you want to post meeting agendas before each meeting.
Instead of using private channels, try to keep discussions public in the #core-themes channels so that more people have a chance to get involved and contribute.
Requesting access
You will need access to the Core blog to be able to post updates, meeting agendas or calls for testing.
Access to using the /here command for the #core-themes Slack channel is needed for meetings.
To work on theme related Trac issues, you may also need increased “bug gardening” privileges for the Core Trac.
Decisions not options
It is important to limit the number of options in the theme. The theme needs to be user-friendly both to new and experienced users.
Accessibility and theme review requirements
The default theme needs to be accessibility-ready, and aim to comply with WCAG 2.2 AA. Accessibility needs to be included in the design and development process from the start and can not be added at the last minute.
Please also read the accessibility requirements for a theme to be included in the WordPress.org Theme Directory.
Versioning
The bundled themes use a version system with two numbers: 1.0.
GitHub Repository
The theme development takes place in a dedicated GitHub repository that is part the WordPress organisation. You will need administrative rights to be able to invite contributors and in turn grant them the rights they need to help you with the development and triage.
Development is moved to the Core Trac at a point that you decide. With the final release of the WordPress version, the GitHub repository is archived.
Giving props
To make sure that all contributors receive credits (props) for their work, you need to keep a list of their WordPress.org usernames. In the GitHub repository, this can be saved in a Contributors.md file. Example: https://github.com/WordPress/twentytwentyone/blob/trunk/CONTRIBUTORS.md
Packaging the theme for a release
Before the first beta version, create a ticket in the Core Trac for adding the theme to the WordPress package.
Example Trac tickets: https://core.trac.wordpress.org/ticket/51526, https://core.trac.wordpress.org/ticket/48110
Prepare the theme (preferably the day before the release to avoid any delays) and either create a GitHub pull request on WordPress-develop, or create a patch that can be added directly in Trac.
The benefit of using GitHub is that you will see the result of the automated tests right away.
For Beta releases, you will add the patch/pull request to WordPress trunk.
To make changes during the release candidates, you need sign off from two committers. These changes should be bug fixes for things found during the RC.
In the description of the pull request or patch, include the list of usernames that should receive props for contributing to the theme.
When the pull request has been made, contact a committer who can add the theme to the WordPress package.
Maintaining bundled themes
Bundled themes are the current and previous default themes that are included when you install WordPress.
You can contribute to improving the themes by:
- Opening issues in the Core Trac ticket system when you find problems
- Ticket triage
- Submitting fixes
Trac
You can find the current open tickets in the Bundled Theme component: https://core.trac.wordpress.org/query?status=!closed&component=Bundled+Theme
You can also search the Core Trac using a specific theme name. Before opening a new issue, make sure that it is not already reported.
Stylesheet changes
If you are working on a bundled theme that has precompiled style files, for example Twenty Twenty-One, please make your patch in the .scss file not directly in the stylesheets.
For committers making changes you can compile any stylesheet using the following steps:
- Apply the patch.
- In the theme run ‘
npm install‘ then ‘rpm run build‘.
Learn more about Trac:
Triage
Please see the dedicated triage page here: https://make.wordpress.org/themes/handbook/get-involved/themes-triage/
The goal of a triage session is to help move tickets closer to being fixed or closed.
When triaging theme-related tickets, first confirm that it is a theme-related issue and not a support question or a bug in a different component.
Submitting fixes
If you want to submit a patch to solve an issue, you may find it easier to use GitHub instead of Trac.
You can find detailed information about submitting a GitHub pull request for an open Trac ticket here:
More resources