Jb Audras 9:11 pm on April 12, 2021
Tags: , ,   

A Week in Core – April 12, 2021

Welcome back to a new issue of Week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between April 5 and April 12, 2021.

  • 26 commits
  • 42 contributors
  • 54 tickets created
  • 9 tickets reopened
  • 45 tickets closed

Reminder: WordPress 5.7.1 is planned for April 14, 2021. The release candidate is available for testing.

Ticketticket Created for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component.

Code changes

Administration

  • Update various background colors for increased contrast – #52760

Build/Test Tools

  • Remove remaining Travis CI references – #52161, #52666
  • Prevent PHPUnit tests on push for forks/private mirrors – #52983
  • Update dependencies in default themes – #52624
  • Update development dependencies from WP packages – #52991
  • Revert package-lock.json change in [50682] – #52768
  • Update some dependencies – #52624

Bundled Themes

  • Update the “Tested up to” value – #52859
  • Twenty Twenty-One: Rebuild IE specific editor stylesheet – #52981, #52702

Coding Standards

  • Rewrite a fragment in request_filesystem_credentials() for clarity and to avoid repetition – #52627
  • Use strict comparison in wp-admin/includes/file.php – #52627
  • Simplify the check for parent terms in export_wp() – #52627
  • Use strict comparison in wp-admin/includes/credits.php – #52627
  • Use strict comparison in wp-admin/includes/comment.php – #52627
  • Remove unnecessary unset() calls in WP_Importer methods – #52996
  • Use strict comparison in wp-admin/includes/dashboard.php – #52627
  • Give a variable in wp-admin/themes.php a more meaningful name – #52627

Customize

  • Set `playsinline` attribute for custom headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. videos – #50111

Editor

  • Use a consistent way to retrieve post ID on Edit Post screens – #52995
  • Ensure wordpress/inteface package is listed as a dependency – #52991

Login and Registration

  • Check if $_GET['login'] is set before using it in wp-login.php – #52980

Media

  • Do not lazy load hidden images or embeds – #52768

Options, 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. APIs

  • Update default color scheme swatch to match CSSCSS Cascading Style Sheets. changes – #52750

REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.

  • Move the rest_jsonp_enabled 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. before setting the Content-Type header – #52691

Site Health

  • Reduce false reports of HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. failures – #52783

Themes

  • Remove unused code fragment from wp-admin/themes.php – #53005

Props

Thanks to the 42 people who contributed to WordPress Core on Trac last week:

@peterwilsoncc (3), @SergeyBiryukov (3), @mukesh27 (3), @johnbillion (2), @TimothyBlynJacobs (2), @ocean90 (2), @ravipatel (2), @klevyke (1), @annalamprou (1), @AnotherDave (1), @ayeshrajans (1), @bobbingwide (1), @Clorith (1), @dragongate (1), @geoffrey1963 (1), @eatsleepcode (1), @gab81 (1), @ninetyninew (1), @Ipstenu (1), @k3nsai (1), @mmuyskens (1), @nicegamer7 (1), @pwallner (1), @ryelle (1), @swissspidy (1), @desrosj (1), @melchoyce (1), @dd32 (1), @rkradadiya (1), @davidbaumwald (1), @jrf (1), @rachelbaker (1), @kebbet (1), @adamsilverstein (1), @audrasjb (1), @fabianpimminger (1), @flixos90 (1), @jonkastonka (1), @joyously (1), @SirStuey (1), @satrancali (1), and @Toru (1).

Please welcome our 17 (!!) new 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. of the week ♥️
@klevyke, @annalamprou, @AnotherDave, @dragongate, @geoffrey1963, @eatsleepcode, @gab81, @ninetyninew, @k3nsai, @mmuyskens, @nicegamer7, @pwallner, @rkradadiya, @fabianpimminger, @jonkastonka, @SirStuey, and @satrancali.

Core committers: @sergeybiryukov (11), @desrosj (5), @peterwilsoncc (4), @ocean90 (2), @gziolo (2), @rachelbaker (1), and @ryelle (1).

#5-7-1, #5-8, #week-in-core

Jb Audras 9:08 pm on April 12, 2021
Tags: , , , , ,   

Dev Chat meeting Summary – April 7, 2021

This is the weekly meetings summary of the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team. The facilitator for this week’s chats was @peterwilsoncc at 05:00 UTC and @francina at 20:00 UTC. Here is the meeting agenda.

Link to 05:00 UTC devchat meeting on the core channel on Slack

Link to 20:00 UTC devchat meeting on the core channel on Slack

Announcements & News

Upcoming releases

WordPress 5.7.1

