Controlling Plugin and Theme auto-update email notifications and Site Health infos in WP 5.5

This is the second part of the plugins and themes auto-updates 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 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. for WordPress 5.5. The first part was dedicated to Controlling Plugins and Themes auto-updates user interface.

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 and Theme auto-update email notifications

As of WordPress 5.5, email notifications will be sent after each attempt to auto-update a plugin or theme regardless of outcome (success or failure).

Here’s what you need to know about these emails.

Filtering the emails

Using the auto_plugin_theme_update_email hook, the recipient, subject, headers, and email content can be filtered to adjust a site’s needs.

Example of use:

<?php
function myplugin_auto_plugin_theme_update_email( $email, $type, $successful_updates, $failed_updates ) {
	// Change the email recipient.
	$email['to'] = 'admin@example.com';
	// Change the email subject when updates failed
	if ( 'fail' === $type ) {
		$email['subject'] = __( 'ATTN: IT Department – SOME AUTO-UPDATES WENT WRONG!', 'my-plugin' );
	}

	return $email;
}
add_filter( 'auto_plugin_theme_update_email', 'myplugin_auto_plugin_theme_update_email', 10, 4 );

Repeated failures email notifications prevention

Sometimes, a specific update may fail multiple times. When this happens, a notification email will be sent for only the first failure. A failure is considered a repeat when attempting to update to the same version.

For example, if version 1.0.1 fails and then 1.0.2 is released and fails, that is not a repeat failure.

For more information, see #50448 on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Disabling email notifications

Email notifications can be disabled using two filters:

  • auto_plugin_update_send_email
  • auto_theme_update_send_email

Emails are enabled by default (true). Returning false to either 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. will disable email notifications for that auto-update type.

The following snippet can be used to disable email notifications for themes and/or plugins auto-updates.

<?php
// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

Auto-updates information in Site Health

Each plugin and theme’s auto-update status is also surfaced on the Site Health “Info” tab.

This text can be adjusted using the plugin_auto_update_debug_string and theme_auto_update_debug_string filters.

The following example replaces the text for the status of auto-updates for plugins:

<?php
function myplugin_plugin_auto_update_debug_string( $text, $plugin, $enabled ) {
	if ( false === $enabled ) {
		return __( 'Please consider turning on auto-updates!', 'my-plugin' );
	} else {
		return __( 'Thanks for enabling auto-updates!', 'my-plugin' );
	}
}
add_filter( 'plugin_auto_update_debug_string', 'myplugin_plugin_auto_update_debug_string', 10, 3 )

The following example replaces the text for the status of auto-updates for themes:

<?php
function mytheme_theme_auto_update_debug_string( $text, $active_theme, $enabled ) {
	if ( false === $enabled ) {
		return __( 'Please consider turning on auto-updates!', 'my-theme' );
	} else {
		return __( 'Thanks for enabling auto-updates!', 'my-theme' );
	}
}
add_filter( 'theme_auto_update_debug_string', 'mytheme_theme_auto_update_debug_string', 10, 3 )

Please note: Site Health support was introduced in the Feature Plugin, so there is no Changelog/Trac ticketticket Created for both bug reports and feature development on the bug tracker. to link.

Reviewed by @pbiron and @desrosj

#5-5, #dev-notes

Discussion: align the WordPress release cycle with the industry standard

The standard software release life cycle hasn’t really changed much since the beginning of programming.

WordPress, for the most part, attempts to closely follow the established pattern, with the exception of what can get committed in 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..

For the past year, there have been conversations in Slack and in the blog about the release cycle. Here is a recap post with a call for feedback.

The WordPress Release Cycle – Today

Each release cycle spans multiple weeks and different phases.

Phase 1: Planning and securing team leads

This period starts as soon as a 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". is created for the previous version (the code is copied from “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.” to a new “branch” in the repository), which means that two major WordPress versions are worked on at the same time. For example, active development on WordPress 5.6 started about two weeks prior to the WordPress 5.5 release. 

During this phase, the release leadRelease Lead The community member ultimately responsible for the Release. discusses features for the next release of WordPress. Contributors get involved with that discussion. The release lead will identify focus leads for each of the features. Information is gathered from different sources to put together a scope and schedule, followed by a kickoff post.

Phase 2: Development work begins

The kick-off post (see an example from WordPress 5.6) marks the beginning of structured, organised work towards Beta. The length of the period might vary, based on what was achieved during the period before the announcement and what is planned for the release.

Focus leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.

Phase 3: Beta 

Betas are released and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are allowed for the rest of the release.

WordPress generally plans for multiple betas.

Phase 4: 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).

In WordPress, release candidates are considered code complete, so no new source code is introduced unless it is to fix regressions or serious bugs discovered during RC. Even then, every commit during this phase needs sign-off from two CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers.

This means hard-freeze on all strings, including those in the About page. It is important to do so to allow the Polyglots team to have enough time to translate it.

During this phase, a new branch will be created thus starting a new release cycle while we are finishing the current.

Phase 5: Launch

This is the final version that is launched and available for update through the dashboard or via download.