In line with the trial for consistent minor release leads for each major branch, all the 5.7.x point releases will be led by @peterwilsoncc, with @audrasjb as deputy.

Here is the expected 5.7.1 release schedule:

  • 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).: Wednesday 7 April, 2021 around 23:00 UTC (released)
  • Final release: Wednesday 14 April, 2021 around 23:00 UTC

@audrasjb announced (and hosted) a new 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. scrub right after the devchat.

Note: At the time this meeting recap is published, WP 5.7.1 Release Candidate 1 is now available for testing.

WordPress 5.8

@francina shared some blogposts worth reading, where a new, experimental, release cycle is proposed, and the early bug scrubs schedule is now available.

Core related blogblog (versus network, site) posts

@annezazu shared that the current FSE call for testing is now open for feedback until April 12th rather than April 8th. Hopefully, this gives people an extra weekend to chime in and share their experience.

@chanthaboune pointed out that the first go/no go date for FSE in WP5.8 is next Tuesday.

@nalininonstopnewsuk shared that it is possible share FSE Call for Testing on social and FSE Call for Testing on LinkedIn.

@francina shared this blog post from the Marketing Team: Thoughts on Marketing, FSE, and What’s Next. It’s relevant to the current release, so please read and leave your feedback.

Component maintainers updates

Build/Test Tools (@sergeybiryukov): Work has continued on backporting recent build and test tool improvements to the older branches still receiving security updates. See ticketticket Created for both bug reports and feature development on the bug tracker. #52653 for more details. A post is also upcoming on make/core.

Date/Time, General, I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill., Permalinks (@sergeybiryukov): No major news this week.

Menus, Widgets, Upgrade/Install (@audrasjb): No major news this week.

Site Health (@clorith): The only ticket in milestone 5.7.1 was committed in time.

@francina also pointed out the ticket she opened in Meta Trac concerning Component maintainers updates. In the past month she also reached out to the majority of the components and removed inactive maintainers. Right now there are quite a lot of components without maintainers.

The attendees discussed about maintainers recruitment. If anyone is interested to help to maintain a component, @audrasjb pointed out that he would be happy to mentor/explain what he is doing on the few components he maintains. @francina proposed an online meeting/Q&A, like the casual online gatherings hosted by the community team.

Open floor

@paaljoachim asked what is the definition of what can and not not be included in a minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality..

@jeffpaul quoted the Core team handbook: “A minor release is intended for bugfixes and enhancements that do not add new deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. files and are at the discretion of the release leadRelease Lead The community member ultimately responsible for the Release. with suggestions/input from component maintainers and committers.”

@sergeybiryukov added that generally, minor releases are addressing regressions introduced in the latest release and some follow-up changes to new features, with occasional fixes for bugs from other recent releases, and occasional enhancements that the release leads feel are necessary.

#5-7-1, #5-8, #core-auto-updates, #dev-chat, #summaries, #summary

Piotrek Boniu 7:00 pm on April 12, 2021
Tags: , ,   

Early test scrub for WordPress 5.8

In the previous week we didn’t run the test scrub. That’s why the agenda stays the same for this week. Early test scrub for WordPress 5.8 will take place on 2021-04-16 13:30 in the core-test channel.

We’ll do manual testing of the below tickets, making sure there are no regressions:
https://core.trac.wordpress.org/ticket/32579
https://core.trac.wordpress.org/ticket/52226
https://core.trac.wordpress.org/ticket/52521
https://core.trac.wordpress.org/ticket/52662
https://core.trac.wordpress.org/ticket/40570
https://core.trac.wordpress.org/ticket/39108

We’ll appreciate your participation and feedback!

What you need

  • WordPress environment
  • WordPress 5.8 alpha release, try the WordPress Beta Tester plugin (choose the “Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk.” channel and 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./RC Only” stream options)
  • Two of the tickets are not merged yet. To test them we’ll need to set up the Testing Environment by following the steps listed here – https://meta.trac.wordpress.org/ticket/5581#comment:3

How to apply 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.

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., for example 35449

npm run grunt patch:35449

How to fetch and then checkout a PR, for example, PR 828

git fetch upstream pull/828/head:pr-828
git checkout pr-828

or for PR:

npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/828

Check the handbook for more ways to test patches.

Looking forward to seeing you!

#5-8, #test, #testing

sarayourfriend 12:45 pm on April 9, 2021
Tags:   

Follow up to the native TypeScript proposal

The proposal to intentionally integrate native TypeScript into 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/ repository has garnered overwhelmingly positive feedback so far. However there have been some responses that express concerns over introducing a new technology that will be difficult for contributors to understand. This follow up will hopefully address some of those concerns by refining and clarifying some of the ideas in the original proposal.