How to align the WordPress release cycle with the industry standard

With this in mind, here are the changes that could be put in place to align the WordPress release cycle with the traditional software release cycle.

Phase 1: Preliminary Planning

Stays the same in terms of tasks. Can be renamed “Preliminary planning” for brevity and clarity.

Phase 2: Alpha

While traditionally priority has been given to enhancements and new features, it would be beneficial to address also all the 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 that are planned for inclusion in the version of WordPress people are working on. 

Changes

  • Rename to “Alpha” for brevity and clarity.
  • All the bugs that people want to see fixed in the next release need to be addressed in this phase and not postponed to Beta.

Phase 3: Beta

This is where WordPress differs from the standard. 

Historically, 

Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs.

Wikipedia

Beta is essentially for testing and fixing bugs discovered after the release of Beta 1 (so bugs introduced in Alpha).

Changes

  • Hard freeze on Beta (ETA code and strings), except for the About page.
  • The tickets that were not committed and are still on the milestone at the time of Beta 1 release party, should be moved to a later release, even if they are bugfixes.

Benefits

  • Virtually no new bugs are introduced during Beta. This means focus on testing and subsequent bug fixing. 
  • More efforts and resources could be allocated to beta-testing. 
  • Beta and RC could be and should be fewer and shorter. This is because we address only bug fixes that emerged during beta testing. 
  • Aligning to the norm makes it easier for new people to join since they are used to a certain procedure and they won’t be confused by the way releases are done in WordPress.

Phase 4: Release Candidate

No changes

Phase 5: General Release

Stays the same in terms of tasks. Can be renamed to “General Release” for clarity.

It’s your turn!

Disclaimer: even if everyone is on board, nothing will change for the current release cycle, WordPress 5.6, because we are already in Beta. 

Please post feedback on:

  1. Name changes for Phase 1, 2 and 5
  2. All bug-fixes milestoned to be addressed in Alpha and not postponed to Beta 
  3. Reserving Beta for testing and fixing bugs discovered by testing

Deadline: November 17th, the date scheduled for Release Candidate 1 of WordPress 5.6 and, potentially, when trunk gets branched for 5.7.

Thanks!

Props @azaozz, @davidbaumwald, @joostdevalk and @ireneyoast for providing historical and technical knowledge on release cycle procedures, and @chanthaboune and @jeffpaul for editing suggestions.

#release-process

Twenty Twenty-One Test Scrub

As part of the 5.6 release, we’ll be hosting a Twenty Twenty-One focused test scrub today Friday, October 30, 2020, 13:30 UTC in the #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/..

What we will test

1. Image 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.https://github.com/WordPress/twentytwentyone/issues/737 – to test this issue, you need WP 5.6 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 + latest version (trunk) of the theme
2. Dark-mode toggle: https://github.com/WordPress/twentytwentyone-dark-mode/issues/1#issuecomment-718679339 – to test this issue, you need WP 5.6 Beta 2 + latest version (trunk) of the theme + dark mode toggle plugin
3. 2 untested blocks > Group and column https://github.com/WordPress/twentytwentyone/issues/72

How we will test

  • We will go through each item as a group.
  • We will create a thread in Slack for each items where you can post the results. This will make it easier to reply in the existing issues or create new ones.

See you later!

#5-6, #bug-scrub, #test, #twenty-twenty-one

Call for testing: PHP 8.0

A long-standing goal of the WordPress project is to be compatible with new versions of PHP on their release day. The next major version of PHP (version 8.0) is currently scheduled for release on November 26, 2020. WordPress 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. are working to ensure PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 8.0 is supported in the next major version of WordPress (version 5.6), which is currently scheduled to be released on December 8, 2020.

PHP 8.0 has been in the making for some time and brings a lot of exciting features. But because PHP 8.0 is a major version release, it also includes some backward incompatible changes. Because of this, a great deal of both manual and automated testing is needed in order to ensure the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. codebase is ready for PHP 8.0.

Even though WordPress 5.6 will add support for PHP 8.0, no changes will be made to the minimum required version of PHP at this time. Any changes made to provide support for PHP 8.0 will be done in a way that maintains backward compatibility for all versions of PHP supported by WordPress (currently to PHP 5.6.20).

Your help is needed to test WordPress on PHP 8.0! While contributors are working on addressing incompatibilities that can be identified by looking at the PHP release notes and upgrade guides, some issues will need to be found through manually testing.

Timeline for testing

Since changes for PHP 8.0 compatibility may be extensive, November 17, 2020 (the current planned date for 5.6 RC 1) should be seen as the cut off date for the change to be included in WordPress 5.6. To ensure that changes receive proper testing, patches and pull requests should be submitted as soon as possible.

How to test WordPress on PHP 8.0

There are a few ways that you can test WordPress on PHP 8.0. Some more experienced developers may prefer to install PHP 8.0 manually on their own. But below are instructions for what is likely the quickest and easiest way for most contributors to get set up with PHP 8.

Local WordPress Core Docker environment