In this proposal, nothing changes for consumers of Gutenberg packages (like 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. developers). 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/. remains the primary way of interacting with the 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.. If block developers opt-in to use TypeScript for their own projects, we will gradually improve the tools and typings to make their experience better.

Okay, let’s answer the question: when will TypeScript be used in the repository? To answer this question, we must first keep in mind that we do not refactor without a good reason and certainly not for refactoring’s sake alone: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/#code-refactoring

“Code refactoring should not be done just because we can”

Let’s remember why it’s important to introduce TypeScript and strongly typed functions:

  • A better developer experience via automatic code completion (like Intellisense) and other related tools
  • More confidence in our code through better static analysis of function internals and their usages

When to use TypeScript for existing code

So, with that in mind, I’d like to propose @gziolo’s method for approaching when to use TypeScript for existing files:

  • The default is to use JavaScript
  • When it is possible to type something simply with JSDoc, use JSDoc
  • If there are complex types, but JSDoc is still sufficient generally for consuming those types, you may extract the complex types into a types-only types.ts file to be imported into the JSDoc
  • If it is not possible to express the types using JSDoc or if the JSDoc will vastly over-complicate the ability to type a function, convert it to TypeScript

This, of course, only applies to the places that support native TypeScript anyway which is currently limited to mostly lower level packages, which are the primary initial targets for typing. This falls in line with the original proposal’s statement that “the majority of Gutenberg will probably forever remain as plain old JavaScript.”

It does not cover the case for fully new code in existing packages or new code in the form of completely new packages.

When to use TypeScript for new code

Therefore, for the now rare occasion when a fully new package is added, if all the dependencies are typed, I would like to propose that these should be added in native TypeScript. Likewise, packages that are fully typed or are currently being worked on towards full typing (see #18838 for the list of typed and in-progress packages) and fall into the categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of “lower level packages” as described here and in the next section should have new code added in TypeScript.

Otherwise, new code should follow the the same logic laid out above for existing files, essentially only using TypeScript when absolutely necessary, preferring JSDoc typed JavaScript.

Lower level packages

A note about “lower level packages.” We can refine this definition slightly by stating that a low level package is a package that:

  1. Provides a public API; and
  2. Is not frequently contributed to.

Summary

In summary, I’d like to propose the following:

  • When refactoring existing code to add types, follow the script above.
  • For new packages, use native TypeScript when a) all the packages dependencies are typed and b) when they fall into the category of “lower level packages” as defined above.
  • For new code in existing packages, follow the same script above as for refactoring existing code.

If this is accepted by the community then I will open a PR to update the JavaScript coding guidelines in the repository to reflect this. The update will include the script set out above.

When will a decision be made?

I’d like to aim for making a decision 2 weeks from the date of publication of this follow up post. That should give ample time for discussion and questions.

#javascript

Jonathan Desrosiers 11:06 pm on April 8, 2021
Tags: ,   

Recent Build/Test Tool changes and GitHub Actions update

It’s been a busy year so far for the Build/Test Tool component! Here are some notable changes to be aware of, and an update on the transition to using GitHub Actions for all automated testing.

NodeJS 14.x LTS support

NodeJS 14.x has been the active LTS version since April of 2020. While dependencies were updated to ensure support and related build scripts have worked on 14.x for some time now, the package.json file in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. now officially recommends using NodeJS 14.15.0 and NPM 6.14.8.

The versions specified in the engines field of the package.json file have also been updated to specify a range of versions (>=14.15.0) instead of explicit versions (14.15.0). This should make it more clear to contributors that they can use any version newer than the one specified.

For more information on these changes, check out #51749 and #52455 on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Consistent tooling across all branches

The WordPress project’s current support policy is that only the most recent major version should be considered supported. At the time of this post, this means that 5.7 is the only maintained 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".. However, security fixes are backported as a courtesy in an effort to promote a more secure web (currently) all the way back to the 3.7 branch.

Because of changes in TravisCI’s services, the 3.7-5.5 branches did not have working automated testing configured since the first week of December. To fix this, the 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/ Actions workflow files added to trunk needed to be backported. This could be accomplished for the 4.6-5.5 branches fairly easily after [49527-49533].

However, because build/test tool functionality has not been maintained in old branches, there were a few blockers and consistency issues that needed to be resolved before the necessary workflows could be backported further.

Outdated NodeJS versions

Because old branches are not maintained and only receive security updates as a courtesy, the version of NodeJS used in each branch largely reflected the active version of NodeJS when the branch was created. For example, the 3.7 branch used v0.10.48, 4.2 used v0.12.18, 4.3 used v4.7.2, etc..