The WordPress development repository includes the tools needed to easily spin up a local Docker environment for developing WordPress. Here’s how to get started using this method.

  • Make sure Docker is installed on your machine and running.
  • Checkout the development repo using GIT or SVN.
  • Edit the .env file in the clone to change LOCAL_PHP=latest to LOCAL_PHP=8.0-fpm (or run export LOCAL_PHP=8.0-fpm in the command line window you are using). If you like to test locally using the build directory, also change LOCAL_DIR to build (or run export LOCAL_DIR=build).
  • Install NPM dependencies by running npm install.
  • Build WordPress using npm run build:dev (or npm run build if you prefer to test locally using the build directory)
  • Start the Docker environment by running npm run env:start.
  • Install WordPress in the Docker container by running npm run env:install.

You will then be able to access the site at localhost:8889 in your browser. As new development versions of PHP 8 are released (rc2, rc3, etc.), the containers will be updated. To ensure you are running the latest version of the PHP 8 container, you can run npm run env:pull. It is recommended that you do this before starting the container anytime you are testing WordPress on PHP 8.

More information on the local Docker setup for developing WordPress can be found in the initial Make Core blog post.

Ways to test

  • Use WordPress to test default Core functionality.
  • Write new unit tests that confirm specific PHP 8.0 features or breaking changes work (or don’t) as expected.
  • Write new tests for areas of the codebase that does not have sufficient test coverage.
  • Test your favorite plugins and themes for issues.

Reporting issues

If you discover something that you believe to be a PHP 8 compatibility issue, please create a 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. report on the WordPress Core instance of Trac. Because this is an ongoing effort, it’s possible an issue you have found is already being tracked, is currently being worked on, or has already been fixed. To avoid duplicate reports, please look through pre-existing tickets. The best way to do this is by looking at tickets with the php8 keyword.

Please be sure to provide as many details as you can when creating a ticketticket Created for both bug reports and feature development on the bug tracker. and provide steps that are as specific as possible so that other contributors can quickly and easily reproduce the problem.

More ways to help

  • Head over to the php8 keyword report on WordPress Trac and find a ticket that interests you.
  • Give feedback, write a 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., or test a patch!
  • Inform others that help is needed to test WordPress on PHP 8.0.

To ensure changes receive the necessary testing, it’s best to fix PHP 8.0 compatibility issues as early as possible during the WordPress development schedule. The 5.6 RC1 date (November 17th, 2020) should be considered the final cut off for changes. If additional critical PHP 8.0 issues are found during the RC period, they should receive tickets and patches and will be evaluated on a case by case basis. But, they will not be guaranteed to make the 5.6 release (usually, only regressions are addressed during the RC period). 

Thanks in advance for your help preparing WordPress for PHP 8.0!

Props @sergeybiryukov, @daisyo, @desrosj, and @andreamiddleton for proofreading and peer review.

#php, #testing

Editor Chat Agenda: 28 October, 2020

Facilitator and notetaker @annezazu

This is the agenda for the weekly editor chat scheduled for 2020-10-28 14:00 UTC.

This meeting is held in the #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-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/..

  • 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/ 9.2.2
  • WordPress 5.6 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
  • Monthly Plan for October 2020 and key project updates. For the updates, the discussion will focus on what is being done and help that is needed:
    • Global Styles & Editor focused APIs
    • WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Screen
    • Full Site Editing
  • Task Coordination
  • Open Floor

Even if you can’t make the meeting, you’re encouraged to share anything relevant for the meeting in the comments below:

  • 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.

#core-editor #core-editor-agenda

WordPress 5.5.2 Coming October 29th

As we get deeper into the WordPress 5.6 release cycle, the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team wanted to get out a few updates related to the 5.5 release. Right now there are 10 issues in the milestone, and a handful of Gutenberg updates.

This release is slated for October 29th, 17:00UTC.

Twenty Twenty-One: Dark Mode Discussion

Yesterday in #core-themes, we discussed Dark Mode support for Twenty Twenty-One. Dark Mode is a setting in some operating systems and browsers that allows individual users to request a “dark” version of the website they’re browsing.

Dark Mode support was added to Twenty Twenty-One during its development phase, and needs testing and refinement during 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. for it to be successful. Unsurprisingly, it’s a pretty complicated feature to wrap one’s head around. There are a lot of conditionals and remaining questions we need to solve.

Dark/Light Toggle

We’ve built in a CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. setting that lets site owners opt their sites out of supporting Dark Mode, for greater design control. Additionally, we’re considering adding a front-end toggle so site viewers can turn Dark Mode on/off, regardless of their OS/Browser preference. This setting would only show if a site allows Dark Mode support.

The idea of a toggle to turn Dark Mode on and off on the user side has been brought up a number of times in issues. There’s currently a PR to explore how it would work in Twenty Twenty-One. Today’s discussion focused around the intersection of this setting, along with the ability to disable Dark Mode entirely.

Dark Mode support is a good 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) improvement; some folks, for example, enable Dark Mode because they are sensitive to bright lights, or find find dark color schemes less of an eye strain.

We identified five possible scenarios:

Option 1

  • Allow site owners to disable all dark mode support on their site, regardless of what the user has selected in their OS/browser.
  • If enabled, allow site viewers to toggle dark mode on/off while viewing the site.
  • Pros:
    • Offers the most balanced amount of control for both site owners and site viewers.
  • Cons:
    • Allows site owners to remove an accessibility feature.

Option 2

  • Allow site owners to disable all dark mode support on their site, regardless of what the user has selected in their OS/browser.
  • Don’t allow site viewers to toggle dark mode on/off while viewing the site.
  • Pros:
    • Less visual clutter on the front-end of the site.
  • Cons:
    • Site viewers who prefer Dark Mode might have situations where they’d prefer to toggle Light Mode, and vice-versa; for example, a change in lighting conditions.

Option 3

  • Don’t allow owners to disable dark mode support.
  • Allow site viewers to toggle dark mode on/off while viewing the site.
  • Pros:
    • Most amount of flexibility for site viewers.
  • Cons:
    • WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. does not provide a way to control how sites look in Dark Mode. For example, if you have a dark logo, your logo will be hard to see or even invisible in Dark Mode. There’s no way to add a lighter logo for Dark Mode without using custom CSSCSS Cascading Style Sheets.. Transparent images could face similar visibility issues.

Option 4

  • Don’t allow owners to disable dark mode support.
  • Don’t allow site viewers to toggle dark mode on/off while viewing the site.
  • Pros:
    • Least amount of UIUI User interface.
  • Cons:
    • Least amount of flexibility for site owners.
    • There are situations where site viewers might prefer the inverse of their default color mode.

Option 5

  • Don’t support dark mode in the theme at all.
  • Pros:
    • Easiest for us; we revert and boom, we don’t need to tackle the many situations and edge-cases that will arise during Beta.
    • No potential conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. between what site viewers see, and what the site owner intends.
    • We won’t need to worry about issues like transparent images or dark logos becoming invisible.
    • If a site builder is using Dark Mode, they might not realize their site colors are different for most users than what they themselves are seeing for their site.
    • WordPress itself doesn’t support Dark Mode yet, so we’re not getting ahead of core.
  • Cons:
    • We’re in a unique position to help support and grow a new web/OS feature.
    • We’re also in a unique position to influence best-practice for Dark Mode support within the wider WordPress theme community.

Amongst the folks involved in the discussion, there seemed to be a preference for Option 3, which forced Dark Mode support but allows individual site viewers to toggle it on/off. This late in the game, though, there are also compelling reasons to go with Option 5.

Showing Dark Mode when editing your site

We also talked a little bit about whether or not Dark Mode should be on within wp-adminadmin (and super admin) (specifically, the Customizer and the editor), and whether that front-end toggle should also show within those two admin contexts. This would be useful for site owners who use Dark Mode, so they could easily and quickly toggle it on/off while customizing or creating new content for their site.

Creating a UI control independent of either editor toolbars and 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. boxes within the editor would be a new and unexpected move for a default theme, and would likely create usability and accessibility concerns. Because default themes are used as an example for theme developers, deciding to show the toggle in the editor would require much more discussion from both the default theme team and the Themes team (+make.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//themes). This would have to be outside of the scope of WordPress 5.6.

@sarahricker also suggested that we only ship a proof-of-concept for Dark Mode in 5.6 without the front-end toggle, and then push for native editing of Dark Mode within core for 5.7:

My suggested approach method might be:

Step 1) Proof of concept > theme switches colors based on user’s device
Step 2) In 5.7 – Core adopts support for editing based on user’s device / toggle in backend
Step 3) In 5.7 – TT1 extends POC to integrate with Core AND provides front end toggle

Once core supports being able to customize the design of your site in Dark Mode, we could add that support in to Twenty Twenty-One. We’d also ship the front-end toggle at this time. However, as @williampatton mentioned, default themes rarely get updated with new features after release because of backwards compatibility concerns.

@ryelle suggested that perhaps Step 2 could be more feedback gathering which we push upstream to core and 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/:

step 2 would be listening to the feedback & issues we’re finding in TT1, and pushing that feedback to core/gutenberg to get more native support there; and theoretically nothing from a 5.7 TT1 would change except maybe a new “add_theme_support”, things would just work nicer because we have core support

A new add_theme_support to enable a Dark Mode editor for core that allows you to preview and make edits to your site’s Dark Mode styles (maybe something similar to the AMP plugin, but using the Full Site Editing framework?) could be great.

There is a PR adding the front-end toggle in GitHub.

Design tweaks to Dark Mode

We didn’t have a chance to discuss this synchronously, but one other topic I’d like us to consider is making minor design tweaks to improve Dark Mode. I have two issues open which I’d love input on, especially from folks who have Dark Mode enabled on their computers:

Are there any other improvements we can make to Dark Mode which will improve the overall accessibility and usability of the feature?


Videos

Dark Mode in Twenty Twenty-One 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.:

Dark Mode front-end toggle in PR #622:

#bundled-theme, #dark-mode, #twenty-twenty-one

Lazy-loading images in 5.5

In WordPress 5.5, images will be lazy-loaded by default, using the native HTML loading attribute which became a web standard earlier in 2020. This will drastically save bandwidth on both servers as well as user agents across sites where images further down the page used to be loaded right away, even in the case the user might never scroll towards them.

By default, WordPress will add loading="lazy" to all img tags that have width and height attributes present. Technically this is handled on page output, similar to how responsive images are facilitated in WordPress by adding srcset and sizes attributes. To improve server-side performance of the two features, a new wp_filter_content_tags() function has been introduced so that img tags only need to be parsed once while then deferring the modifications to more specific functions related to the feature.

See #44427 for the overarching TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker..

Reduced layout shifting as a prerequisite

A common user experience problem in modern website is so-called layout shifting, often caused by slow-loading media resources like images: By default, only after an image is loaded, the browser can layout the page correctly, which results in the content e.g. below the image to shift. This issue can be easily resolved by providing width and height attributes on img tags, as the browser will use them to determine the aspect ratio of the image so that it can infer the page layout ahead of actually loading the image.

While this is already a major problem without lazy-loading images, with lazy-loading it becomes more relevant. Therefore WordPress will only add loading="lazy" to img tags which have both dimension attributes present. At the same time, resolving the underlying issue is just as important to reduce layout shifting in general, which is why with version 5.5 WordPress will start back-filling width and height attributes on img tags when they are not already present. To do that, it reuses the established logic already in place for determining srcset and sizes attributes. Like with those attributes, width and height can only be determined if an image is for a WordPress attachment and if the img tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) includes the relevant wp-image-$id class.

WordPress has mostly been following this best practice, and work is being done to ensure all images in the editor will have width and height. Back-filling these attributes should not have any implications on themes, as long as a theme’s CSSCSS Cascading Style Sheets. works appropriately with classic editor content., which is expected: If an image’s width or height is modified via CSS, the respective other attribute should be set to auto, to avoid the image from being stretched.

See #50367 for further background information on this change.

Customizing lazy-loading

By default, WordPress will add a loading="lazy" attribute to the following images:

  • images within post content (the_content)
  • images within post excerpts (the_excerpt)
  • images within text widgets (widget_text_content)
  • avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. images (get_avatar)
  • template images using wp_get_attachment_image() (wp_get_attachment_image)

Developers can customize this behavior through various filters, the most foundational one being wp_lazy_loading_enabled, which receives the following parameters:

  • $default: The boolean default of true 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..
  • $tag_name: An HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. tag name. While per current WordPress behavior this will always be img, it should be noted that the loading attribute is a generic attribute and may be expanded to support further elements, e.g. iframes, in the future.
  • $context: A context string as additional parameters, indicating where the image technically comes from, usually a WordPress hook name. Based on how WordPress itself uses lazy-loading, the context can be one of the five values in parentheses in the list above.

For example, if you would like to turn off lazy-loading by default for template images, you could use the following code snippet:

function disable_template_image_lazy_loading( $default, $tag_name, $context ) {
	if ( 'img' === $tag_name && 'wp_get_attachment_image' === $context ) {
		return false;
	}
	return $default;
}
add_filter(
	'wp_lazy_loading_enabled',
	'disable_template_image_lazy_loading',
	10,
	3
);

In order to modify the loading attribute for very specific images, there are two different approaches, depending on the type of images:

For images that appear within a content blob (e.g. the_content, the_excerpt, widget_text_content), another new filter wp_img_tag_add_loading_attr can be used, which receives the following parameters:

  • $value: The loading attribute value, either “lazy” (default), “eager”, or false. If you want to disable lazy-loading for an image, it is strongly recommended to specify false so that the attribute is omitted altogether.
  • $image: The entire image HTML tag with its attributes.
  • $context: The context, similar as described for the other filter above.

For example, if you would like to disable lazy-loading for a specific attachment image with ID 42 in size “large” within post content, you could use the following code snippet:

function skip_loading_lazy_image_42_large( $value, $image, $context ) {
	if ( 'the_content' === $context ) {
		$image_url = wp_get_attachment_image_url( 42, 'large' );
		if ( false !== strpos( $image, ' src="' . $image_url . '"' ) {
			return false;
		}
	}
	return $value;
}
add_filter(
	'wp_img_tag_add_loading_attr',
	'skip_loading_lazy_image_42_large',
	10,
	3
);

For images which are output via wp_get_attachment_image(), the attribute can simply be controlled through the function’s $attr parameter, which can be the same possibles values like the $value parameter for the above filter. In order to not lazy-load an image, an attribute value of false should be specified, which will result in the attribute being omitted. For example:

echo wp_get_attachment_image(
	42,
	'large',
	false,
	array( 'loading' => false ),
);

Theme developers are recommended to granularly handle loading attributes for images anytime they rely on wp_get_attachment_image() or another function based on it (such as the_post_thumbnail() or get_custom_logo()), depending on where they are used within templates. For example, if an image is placed within the header.php template and is very likely to be in the initial viewport, it is advisable to skip the loading attribute for that image.

Images that are marked as candidates for lazy-loading require the browser to resolve where the image is positioned on the page, which relies on the IntersectionObserver to be available and thus as of today slightly delays their fetching. Experiments using Chrome for Android have shown that the impact of such loading=”lazy” images in the initial viewport on the Largest Contentful Paint metric is fairly small, with 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. of <1% at the 75th and 99th percentiles compared to non lazy-loaded images – yet it is a consideration to make where theme developers can apply some fine tuning for even better user experience.

See #50425 for further background information on this change.

Browser compatibility

The loading attribute is widely supported by modern browsers, with an increasing trend: For example, while Safari support is not yet available at the time of publication, the feature is being worked on there as well and has already been merged into the underlying WebKit engine.

Yet, even browsers that currently do not support the loading attribute will not see any negative consequences from WordPress providing the attribute on images, since the native lazy-loading mechanism is implemented as a fully progressive enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.: For those browsers the attribute will simply be ignored. This also means that whenever a browser implements support for the feature, its users will get the benefits right away when they browse WordPress-powered sites.

Props @azaozz for helping with this post.

#5-5, #dev-notes, #feature-lazyloading

New XML Sitemaps Functionality in WordPress 5.5

In WordPress 5.5, a new feature is being introduced that adds basic, extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. XML sitemaps functionality into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

While web crawlers are able to discover pages from links within the site and from other sites, sitemaps supplement this approach by allowing crawlers to quickly and comprehensively identify all URLs included in the sitemap and learn other signals about those URLs using the associated metadata.

For more background information on this new feature, check out the merge announcement, or the corresponding TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #50117.

This article explains in detail the various ways in which this new feature can be customized by developers. For example, if you are developing a 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 with some similar functionality, this post will show you how you can integrate it with the core’s new sitemaps feature.

Key Takeways

With version 5.5., WordPress will expose a sitemap index at /wp-sitemap.xml. This is the main XML file that contains the listing of all the sitemap pages exposed by a WordPress site.

The sitemap index can hold a maximum of 50000 sitemaps, and a single sitemap can hold a (filterable) maximum of 2000 entries.

By default, sitemaps are created for all public and publicly queryable post types and taxonomies, as well as for author archives and of course the homepage of the site.

The robots.txt file exposed by WordPress will reference the sitemap index so that i can be easily discovered by search engines.

Technical Requirements

Rendering sitemaps on the frontend requires the SimpleXML PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 extension. If this extension is not available, an error message will be displayed instead of the sitemap. The HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. status code 501 (“Not implemented”) will be sent accordingly.

Configuring Sitemaps Behavior

Adding Custom Sitemaps

WordPress provides sitemaps for built-in content types like pages and author archives out of the box. If you are developing a plugin that adds custom features beyond those standard ones, or just want to include some custom URLs on your site, it might make sense to add a custom sitemap provider.

To do so, all you need to do is create a custom PHP class that extends the abstract WP_Sitemaps_Provider class in core. Then, you can use the wp_register_sitemap_provider() function to register it. Here’s an example:

add_filter(
	'init',
	function() {
		$provider = new Awesome_Plugin_Sitemaps_Provider();
		wp_register_sitemap_provider( 'awesome-plugin', $provider );
	}
);

The provider will be responsible for getting all sitemaps and sitemap entries, as well as determining pagination.

Removing Certain Sitemaps

There are three existing sitemaps providers for WordPress object types like posts, taxonomies, and users. If you want to remove one of them, let’s say the “users” provider, you can leverage the wp_sitemaps_add_provider 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. to do so. Here’s an example:

add_filter(
	'wp_sitemaps_add_provider',
	function( $provider, $name ) {
		if ( 'users' === $name ) {
			return false;
		}

		return $provider;
	},
	10,
	2
);

If instead you want to disable sitemap generation for a specific post type or 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., use the wp_sitemaps_post_types or wp_sitemaps_taxonomies filter, respectively.

Example: Disabling sitemaps for the page post type

add_filter(
	'wp_sitemaps_post_types',
	function( $post_types ) {
		unset( $post_types['page'] );
		return $post_types;
	}
);

Example: Disabling sitemaps for the post_tag taxonomy

add_filter(
	'wp_sitemaps_taxonomies',
	function( $taxonomies ) {
		unset( $taxonomies['post_tag'] );
		return $taxonomies;
	}
);

Adding Additional Tags to Sitemap Entries

The sitemaps protocol specifies a certain set of supported attributes for sitemap entries. Of those, only the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org (loc) tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) is required. All others (e.g. changefreq and priority) are optional tags in the sitemaps protocol and not typically consumed by search engines, which is why WordPress only lists the URL itself. Developers can still add those tags if they really want to.

You can use the wp_sitemaps_posts_entry / wp_sitemaps_users_entry / wp_sitemaps_taxonomies_entry filters to add additional tags like changefreq, priority, or lastmod to single items in the sitemap.

Example: Adding the last modified date for posts