This was recently made easier through the use of nvm (Node Version Manager) and .nvmrc files (see #51682), but the dependencies needed to run the local Docker environment (more on that below) do not support these older versions of NodeJS.

After [50187-50224], all older branches currently receiving security updates have been updated to support the most recent version of NodeJS LTS (currently 14.x) and all devDependencies specified in the package.json files have been updated to their latest versions.

The 3.7-4.9 branches also contained an npm-shrinkwrap.json file. This is a type of lock file that predates the newer package-lock.json file. Since all newer branches utilize a package-lock.json file to specify the exact desired versions of dependencies, all npm-shrinkwrap.json files have been replaced with package-lock.json ones in old branches for consistency.

Note: Because the dependencies are responsible for processing JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors., SCSS, and CSSCSS Cascading Style Sheets. files, this will result in most of these files being updated in the next release of each old branch.

For more information on these changes, see #52341 on Trac.

Inconsistent tooling

Another side effect of only backporting security fixes to unmaintained branches is inconsistent tooling. Because tools that make contributing easier are updated and added in each release, switching to an older branch to create 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. becomes much more difficult. The tools contributors are accustomed to using are not there or work differently, and then they have to spend time figuring out how things were done in the past before they can contribute.

All branches now contain the same basic scripts needed to work on WordPress locally. This includes:

  • npm run build
  • npm run watch
  • npm run grunt

Additionally, the grunt-patch-wordpress package has been updated to the latest version in all branches. It has also been added to the 3.7 and 3.8 branches where it was missing.

More information on these changes can also be found in #52341 on Trac.

Local Docker environment

Since WordPress 5.3, a local Docker environment configuration has been included in wordpress-develop to provide an easy way for contributors to configure their own development environment and serve as a more consistent testing environment (mainly for Core’s PHPUnit tests). This environment has also been used for all automated testing in branches 5.3 and newer since being introduced.

However, because of the blockers detailed above, this environment could not be backported to the 3.7-4.5 branches.

After those blockers were resolved, the local Docker environment was then merged into older branches in [50243-50251] ensuring all branches receiving security updates can use the Docker environment.

Note: PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.2 is not currently included in the testing workflows for older branches that supported this version. Adding this for true parity with the old TravisCI testing configuration is blocked by the local Docker environment’s PHP 5.2 PHPUnit image not containing the correct version of PHPUnit.

For more information on this, see #48301 (and the previous #47767) on Trac.

Transitioning to GitHub Actions for automated testing

If you’re unfamiliar with the ongoing transition moving all automated testing from TravisCI/Appveyor to GitHub Actions, the initiative introduction and follow-up posts will help bring you up to speed. This transition has been continuing, and is nearing completion.

As of [50324], automated testing has been restored for all branches still receiving security updates as a courtesy. This includes (where supported) PHPUnit testing, NPM testing, JSHint/PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. linting, QUnit testing, and PHPCompatibility scanning.

In addition to restoring automated testing to branches receiving security updates, there have been a number of performance improvements to the workflows. Most notably, this has resulted in a roughly 70% total decrease in overall runtime for the PHPUnit test workflow.

Here are some additional changes related to GitHub Actions.

Note: All of the changes and improvements listed below have been backported through the 3.7 branch unless otherwise noted.

Limiting when workflows run

Because there are over 750 forks of the wordpress-develop mirror, it’s important to limit when workflows run appropriately. For private repositories, owners are given an allotment of free workflow minutes and are then charged for every minute used over that number. If no limitations are added, each workflow would run on every push event for every fork, including any additional public or private mirrors that are maintained. This would not only waste resources (running for every push to a fork is not necessary as most people open a pull request anyway), but could also unintentionally exhaust a user’s or organization’s private workflow minutes.

To help with this, all workflows have been updated to run only under the following conditions:

  • Every push event to wordpress-develop for the primary branch, branches >= 3.7, and all tags matching the pattern x.y.z that is >= 3.7.0.
  • Every pull request to wordpress-develop with the primary branch or branches >= 3.7 as the base.
  • Every pull request to a fork or private mirror repository with the primary branch or branches >= 3.7 as the base.

For pull request workflows, additional path filtering has been added so that workflows only run when relevant files are changed. For example, the 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/. testing workflow will only run when a JavaScript file, QUnit related file, or relevant configuration files (.jshintrc, package.json, etc.) are changed.

These conditions will help limit the number of workflow runs that occur throughout the contributor base without limiting the ability to test and verify changes.

For more information on these changes, see #52643 and #52667 on Trac.

Regular testing of old branches

In TravisCI, there was a feature to configure regular testing of a repository’s branches at given intervals. This was used to run the test suite for:

  • The currently maintained branch daily when there has not been a successful build in the last 24 hours.
  • The previous branch weekly when there has not been a successful build in the last 24 hours.
  • All other branches receiving security updates monthly when there has not been a successful build in the last 24 hours.

There is a schedule event for triggering workflows in GitHub Actions, but it only runs in the primary branch of a repository, so it cannot be used at the workflow level to ensure regular testing of branches.

Instead, a new workflow has been introduced that will run on a schedule and initiate all of the necessary workflows for old branches using the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. to trigger a workflow_dispatch event. This workflow will test the two most recent branches twice per month, and all other branches monthly.

For more information on this, see #52653 on Trac.

Code coverage reporting

Generating a code coverage report for the code base has been supported for some time (see [42665]). But, reports have never been generated and aggregated on a regular basis. To correct this, a new workflow has been introduced to run a test coverage report daily (see [49834]).

The reports generated are now submitted to Codecov and can be viewed here.

This will hopefully give contributors interested in test coverage the ability to find areas of the code base with little to no testing, and provide some insight into how code coverage increases or decreases over time.

Note: The code coverage will only be reported for the primary branch.

For more information, see #52034 on Trac.

Additional improvements to GitHub Actions workflows

  • The NPM testing workflow has been generalized to not only verify the build tools work on Windows, but Linux and MacOS as well. Steps have also been added to test additional scripts, such as npm run build:dev and npm run grunt clean (see #52658).
  • The fail-fast option has been disabled for the NPM (see [50579]) and PHPUnit (see #52612) testing workflows. fail-fast is great for being alerted of a failure faster, but does not give the full picture of what conditions cause the failure.
  • The method of installing dependencies by use of npx install-changed has been replaced with using npm ci after comparisons found the latter was more performant (see #52660).
  • All restore-keys options for the actions/cache action have been removed in order to prevent the cache from snowballing due to lax cache key matching. This resulted in a 40% decrease in the NPM dependency cache size (see #52660).
  • The restapi-jsclient test group is no longer run separately. This group was never excluded in the phpunit.xml.dist file, so it already runs as part of the main test suite (see #52608).
  • The single site and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site tests have been split into separate jobs that run in parallel. This has reduced the overall runtime for the PHPUnit workflow by over approximately 30% from the previous run (see #52548).
  • Because the test suite takes significantly longer to run on PHP <= 5.6, the PHPUnit workflow has been updated to run test groups that are considered slow (restapi, media, and external-http) in separate, parallel jobs. This reduced the overall time for the workflow by 34% from the previous run (see #52645).

Known transition steps remaining (updated)

The following items remain to achieve parity with the previous testing configurations on TravisCI.

  1. Add and configure 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/. notifications. In addition to sending the results of the whole build of a core commit into #core, we may also want to consider a firehose channel for PRs. This may require all workflows to be combined into a single workflow if needed middleware cannot be found.
  2. Move to GitHub badges for build status indicators – note that these are per-workflow, which is different from the single badge for the entire Travis build for a given commit. However, GitHub does report an overall status for a commit/PR, so we may be able to use that information as well. It seems that the expectation in the greater developer community is that projects report status with a singular badge. Like the Slack notifications, this may require the workflows to be combined in the absence of middleware.
  3. Backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. the workflow files to unsupported older branches receiving security updates.
  4. Finish backporting the local Docker environment to branches 3.7-4.5. This is blocked by:
    • wpdev-docker-images#46, which aims to fix the PHP 5.2 PHPUnit image to include the requred version of PHPUnit (3.6).
    • WP branches <= 4.5 are running a version of NodeJS that is too old for the needed NPM packages required to run the local Docker environment.
  5. Report test results to the Host Test Results page. Completed, but the MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. version being tested is not currently being reported (see phpunit-test-runner#135).

Running tests from src (again)

Since the build process was overhauled in WordPress 5.1 (see #43309), automated testing has been running from the build directory. Running from build introduces several problems that makes contributing difficult:

  • Running a build is slow. It copies all the files and builds, validates, and minifies all the CSS and JS. None of this should be necessary for PHP testing.
  • Developing with grunt watch can give issues on some development environments that run in VirtualBox (like VVV), where changes aren’t being picked up. Having to rebuild manually after each change is a hassle.
  • A developer iterating on a patch in the source file has no way of knowing that their file is not actually being tested when running the tests, unless they run the build each time or start and run the file watcher. This is an easy step to forget.
  • PHP errors display a stack trace from build instead src.
  • Breakpoint debugging isn’t fun as it also uses the stack trace from build instead of src.

The build process was adjusted to allow building and cleaning src again in #44492, but the default directory for automated testing remained build because of some unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. failures.

The remaining items blocking the PHPUnit test suite from running against the src directory have been fixed in [50441] and the default branch for testing has been switched back to src. The PHPUnit testing workflow has also been updated to run the Core test suite from the src directory. This change resulted in an approximately 28% decrease in the workflow’s overall run time from the previous run.

Note: This change has only been merged back to the 5.2-5.7 branches, as this was where it seemed reasonable to draw the line for this change when weighing effort vs. benefits.

For more information on this change, see #51734 on Trac. Related tickets: #43055, #44492, #45863.

Additional changes of note

Here are some other, additional build/test tool changes to make note of:

  • The Docker-based local environment now installs the WordPress Importer 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 into the tests/phpunit/data/plugins directory as part of the npm run env:install script. This eliminates the extra step required when running the unit test suite locally (see #49720).
  • MariaDB support has been added to the local Docker environment. To substitute MySQL for MariaDB, change the values of the LOCAL_DB_TYPE and LOCAL_DB_VERSION to mariadb and a valid MariaDB version in the .env file, in your local CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. configuration file (such as bashrc), or by setting the variable’s value in your session (see #51744).
  • The deprecated node-sass package has been substituted with the recommended replacement, DartSass (sass), which uses the same Javascript 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. (see #51763).
  • The svn:global-ignores and svn:ignore properties have been synchronized with the .gitignore file. These SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. properties had fallen out of date, and several exclusions defined for contributors using 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/. were not defined for those using SVN (see #49784).

Unmaintained branches and build/test tools going forwards

Even though these changes were merged all they through the 3.7, WordPress’ official stance continues to be that only the most recent release (5.7 at the time of this post) should be considered supported. The 3.7-5.6 branches will continue to only receive security fixes going forward (though there have recently been discussions about reducing the number of versions receiving security updates).

The changes above were merged into older branches because they were necessary to restore automated testing, or to maintain consistency in testing configurations across branches.

As changes are made to build/test tool areas of the code base going forward, component maintainers will use their judgement in determining which changes should be backported to these older branches. Changes can be grouped and backported as necessary. To start, reviewing these quarterly or after each major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. can be used as the frequency.

Immense props go out to @johnbillion. Almost all of the performance related changes detailed above were his ideas and contributions. Props to @jorbin, @davidbaumwald, and @sergeybiryukov for peer review.

#build-test-tools, #github-actions

Josepha 7:54 pm on April 8, 2021
Tags: , ,   

Full Site Editing Scope for WP5.8

The first go/no go date is next week (April 14, 2021), and I’d like to offer a roadmap and some high level clarifications for folks following along.

Full site editing is a collection of projects and together they represent a big change, arguably too much for a single release. The most important context to share is that it isn’t shipping as the full, default experience for users. One of the clearest pieces of feedback from the Phase One merge process was that there wasn’t enough time for our extenders (agencies, theme authors, 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 developers, site builders, etc.) to prepare for the upcoming changes.

With that in mind, this merge process won’t be an on/off switch. The focus now is not on a full and nuanced user experience, but more of an open public 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. within WordPress 5.8.

With that context, let’s take a look at what is coming up in the next week and beyond..

Next Steps

Go/No Go Dates

On April 14 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/ plugin will ship v10.4 and shortly thereafter will be the go/no go demo.

The scope is the same as the past few months and focuses on the interface that allows for template editing, a number of new theme-building-oriented blocks, and design tools. This part of the FSE merge will not change the users’ default experience, but instead will focus on bringing tools to the extenders in our community so that they can experiment with their users in mind.

  • Block theme building based on the theme.json configuration file. (https://github.com/WordPress/gutenberg/issues/29891)
  • Site-editing-oriented blocks, such as the Query block, Template Part block, and Site Logo block.(https://github.com/WordPress/gutenberg/issues/28744)
  • Along with the query block, a collection of patterns and contextual pattern transformations. (https://github.com/WordPress/gutenberg/issues/30508)
  • 7 Gutenberg plugin iterations (10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6)

Beta Dates

On June 8 the WordPress 5.8 release will reach its beta period. 

The components below are some of the most complex, and the user experience of them will be key. They are all high priority to complete (hopefully for WP5.8), but will be punted if they aren’t ready in time for Beta.

Later Dates

On July 20 the WordPress 5.8 release will reach general availability.

The components below came up frequently in user testing as being confusing and need more attention. Polishing these components has been moved out of the focus for WP5.8 for proper prioritization.

  • Making the saving flow more intuitive when in the template editor and making changes to multiple areas of a site.
  • Phased rollout of user-interface for Global Styles and interactions with the template editor & template parts.

The Demo

This has been scheduled for April 14. 

Attending

  • Matt Mullenweg – Project Lead (advocating for the vision/mission of WordPress, and aggregate body of users)
  • Matias Ventura – Gutenberg project lead (host of the demo)
  • Helen Hou-Sandi – Lead developer (advocating for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and extender community)
  • Josepha Haden Chomphosy – Executive Director (advocating for the community of WordPress, and aggregate body of users)

Agenda

  • Matias will demo the features intended for WP5.8
  • Discussions and implementation questions

Afterward

  • Blocking items (if any) will be gathered and shared publicly
    • If yes: A plan to prioritize and address issues prior to the second go/no-go date of April 27 will be shared
    • If none: A plan to merge to Core will be shared

#5-8, #core-editor, #full-site-editing

Héctor Prieto 7:52 pm on April 8, 2021
Tags: , ,   

What’s next in Gutenberg? (April 2021)

This monthly update contains the high-level items that 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/ contributors are focusing on for April. Please join us in our efforts and let us know in the comments if anything is blocking you from doing so.

How to follow along with Gutenberg:

Here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project. There is also an index page of Gutenberg development-related posts and a Site Editing Milestone overview issue that breaks down the upcoming work into more concrete next steps. 

Widgets Editor

Work on 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.-based 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. Editor is a continued focus for the month ahead. This effort aims to bring the flexibility of block editing to the widgets and 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. screens. The current efforts include:

Follow along:

You can find more information about the current work in progress in this tracking issue, as well as on this project board. Moreover, you can join #feature-widgets-block-editor in 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/ 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/. for future Widget Editor-focused meetings.

Navigation Editor

Like the Widgets Editor, the Navigation Editor aims to help expand what’s possible with menus while bringing block functionality to yet another part of WordPress to allow for more adoption and offer a more modern experience. Because the Navigation Editor needs to work nicely with the Navigation block (and vice versa), much of the current effort from contributors focus on the Navigation block. With this in mind, current efforts include:

Follow along:

You can follow the progress of this project on this project board or review the new Navigation Editor tracking issue and join #feature-navigation-block-editor in WordPress.org Slack.

Full Site Editing

As with the prior months, work on this major focus for phase 2 is ongoing and is expected to continue as a big-picture goal for 2021. Work this month will include the following focus areas:

Milestone 1 – Site Editing Infrastructure and UI

Milestone 3 – Global Styles

Milestone 4 – Block Themes

Milestone 5 – Query Block

Milestone 6 – Navigation Block

Follow along:

You can follow the progress of this project with this overview issue showing key milestones for site editing. For each major milestone, there are related issues you can follow if you want a more granular look at each next step.

If you’re interested in testing Full Site Editing, check out the FSE Outreach Program to learn more. If you have questions about Full Site Editing, check out this recent effort to offer answers.

Areas to be aware of

Full Site Editing Roadmap:

Block & 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 Developers:

Calls for testing:

Design:

A number of design explorations regarding improvements to reusable blocks are in the works, including:

Theme Developers:

Ways to Get Involved

While the above items are our focuses, don’t forget that you can always help with triage, needs testing issues, good first issues, and reviewing PRs. In particular, if you’re interested in helping with triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. but don’t know where to start, there’s a course on Learn WordPress for how to do triage in GitHub! Check it out and join us.

If there’s anything we can do to make contributing easier, let us know in the comments or in #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.

Meetings to join:

While you can view all meetings here, here are specific meetings to join depending on your interest. Remember that you need a WordPress.org slack account to participate:

  • Core Editor weekly Wednesdays @ 14:00 UTC in #core-editor focused on all things Gutenberg.
  • Block Themes meeting twice monthly on Wednesday @ 16:00 UTC in #themereview focused on preparing for Full Site Editing.

#core-editor #gutenberg-next #gutenberg

Dan Farrow 6:30 pm on April 8, 2021
Tags: ,   

CSS Chat Summary: 01 April 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

Housekeeping

  • Reminder that the meeting time is now 9pm UTC (until later in the year when daylight saving time ends)
  • There will be 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.-scrub before next week’s meeting, which @ryelle offered to run, at 8pm UTC on 08 April

Color custom property naming mock-up share

  • @ryelle shared her mockup adding form elements to her previous pen
  • @notlaura shared her mockup of a dashboard widget
  • @notlaura’s mockup includes a non-colour custom property (border-size) to see how a naming pattern would accommodate values other than colours. For this she uses a [prefix]--[property]--[contextual name] naming pattern
  • By contrast, @ryelle’s [prefix]--[location]--[property]--[state] naming pattern is intended to name custom props containing colour values. The [property] part is the exact property which the custom prop will be applied to e.g. --background-color-- or --color--
  • After some discussion it became clearer that the custom property naming pattern we settle on will, in nearly all cases, only need to accommodate colour values
  • As the discussion had taken some time we’ll continue in future meetings!
  • @ryelle suggested it would be a good time to do another make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. post, following up on @kburgoine’s from earlier this year

Open Floor + CSSCSS Cascading Style Sheets. Link Share

Thanks everyone!

#core-css, #summaries

Lara Schenck 6:04 pm on April 8, 2021
Tags: ,   

CSS Chat Agenda: April 8, 2021

Note: 1 hour before the meeting this week, @ryelle will lead a CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSSCSS Cascading Style Sheets. 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. scrub!

This is the agenda for the upcoming CSS meeting scheduled for Thursday, April 8, at 5:00 PM EST. This meeting will be held in the #core-css 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/..

If there’s any topic you’d like to discuss, or if you have suggestions for discussion questions, please leave a comment below!

#agenda, #core-css

Jb Audras 11:27 pm on April 7, 2021
Tags: , , ,   

WordPress 5.7.1 RC 1

WordPress 5.7.1 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). 1 (RC1) is available for testing!

Here are two ways to test WordPress 5.7.1 RC1:

  • Use the WordPress Beta Tester 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 (select the point releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. nightlies option)
  • Download the release candidate here (zip)

What’s in this release candidate?

5.7.1 Release Candidate 1 features 23 bug fixes on CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., as well as 8 bug fixes 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.

Fixed Core tickets from TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.:

  • #52787 – Empty array for non-single post 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. breaks post save through REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.
  • #52822 – PHPMailer change in WordPress 5.7 breaks working sites
  • #52670 – Adminadmin (and super admin) pointer arrow border color darker than pointer content
  • #52713 – Reverse logic in wp_robots function and 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.
  • #52743 – Hardcoded SVG image URLs on WP 5.7 About screen
  • #52750 – WP 5.7 colors inconsistent in get_option( 'admin_color' ) since color contrast changes
  • #52751 – UIUI User interface issue on Privacy Policy Guide page
  • #52756 – Duplicate video URLs on WP 5.7 About screen
  • #52758 – 5.7 About Page: Image comparison doesn’t work on first load on some browsers
  • #52760 – Color not 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) for AA
  • #52764 – Classic editor adding empty tags in some media embed situations
  • #52768 – WordPress post URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org oEmbed rendering blocked by iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. lazy-loading
  • #52783 – Health Check mis-reports httpsHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. functionality in certain situations
  • #52789 – Gallery layout block adds all media items when changing an image
  • #52816 – Post metaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way. style Twenty Seventeen has a border
  • #52826 – New wp_getimagesize() causing unexpected failures
  • #52834 – Reset password screen: improve buttons layout for better i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.
  • #52891 – Privacy: print screen reader text message
  • #52894 – The wp_sanitize_script_attributes function added in version 5.7 does not escape attributes in some cases
  • #52932 – Rest Api enum validation does not work correctly WordPress 5.7
  • #52961 – Add ‘object-position’ as an allowed CSSCSS Cascading Style Sheets. attribute
  • #52981 – Twenty Twenty-One: Update IE specific editor stylesheet

Fixed Block editor issues from 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/:

  • PR30218 – Core Data: Use getAuthors for showCombobox
  • PR30524 – Editor: Revert (#27717) save editors value on change
  • PR30122 – Gallery: Set addToGallery prop to false when images don’t have IDs
  • PR29809 – Revert: Show empty paragraphs on fronted
  • PR29860 – Try: Fix gallery item clicking
  • PR29920 – Fix sibling block inserter displaying at end of block list
  • PR30125 – Block Editor: Ensure that uncategorized block types are properly handled
  • PR30243 – Add object-position to allowed inline style attributes list

What’s next?

The dev-reviewed workflow (double committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. sign-off) is now in effect when making any changes to the 5.7 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"..

As per the proposed WordPress 5.7.1 schedule, the final release is expected on Wednesday April 14, 2021 around 23:00 UTC. Please note that this date/time can change depending on possible issues after RC1 is released.

The 5.7.1 release is being lead by @peterwilsoncc and @audrasjb.

#5-7, #5-7-1, #minor-releases, #releases