add_filter(
	'wp_sitemaps_posts_entry',
	function( $entry, $post ) {
		$entry['lastmod'] = $post->post_modified_gmt;
		return $entry;
	},
	10,
	2
);

Similarly, you can use the wp_sitemaps_index_entry filter to add lastmod on the sitemap index. Note: the sitemaps protocal does not support on the sitemap index.

Trying to add any unsupported tags will result in a _doing_it_wrong notice.

Excluding a Single Post from the Sitemap

If you are developing a plugin that allows setting specific posts or pages to noindex, it’s a good idea to exclude those from the sitemap too.

The wp_sitemaps_posts_query_args filter can be used to exclude specific posts from the sitemap. Here’s an example:

add_filter(
	'wp_sitemaps_posts_query_args',
	function( $args, $post_type ) {
		if ( 'post' !== $post_type ) {
			return $args;
		}

		$args['post__not_in'] = isset( $args['post__not_in'] ) ? $args['post__not_in'] : array();
		$args['post__not_in'][] = 123; // 123 is the ID of the post to exclude.
		return $args;
	},
	10,
	2
);

Disabling Sitemaps Functionality Completely

If you update the Site Visibility settings in WordPress adminadmin (and super admin) to discourage search engines from indexing your site, sitemaps will be disabled. You can use the wp_sitemaps_enabled filter to override the default behavior.

Here’s an example of how to disable sitemaps completely, no matter what:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Note: Doing that will not remove the rewrite rules used for the sitemaps, as they are needed in order to send appropriate responses when sitemaps are disabled.

Want to know whether sitemaps are currently enabled or not? Use wp_sitemaps_get_server()->sitemaps_enabled().

Image/Video/News Sitemaps

WordPress currently implements and supports the core sitemaps format as defined on sitemaps.org. Sitemap extensions like image, video, and news sitemaps are not covered by this feature, as these are usually only useful for a small number of websites. In future versions of WordPress, filters and hooksHooks In 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. may be added to enable adding such functionality. For now this will still be left to plugins to implement.

New Classes and Functions

As of this writing, this is the full list of new classes and functions introduced with this feature.

Functions:

  • wp_sitemaps_get_server – Retrieves the current Sitemaps server instance.
  • wp_get_sitemap_providers – Gets an array of sitemap providers.
  • wp_register_sitemap_provider – Registers a new sitemap provider.
  • wp_sitemaps_get_max_urls – Gets the maximum number of URLs for a sitemap.

Classes:

  • WP_Sitemaps – Main class responsible for setting up rewrites and registering all providers.
  • WP_Sitemaps_Index – Builds the sitemap index page that lists the links to all of the sitemaps.
  • WP_Sitemaps_Provider – Base class for other sitemap providers to extend and contains shared functionality.
  • WP_Sitemaps_Registry – Handles registering sitemap providers.
  • WP_Sitemaps_Renderer – Responsible for rendering Sitemaps data to XML in accordance with sitemap protocol.
  • WP_Sitemaps_Stylesheet – This class provides the XSL stylesheets to style all sitemaps.
  • WP_Sitemaps_Posts – Builds the sitemaps for the ‘post’ object type and its sub types (custom post types).
  • WP_Sitemaps_Taxonomies – Builds the sitemaps for the ‘taxonomy’ object type and its sub types (custom taxonomies).
  • WP_Sitemaps_Users – Builds the sitemaps for the ‘user’ object type.

Available Hooks and Filters

As of this writing, this is the full list of available hooks and filters.

General:

  • wp_sitemaps_enabled – Filters whether XML Sitemaps are enabled or not.
  • wp_sitemaps_max_urls – Filters the maximum number of URLs displayed on a sitemap.
  • wp_sitemaps_init – Fires when initializing sitemaps.
  • wp_sitemaps_index_entry – Filters the sitemap entry for the sitemap index.

Providers:

  • wp_sitemaps_add_provider – Filters the sitemap provider before it is added.
  • wp_sitemaps_post_types – Filters the list of post types to include in the sitemaps.
  • wp_sitemaps_posts_entry – Filters the sitemap entry for an individual post.
  • wp_sitemaps_posts_show_on_front_entry – Filters the sitemap entry for the home page when the ‘show_on_front’ option equals ‘posts’.
  • wp_sitemaps_posts_query_args – Filters the query arguments for post type sitemap queries.
  • wp_sitemaps_posts_pre_url_list – Filters the posts URL list before it is generated (short-circuit).
  • wp_sitemaps_posts_pre_max_num_pages – Filters the max number of pages before it is generated (short-circuit).
  • wp_sitemaps_taxonomies – Filters the list of taxonomies to include in the sitemaps.
  • wp_sitemaps_taxonomies_entry – Filters the sitemap entry for an individual term.
  • wp_sitemaps_taxonomies_query_args – Filters the query arguments for taxonomy terms sitemap queries.
  • wp_sitemaps_taxonomies_pre_url_list – Filters the taxonomies URL list before it is generated (short-circuit).
  • wp_sitemaps_taxonomies_pre_max_num_pages – Filters the max number of pages before it is generated (short-circuit).
  • wp_sitemaps_users_entry – Filters the sitemap entry for an individual user.
  • wp_sitemaps_users_query_args – Filters the query arguments for user sitemap queries.
  • wp_sitemaps_users_pre_url_list – Filters the users URL list before it is generated (short-circuit).
  • wp_sitemaps_users_pre_max_num_pages – Filters the max number of pages before it is generated (short-circuit).

Stylesheets:

  • wp_sitemaps_stylesheet_css – Filters the CSSCSS Cascading Style Sheets. for the sitemap stylesheet.
  • wp_sitemaps_stylesheet_url – Filters the URL for the sitemap stylesheet.
  • wp_sitemaps_stylesheet_content – Filters the content of the sitemap stylesheet.
  • wp_sitemaps_stylesheet_index_url – Filters the URL for the sitemap index stylesheet.
  • wp_sitemaps_stylesheet_index_content – Filters the content of the sitemap index stylesheet.

#5-5, #dev-notes, #sitemaps, #xml-sitemaps

Introducing Twenty Twenty-One

Well friends, it’s time for what I’m sure you’ve all been waiting for: an announcement about the next WordPress default theme! The rumors are true; WordPress 5.6 will launch with a brand new default theme: Twenty Twenty-One. 

The default theme team includes:

  • Default Theme Design Lead: Mel Choyce-Dwan (@melchoyce).
  • Default Theme Development Lead: Carolina Nymark (@poena).  
  • Default Theme Wrangler: Jessica Lyschik (@luminuu).
  • …and you, our fabulous volunteers!

Background

Twenty Twenty-One is designed to be a blank canvas for the 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. After trying some designs heavily inspired by print resources, @kjellr remarked to me, “why not try something natively digital?” I added even more ideas to my increasingly unwieldy pinterest board and gave it a shot. The concept ended up being the most natural, usable design of the bunch. It was simple and un-opinionated, yet still refined. It felt like a fresh canvas, waiting to be painted.

Twenty Twenty-One will use a modified version of the Seedlet theme as its base. This provides us with a thorough system of nested CSSCSS Cascading Style Sheets. variables to make child theming easier, and to help integrate with the global styles functionality that’s under development for full-site editing.

Once the theme is stable, after 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. 1, we’ll start exploring Full Site Editing support.


Design Decisions

By default, the theme uses a native system font stack. I made this choice for a couple reasons:

  • No extra load time. Let’s keep this theme simple and fast.
  • This particular stack is pretty typographically “neutral” — none of the fonts are super opinionated, so the theme can be used broadly across different types of sites.
  • Using just the one font stack, without loading additional font files, also makes it easier for folks to customize or create a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. for Twenty Twenty-One. We want this theme to be a teaching tool, and an outlet for your creativity.

The theme also uses a limited color palette: a pastel green background color, and two shades of dark grey for text. We’ll be bundling the theme with some additional color palettes, including both a white and a black color scheme. Why pastel green? Pastels and muted colors are pretty in right now (seriously I could keep going).

(Who doesn’t love a little pastel cottagecore during these troubling times?)

All this is to say: the design? It’s pretty simple. That’s where patterns come in.

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/ introduced support for patterns in WordPress 5.5. This is the perfect time to show them off. Twenty Twenty-One will come packaged with a bunch of unique patterns designed explicitly for the theme. The theme’s overall design is simple, so you can make it your own, but the patterns will be opinionated. There are a couple already designed, and we’ll be relying on our talented community designers for more ideas. Here’s what we’re thinking about so far:

Want to contribute a block pattern? We have an issue template for that.

Lastly, we’d love to make the theme meet relevant guidelines from WCAG 2.1 level AAA. We loved the idea when +make.wordpress.org/accessibility/ brought it up, and would appreciate any and all guidance from our community a11yAccessibility 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) experts to help make this possible.

You can find full page mockups of Twenty Twenty-One in the Figma file.


Timeline

Per the development cycle information, the upcoming important dates are:

  • WP 5.6 Beta 1 – October 20
    • Last chance for feature projects and new enhancements
    • Theme should be committed to 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.
    • Start exploring FSE support in a second, block-based theme
  • WP 5.6 Beta 4 – November 10
    • Soft string freeze
    • Starter content should be committed
  • WP 5.6 RC 1 – November 17
    • Hard string freeze
    • Starter content needs to be finalized
  • WP 5.6 Release – December 8

Get Involved

If you are interested in contributing to Twenty Twenty-One, make sure you are following this blogblog (versus network, site). During the design and development process, there will be weekly meetings starting Monday, September 28 at 15:00 UTC in #core-themes. We’ll also be holding weekly triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions at starting this Friday at 16:00 UTC.

Theme development will happen on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ and in the interest of time, an in-progress version of the theme code has been uploaded here: https://github.com/wordpress/twentytwentyone.

Once the theme is stable, it will be merged into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and the GitHub repo will be deprecated.


Learn More

If you’re interested in learning more about default themes, you can read the following posts:

#5-6, #bundled-theme, #core-themes, #twenty-twenty-one