Title: 2021 – Page 43 – Make WordPress Core --- # Yearly Archives: 2021 [ ](https://profiles.wordpress.org/sarayourfriend/) [Sara](https://profiles.wordpress.org/sarayourfriend/) 12:45 pm _on_ April 9, 2021 Tags: [javascript ( 130 )](https://make.wordpress.org/core/tag/javascript/) # 󠀁[Follow up to the native TypeScript proposal](https://make.wordpress.org/core/2021/04/09/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/](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](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](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/#code-refactoring) > [“Code refactoring should not be done just because we can”](https://make.wordpress.org/core/2011/03/23/code-refactoring/) 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](https://profiles.wordpress.org/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](https://github.com/WordPress/gutenberg/issues/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](https://make.wordpress.org/core/2021/03/18/proposal-native-typescript-support-in-gutenberg/#package-list) 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](https://make.wordpress.org/core/2021/03/18/proposal-native-typescript-support-in-gutenberg/#package-list). ## 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](https://make.wordpress.org/core/tag/javascript/) [ ](https://profiles.wordpress.org/desrosj/) [Jonathan Desrosiers](https://profiles.wordpress.org/desrosj/) 11:06 pm _on_ April 8, 2021 Tags: [build-test-tools ( 4 )](https://make.wordpress.org/core/tag/build-test-tools/), [github-actions ( 2 )](https://make.wordpress.org/core/tag/github-actions/)    # 󠀁[Recent Build/Test Tool changes and GitHub Actions update](https://make.wordpress.org/core/2021/04/08/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](https://make.wordpress.org/core/2020/10/15/introducing-github-actions-for-automated-testing/) [GitHub Actions for all automated testing](https://make.wordpress.org/core/2020/12/23/continuing-the-transition-to-github-actions-for-automated-testing/). ## NodeJS 14.x LTS support NodeJS 14.x has been the [active LTS version since April of 2020](https://nodejs.org/en/about/releases/). 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](https://core.trac.wordpress.org/ticket/51749) and [#52455](https://core.trac.wordpress.org/ticket/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 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 by the repository owner. [https://github.com/](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]](https://core.trac.wordpress.org/log/?revs=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](https://github.com/nvm-sh/nvm)) and `.nvmrc` files (see [#51682](https://core.trac.wordpress.org/ticket/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]](https://core.trac.wordpress.org/log/?revs=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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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]](https://core.trac.wordpress.org/log/?revs=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 7.4 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](https://github.com/WordPress/wpdev-docker-images/pull/46). For more information on this, see [#48301](https://core.trac.wordpress.org/ticket/48301)( and the previous [#47767](https://core.trac.wordpress.org/ticket/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](https://make.wordpress.org/core/2020/10/15/introducing-github-actions-for-automated-testing/) and [follow-up](https://make.wordpress.org/core/2020/12/23/continuing-the-transition-to-github-actions-for-automated-testing/) posts will help bring you up to speed. This transition has been continuing, and is nearing completion. As of [[50324]](https://core.trac.wordpress.org/changeset/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,](https://github.com/squizlabs/PHP_CodeSniffer) a popular tool for analyzing code quality. The [WordPress Coding Standards](https://github.com/WordPress/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](https://github.com/WordPress/wordpress-develop/network/members) 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](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](https://core.trac.wordpress.org/ticket/52643) and [#52667](https://core.trac.wordpress.org/ticket/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](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events) 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/](https://developer.wordpress.org/rest-api/) to trigger a [`workflow_dispatch` event](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_dispatch). This workflow will test the two most recent branches twice per month, and all other branches monthly. For more information on this, see [#52653](https://core.trac.wordpress.org/ticket/52653) on Trac. ### Code coverage reporting Generating a code coverage report for the code base has been supported for some time (see [[42665]](https://core.trac.wordpress.org/changeset/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]](https://core.trac.wordpress.org/changeset/49834)). The reports generated are now submitted to Codecov and [can be viewed here](https://app.codecov.io/gh/WordPress/wordpress-develop). 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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/52658)). * The `fail-fast` option has been disabled for the NPM (see [[50579]](https://core.trac.wordpress.org/changeset/50579)) and PHPUnit (see [#52612](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/52660)). * All `restore-key`s 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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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/](https://slack.com/). The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/) notifications. In addition to sending the results of the whole build of a core commit into [#core](https://make.wordpress.org/core/tag/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](https://docs.github.com/en/free-pro-team@latest/actions/managing-workflow-runs/adding-a-workflow-status-badge) 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:~ 5. * [wpdev-docker-images#46](https://github.com/WordPress/wpdev-docker-images/pull/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.~ 6. ~Report test results to the [Host Test Results](https://make.wordpress.org/hosting/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](https://www.mysql.com/) version being tested is not currently being reported (see [phpunit-test-runner#135](https://github.com/WordPress/phpunit-test-runner/issues/135)). ## Running tests from `src` (again) Since the build process was overhauled in WordPress 5.1 (see [#43309](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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](https://make.wordpress.org/core/2021/page/43/?output_format=md#regression). failures. The remaining items blocking the PHPUnit test suite from running against the `src` directory have been fixed in [[50441]](https://core.trac.wordpress.org/changeset/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](https://core.trac.wordpress.org/ticket/51734) on Trac. Related tickets: [#43055](https://core.trac.wordpress.org/ticket/43055), [#44492](https://core.trac.wordpress.org/ticket/44492), [#45863](https://core.trac.wordpress.org/ticket/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/](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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/browser/tags/5.7/.env#L48), 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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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/](https://git-scm.com/) were not defined for those using SVN (see [#49784](https://core.trac.wordpress.org/ticket/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](https://make.wordpress.org/core/2019/07/29/should-security-fixes-continue-to-be-backported-to-very-old-versions-of-wordpress/)). 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](https://profiles.wordpress.org/johnbillion/). Almost all of the performance related changes detailed above were his ideas and contributions. Props to [@jorbin](https://profiles.wordpress.org/jorbin/), [@davidbaumwald](https://profiles.wordpress.org/davidbaumwald/), and [@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/) for peer review._ [#build-test-tools](https://make.wordpress.org/core/tag/build-test-tools/), [#github-actions](https://make.wordpress.org/core/tag/github-actions/) [ ](https://profiles.wordpress.org/chanthaboune/) [Josepha](https://profiles.wordpress.org/chanthaboune/) 7:54 pm _on_ April 8, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [core-editor ( 757 )](https://make.wordpress.org/core/tag/core-editor/), [full-site editing ( 15 )](https://make.wordpress.org/core/tag/full-site-editing/) # 󠀁[Full Site Editing Scope for WP5.8](https://make.wordpress.org/core/2021/04/08/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/](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/](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](https://make.wordpress.org/core/2021/02/17/whats-new-in-gutenberg-10-0-february/), [10.1](https://make.wordpress.org/core/2021/03/02/whats-new-in-gutenberg-10-1-3-march/), [10.2](https://make.wordpress.org/core/2021/03/17/whats-new-in-gutenberg-10-2-17-march/), [10.3](https://make.wordpress.org/core/2021/04/02/whats-new-in-gutenberg-10-3-31-march/), 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. * [Widgets Editor](https://github.com/WordPress/gutenberg/issues/24687) * Navigation [Editor](https://github.com/WordPress/gutenberg/issues/29102) and [block](https://github.com/WordPress/gutenberg/issues/27593) * [Refactored gallery block](https://github.com/WordPress/gutenberg/pull/25940) * [List view](https://github.com/WordPress/gutenberg/issues/29736) ### 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](https://make.wordpress.org/core/2021/03/16/high-level-feedback-from-the-fse-program-march/) 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](https://make.wordpress.org/core/tag/5-8/), [#core-editor](https://make.wordpress.org/core/tag/core-editor/), [#full-site-editing](https://make.wordpress.org/core/tag/full-site-editing/) [ ](https://profiles.wordpress.org/priethor/) [Héctor Prieto](https://profiles.wordpress.org/priethor/) 7:52 pm _on_ April 8, 2021 Tags: [core-editor ( 757 )](https://make.wordpress.org/core/tag/core-editor/), [gutenberg ( 547 )](https://make.wordpress.org/core/tag/gutenberg/), [gutenberg-next ( 23 )](https://make.wordpress.org/core/tag/gutenberg-next/) # 󠀁[What’s next in Gutenberg? (April 2021)](https://make.wordpress.org/core/2021/04/08/whats-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/](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](https://make.wordpress.org/core/2020/05/20/ways-to-keep-up-with-full-site-editing-fse/) to keep up with Gutenberg and the Full Site Editing project. There is also an index page of [Gutenberg development-related posts](https://make.wordpress.org/core/handbook/references/keeping-up-with-gutenberg-index/) and a [Site Editing Milestone overview issue](https://github.com/WordPress/gutenberg/issues/24551) 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: * Following the [implementation of the block inspector panel in the customizer](https://github.com/WordPress/gutenberg/issues/29286), the next step is to polish it to [follow accessibility best practices](https://github.com/WordPress/gutenberg/issues/30271). * Implement [undo/redo in the widgets customizer](https://github.com/WordPress/gutenberg/issues/30400). * Implement feature parity with the classic widgets screen, such as [moving blocks between widget areas](https://github.com/WordPress/gutenberg/issues/27409). * Auditing and ensuring [backward compatibility](https://github.com/WordPress/gutenberg/issues/28673). **Follow along:** You can find more information about the current work in progress in this [tracking issue](https://github.com/WordPress/gutenberg/issues/24687), as well as[ on this project board](https://github.com/WordPress/gutenberg/projects/27). Moreover, you can join [#feature-widgets-block-editor](https://make.wordpress.org/core/tag/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/](https://wordpress.org/) SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/). The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](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: * Continue defining Navigation Editor architecture. * [Reconsider the placeholder state](https://github.com/WordPress/gutenberg/issues/23953) to make it easier to create a new menu. * [Show only the menu name and list view button](https://github.com/WordPress/gutenberg/issues/28856) in the Navigation block toolbar when in the context of the Navigation Editor. * [Better handling of unsaved changes](https://github.com/WordPress/gutenberg/issues/30322), including enabling the save button [only when there are unsaved changes](https://github.com/WordPress/gutenberg/issues/30391). **Follow along:** You can follow the progress of this project [on this project board](https://github.com/WordPress/gutenberg/projects/31) or review the new [Navigation Editor tracking issue](https://github.com/WordPress/gutenberg/issues/29102) and join[ #feature-navigation-block-editor](https://wordpress.slack.com/archives/C01KDAZJMQ9) 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](https://make.wordpress.org/updates/2021/01/21/big-picture-goals-2021/). Work this month will include the following focus areas: Milestone 1 – [Site Editing Infrastructure and UI](https://github.com/WordPress/gutenberg/issues/24818) * Ongoing work on [phase 3 of the infrastructure](https://github.com/WordPress/gutenberg/issues/27814). * Explore [how to expose the new FSE editors to users](https://github.com/WordPress/gutenberg/issues/29630). * Allow creating [custom block templates in classic themes](https://github.com/WordPress/gutenberg/pull/30438). * Add [support for classic themes to use specific block template parts](https://github.com/WordPress/gutenberg/pull/30345). * Improve the [persistent list view](https://github.com/WordPress/gutenberg/issues/29736), including [enabling it in the post editor](https://github.com/WordPress/gutenberg/issues/29470). Milestone 3 – [Global Styles](https://github.com/WordPress/gutenberg/issues/20331) * Iterate on the[ block supports mechanism](https://github.com/WordPress/gutenberg/issues/28913), including: - [Add configurable sides and margins to spacing support](https://github.com/WordPress/gutenberg/pull/30333#issuecomment-815619025). - [Add border color, style, and width support](https://github.com/WordPress/gutenberg/pull/30124). * Improve the [theme.json structure](https://github.com/WordPress/gutenberg/issues/29891). * Add [CSS vars for root level settings](https://github.com/WordPress/gutenberg/pull/29714). * Standardize loading [default block editor settings](https://github.com/WordPress/gutenberg/pull/30245). Milestone 4 – [Theme Blocks](https://github.com/WordPress/gutenberg/issues/22724) * Enable [theme blocks in classic themes](https://github.com/WordPress/gutenberg/issues/28744). * Design for [Post Comment blocks](https://github.com/WordPress/gutenberg/issues/24101) and its inner blocks. * Polish the Site Logo block’s design and [bring feature parity with the Image block](https://github.com/WordPress/gutenberg/issues/30406). Milestone 5 – [Query Block](https://github.com/WordPress/gutenberg/issues/24762) * Revisit the bundled [Query Block Patterns](https://github.com/WordPress/gutenberg/issues/30508). * Suggest [Patterns in block placeholder states](https://github.com/WordPress/gutenberg/issues/28735). Milestone 6 – [Navigation Block](https://github.com/WordPress/gutenberg/issues/27593) * [Make the navigation mobile-responsive](https://github.com/WordPress/gutenberg/issues/22824) is an ongoing effort, collapsing it to a hamburger icon when on smaller viewports. * Allow converting the [Page List to individual Navigation Link items](https://github.com/WordPress/gutenberg/issues/29437). * [Support non-li inner blocks](https://github.com/WordPress/gutenberg/issues/29036), with a first attempt to [add a Links block](https://github.com/WordPress/gutenberg/issues/24644). * The next step of improving the placeholder step of blocks that link provides[ a split label/URL control and placeholder state](https://github.com/WordPress/gutenberg/issues/30170). * Mark [invalid menu items](https://github.com/WordPress/gutenberg/issues/23573) and [links to draft pages](https://github.com/WordPress/gutenberg/issues/29417#issuecomment-790816305) for better editing UXUX User experience. **Follow along:** You can follow the progress of this project with this overview issue showing [key milestones for site editing](https://github.com/WordPress/gutenberg/issues/24551). 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](https://make.wordpress.org/test/handbook/full-site-editing-outreach-experiment/). If you have questions about Full Site Editing, [check out this recent effort to offer answers.](https://make.wordpress.org/test/tag/fse-answers/) ## Areas to be aware of **Full Site Editing Roadmap**: * [@matveb](https://profiles.wordpress.org/matveb/) [guest-joined the WP Briefing Podcast](https://wordpress.org/news/2021/03/talking-full-site-editing-with-matias-ventura/) to talk about Full Site Editing, its current state, and next steps. * [@chanthaboune](https://profiles.wordpress.org/chanthaboune/) published a [post covering the Full Site Editing Scope for 5.8](https://make.wordpress.org/core/2021/04/08/full-site-editing-scope-for-wp5-8/). **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/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. Developers**: * CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Blocks can now [load JavaScript in the frontend on demand](https://github.com/WordPress/gutenberg/pull/30341). * A recent proposal was submitted to [add native TypeScript support in Gutenberg](https://make.wordpress.org/core/2021/03/18/proposal-native-typescript-support-in-gutenberg/). **Calls for testing**: * There’s an [open call for testing](https://make.wordpress.org/core/2021/03/23/gallery-block-update-call-for-testing/) following the recent work on the [Gallery block refactor](https://github.com/WordPress/gutenberg/pull/25940). * [Round #4 of the FSE Out Reach Program](https://make.wordpress.org/test/2021/03/25/fse-program-testing-call-4-building-a-restaurant-themed-header/) is open until April 12th. **Design**: A number of design explorations regarding [improvements to reusable blocks](https://github.com/WordPress/gutenberg/issues/27890) are in the works, including: * [Add more functionality to reusable block settings](https://github.com/WordPress/gutenberg/issues/30357). * [Add a menu in the isolated editing view top toolbar](https://github.com/WordPress/gutenberg/issues/30622) for navigating to usage locations. * [Show the Save button in the Reusable Block toolbar](https://github.com/WordPress/gutenberg/issues/29871) if there are changes. **Theme Developers**: * A discussion is underway regarding [the future of themes with Full Site Editing and its gradual adoption](https://github.com/WordPress/gutenberg/issues/29024). * [Connecting patterns with specific contexts and transforms](https://github.com/WordPress/gutenberg/issues/27575) is in the works, allowing themes to suggest specific patterns depending on the context. * We’re still watching the [Theme Experiments repo](https://github.com/WordPress/theme-experiments) to see how theme developers are building block themes. Please continue to share there and know we appreciate it. ## Ways to Get Involved While the above items are our focuses, don’t forget that you can always help with [triage](https://href.li/?https://github.com/WordPress/gutenberg/blob/master/docs/contributors/triage.md), [needs testing issues](https://href.li/?https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+Testing%22), [good first issues](https://href.li/?https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3A%22Good+First+Issue%22), and [reviewing PRs](https://href.li/?https://github.com/WordPress/gutenberg/tree/master/packages/env). 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!](https://learn.wordpress.org/workshop/how-to-do-triage-on-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](https://wordpress.slack.com/archives/C02QB2JS7) 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](https://make.wordpress.org/meetings/), here are specific meetings to join depending on your interest. Remember that you need a [WordPress.org slack account](https://make.wordpress.org/chat/) to participate: * Core Editor weekly Wednesdays @ 14:00 UTC in [#core-editor](https://wordpress.slack.com/archives/C02QB2JS7) focused on all things Gutenberg. * Block Themes meeting twice monthly on Wednesday @ 16:00 UTC in [#themereview](https://wordpress.slack.com/archives/C02RP4Y3K) focused on preparing for Full Site Editing. [#core-editor](https://make.wordpress.org/core/tag/core-editor/) [#gutenberg-next](https://make.wordpress.org/core/tag/gutenberg-next/) [#gutenberg](https://make.wordpress.org/core/tag/gutenberg/) [ ](https://profiles.wordpress.org/danfarrow/) [Dan Farrow](https://profiles.wordpress.org/danfarrow/) 6:30 pm _on_ April 8, 2021 Tags: [core-css ( 191 )](https://make.wordpress.org/core/tag/core-css/), [summary ( 975 )](https://make.wordpress.org/core/tag/summary/)    # 󠀁[CSS Chat Summary: 01 April 2021](https://make.wordpress.org/core/2021/04/08/css-chat-summary-01-april-2021/)󠁿 [The meeting took place here on Slack](https://wordpress.slack.com/archives/CQ7V4966Q/p1617311373152800). [@notlaura](https://profiles.wordpress.org/notlaura/) facilitated and [@danfarrow](https://profiles.wordpress.org/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](https://profiles.wordpress.org/ryelle/) offered to run, at 8pm UTC on 08 April ## Color custom property naming mock-up share * [@ryelle](https://profiles.wordpress.org/ryelle/) [shared her mockup adding form elements to her previous pen](https://codepen.io/ryelle/project/full/AooEky) * [@notlaura](https://profiles.wordpress.org/notlaura/) [shared her mockup of a dashboard widget](https://codepen.io/laras126/pen/wvgJgaQ) * [@notlaura](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/kburgoine/)’s from earlier this year ## Open Floor + CSSCSS Cascading Style Sheets. Link Share * [@joyously](https://profiles.wordpress.org/joyously/) [shared her comment on the previous week’s meeting notes](https://make.wordpress.org/core/2021/03/30/css-chat-summary-25-march-2021/#comment-40980) which include some links to interesting approaches for handling CSS colour scheming * [@ryelle](https://profiles.wordpress.org/ryelle/) suggested discussing the core CSS coding standards in a future meeting as they are in need of some attention– [there’s a related Gutenberg issue here](https://github.com/WordPress/gutenberg/issues/11689) Thanks everyone! [#core-css](https://make.wordpress.org/core/tag/core-css/), [#summary](https://make.wordpress.org/core/tag/summary/) [ ](https://profiles.wordpress.org/notlaura/) [Lara Schenck](https://profiles.wordpress.org/notlaura/) 6:04 pm _on_ April 8, 2021 Tags: [agenda ( 1,142 )](https://make.wordpress.org/core/tag/agenda/), [core-css ( 191 )](https://make.wordpress.org/core/tag/core-css/)    # 󠀁[CSS Chat Agenda: April 8, 2021](https://make.wordpress.org/core/2021/04/08/css-chat-agenda-april-8-2021/)󠁿 _Note: 1 hour before the meeting this week, [@ryelle](https://profiles.wordpress.org/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](https://www.timeanddate.com/worldclock/fixedtime.html?msg=WordPress+CSS+Core+Chat&iso=20210408T17&p1=418&ah=1). This meeting will be held in the [#core-css](https://make.wordpress.org/core/tag/core-css/) channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/). The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](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! * Housekeeping * Discuss: - CSS deprecation path * See [this issue in the Gutenberg repo](https://github.com/WordPress/gutenberg/issues/28664) * A post from [@helen](https://profiles.wordpress.org/helen/) about [Admin CSS back-compat](https://helen.wordpress.com/2013/09/19/admin-css-back-compat-possibilities/) - CSS naming and usage conventions for JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. targeting, [ticket 40686](https://core.trac.wordpress.org/ticket/40686) * Project Updates - CSS Audit ([#49582](https://core.trac.wordpress.org/ticket/49582)) - Color Scheming ([#49999](https://core.trac.wordpress.org/ticket/49999)) * Open Floor + CSS Link Share [#agenda](https://make.wordpress.org/core/tag/agenda/), [#core-css](https://make.wordpress.org/core/tag/core-css/) [ ](https://profiles.wordpress.org/audrasjb/) [Jb Audras](https://profiles.wordpress.org/audrasjb/) 11:27 pm _on_ April 7, 2021 Tags: [5.7 ( 67 )](https://make.wordpress.org/core/tag/5-7/), [5.7.1 ( 20 )](https://make.wordpress.org/core/tag/5-7-1/), [minor releases ( 40 )](https://make.wordpress.org/core/tag/minor-releases/), [releases ( 58 )](https://make.wordpress.org/core/tag/releases/)    # 󠀁[WordPress 5.7.1 RC 1](https://make.wordpress.org/core/2021/04/07/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)](https://make.wordpress.org/core/2021/page/43/?output_format=md#alpha-beta). 1** (RC1) is available for testing! Here are two ways to test WordPress 5.7.1 RC1: * Use the [WordPress Beta Tester](https://wordpress.org/plugins/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/](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)](https://wordpress.org/wordpress-5.7.1-RC1.zip) ## What’s in this release candidate? 5.7.1 Release Candidate 1 features [23 bug fixes](https://core.trac.wordpress.org/query?status=closed&milestone=5.5.1&group=status&col=id&col=summary&col=milestone&col=owner&col=type&col=status&col=priority&order=priority) on CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., as well as [8 bug fixes](https://github.com/WordPress/gutenberg/pull/24828) 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](https://core.trac.wordpress.org/ticket/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/](https://developer.wordpress.org/rest-api/) * [#52822](https://core.trac.wordpress.org/ticket/52822) – PHPMailer change in WordPress 5.7 breaks working sites * [#52670](https://core.trac.wordpress.org/ticket/52670) – Adminadmin (and super admin) pointer arrow border color darker than pointer content * [#52713](https://core.trac.wordpress.org/ticket/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](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](https://core.trac.wordpress.org/ticket/52743) – Hardcoded SVG image URLs on WP 5.7 About screen * [#52750](https://core.trac.wordpress.org/ticket/52750) – WP 5.7 colors inconsistent in `get_option( 'admin_color' )` since color contrast changes * [#52751](https://core.trac.wordpress.org/ticket/52751) – UIUI User interface issue on Privacy Policy Guide page * [#52756](https://core.trac.wordpress.org/ticket/52756) – Duplicate video URLs on WP 5.7 About screen * [#52758](https://core.trac.wordpress.org/ticket/52758) – 5.7 About Page: Image comparison doesn’t work on first load on some browsers * [#52760](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/52764) – Classic editor adding empty tags in some media embed situations * [#52768](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/52789) – Gallery layout block adds all media items when changing an image * [#52816](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/52826) – New `wp_getimagesize()` causing unexpected failures * [#52834](https://core.trac.wordpress.org/ticket/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](https://make.wordpress.org/core/2021/page/43/?output_format=md#l10n). Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. * [#52891](https://core.trac.wordpress.org/ticket/52891) – Privacy: print screen reader text message * [#52894](https://core.trac.wordpress.org/ticket/52894) – The `wp_sanitize_script_attributes` function added in version 5.7 does not escape attributes in some cases * [#52932](https://core.trac.wordpress.org/ticket/52932) – Rest Api enum validation does not work correctly WordPress 5.7 * [#52961](https://core.trac.wordpress.org/ticket/52961) – Add ‘object-position’ as an allowed CSSCSS Cascading Style Sheets. attribute * [#52981](https://core.trac.wordpress.org/ticket/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 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 by the repository owner. [https://github.com/](https://github.com/): * [PR30218](https://github.com/WordPress/gutenberg/pull/30218) – Core Data: Use` getAuthors` for `showCombobox` * [PR30524](https://github.com/WordPress/gutenberg/pull/30524) – Editor: Revert( [#27717](https://github.com/WordPress/gutenberg/pull/27717)) save editors value on change * [PR30122](https://github.com/WordPress/gutenberg/pull/30122) – Gallery: Set ` addToGallery` prop to false when images don’t have IDs * [PR29809](https://github.com/WordPress/gutenberg/pull/29809) – Revert: Show empty paragraphs on fronted * [PR29860](https://github.com/WordPress/gutenberg/pull/29860) – Try: Fix gallery item clicking * [PR29920](https://github.com/WordPress/gutenberg/pull/29920) – Fix sibling block inserter displaying at end of block list * [PR30125](https://github.com/WordPress/gutenberg/pull/30125) – Block Editor: Ensure that uncategorized block types are properly handled * [PR30243](https://github.com/WordPress/gutenberg/pull/30243) – 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](https://make.wordpress.org/core/2021/03/22/wordpress-5-7-1-maintenance-release-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](https://profiles.wordpress.org/peterwilsoncc/) and [@audrasjb](https://profiles.wordpress.org/audrasjb/). [#5-7](https://make.wordpress.org/core/tag/5-7/), [#5-7-1](https://make.wordpress.org/core/tag/5-7-1/), [#minor-releases](https://make.wordpress.org/core/tag/minor-releases/), [#releases](https://make.wordpress.org/core/tag/releases/) [ ](https://profiles.wordpress.org/annezazu/) [annezazu](https://profiles.wordpress.org/annezazu/) 5:28 pm _on_ April 7, 2021 Tags: [core-editor ( 757 )](https://make.wordpress.org/core/tag/core-editor/), [core-editor-summary ( 185 )](https://make.wordpress.org/core/tag/core-editor-summary/), [gutenberg ( 547 )](https://make.wordpress.org/core/tag/gutenberg/)    # 󠀁[Editor chat summary: 7 April, 2021](https://make.wordpress.org/core/2021/04/07/editor-chat-summary-7-april-2021/)󠁿 This post summarizes the weekly editor chat meeting ([agenda here](https://make.wordpress.org/core/2021/04/06/editor-chat-agenda-7-april-2021/)) held on [2021-04-7 14:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210407T1400) in [Slack](https://wordpress.slack.com/archives/C02QB2JS7/p1617804003038800). Moderated by [@annezazu](https://profiles.wordpress.org/annezazu/). ## Announcements * 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/](https://wordpress.org/gutenberg/) [10.3.1 release](https://github.com/WordPress/gutenberg/releases/tag/v10.3.1) shipped on April 1st. * Gutenberg [10.3.2 release](https://github.com/WordPress/gutenberg/releases/tag/v10.3.2) shipped on April 7th.  * Gutenberg [10.4 RC](https://github.com/WordPress/gutenberg/releases/tag/v10.4.0-rc.1) is available to test and report bugs. * Help [test the WordPress 5.7.1 RC](https://make.wordpress.org/core/2021/03/22/wordpress-5-7-1-maintenance-release-schedule/)( will be released later today).  * Reminder: feedback due on April 12th now for the [FSE Program Testing Call #4: Building a restaurant themed header.](https://make.wordpress.org/test/2021/03/25/fse-program-testing-call-4-building-a-restaurant-themed-header/) ## Monthly Priorities & Key Project Updates **Full Site Editing** **from [@youknowriad](https://profiles.wordpress.org/youknowriad/)** * Making the margins the same between frontend and backend (no opinionated margins provided by 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 by default). * Working on [adding a way to use block templates in classic](https://github.com/WordPress/gutenberg/pull/30438) [ ](https://github.com/WordPress/gutenberg/pull/30438)[themes](https://github.com/WordPress/gutenberg/pull/30438) as well which should provide a nice transition point. **Global Styles from [@nosolosw](https://profiles.wordpress.org/nosolosw/)** Shipped: * Block Supports: added a `gutenberg_block_has_support` helper function and support for padding in dynamic blocks [30322](https://github.com/WordPress/gutenberg/pull/30332), border for search block [#30227](https://github.com/WordPress/gutenberg/pull/30227). * Fixes: title in the save panel of the site editor [30521](https://github.com/WordPress/gutenberg/pull/30521), fix for themes without theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. support but with experimental link color support [30452](https://github.com/WordPress/gutenberg/pull/30452). Ongoing * Block supports: border for button block [#30194](https://github.com/WordPress/gutenberg/pull/30194), add border color/style/width properties [#30124](https://github.com/WordPress/gutenberg/pull/30124), spacing [#30333](https://github.com/WordPress/gutenberg/pull/30333) [#30371](https://github.com/WordPress/gutenberg/pull/30371). * Theme.json: Update format [#29891](https://github.com/WordPress/gutenberg/issues/29891), there’s now a draft PR at [#30541](https://github.com/WordPress/gutenberg/pull/30541), conversation about whether and how to expand the use of CSSCSS Cascading Style Sheets. Custom Properties [#29714](https://github.com/WordPress/gutenberg/pull/29714) **Navigation Block from [@mkaz](https://profiles.wordpress.org/mkaz/) and [@andraganescu](https://profiles.wordpress.org/andraganescu/)** Updates and improvements keep chugging along! The [dependency on responsive nav](https://github.com/WordPress/gutenberg/pull/30341) will likely get merged today, and then the [responsive PR](https://github.com/WordPress/gutenberg/pull/30047) can move forward. A new update [attempts to fix the HTML produced by the block](https://github.com/WordPress/gutenberg/pull/30430). This is blocked by the lack of advancement in the discussions opened by [@talldanwp](https://profiles.wordpress.org/talldanwp/)( [Issue30007 ](https://github.com/WordPress/gutenberg/issues/30007)and [Issue30006](https://github.com/WordPress/gutenberg/issues/30006)). Any help moving those points forward would be greatly appreciated! Plenty of other refinements and updates continue too, for example the [placeholder state was updated](https://github.com/WordPress/gutenberg/pull/30281). The best way to follow along is by labels in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘ pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. [https://github.com/](https://github.com/) PRs or this [tracking issue](https://github.com/WordPress/gutenberg/issues/27593). **Navigation Editor from [@andraganescu](https://profiles.wordpress.org/andraganescu/)** The Block based Navigation editor is advancing with a host of PRs aimed at polishing various functionality ([PR30374](https://github.com/WordPress/gutenberg/pull/30374), [PR30403](https://github.com/WordPress/gutenberg/pull/30403), [PR30524 ](https://github.com/WordPress/gutenberg/pull/30524), [PR30340](https://github.com/WordPress/gutenberg/pull/30340)) and some that could use a review and testing ([PR30446](https://github.com/WordPress/gutenberg/pull/30446), [PR30440](https://github.com/WordPress/gutenberg/pull/30440), [PR30349](https://github.com/WordPress/gutenberg/pull/30349)). **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 from [@andraganescu](https://profiles.wordpress.org/andraganescu/)** Block based Widget Editor work is focused on tidying up blocks in 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. for better 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) and various bugs. **Mobile Gutenberg from [@mattchowning](https://profiles.wordpress.org/mattchowning/)** Landed * Block transforms * Removing ability to switch to the Classic editor when editing a post * Significantly the number of blocks that are tested on native by CI on each PR( [relevant PR](https://github.com/WordPress/gutenberg/pull/26405)) New In Progress * Slash inserter Still In Progress * Dual licensing Gutenberg: planning to merge the [PR with interim license](https://github.com/WordPress/gutenberg/pull/30383) this week * Global Style Support * Reusable blocks * Search block * Adding search to the block inserter * Embed block * Simplification of media insertion flow ## Task Coordination [@mkaz](https://profiles.wordpress.org/mkaz/) * I’m working on [bring justification controls to vertical variant](https://github.com/WordPress/gutenberg/pull/30351) of navigation, but not in editor screen. This may require some rework and implement using supports mechanism. [@ntsekouras](https://profiles.wordpress.org/ntsekouras/) * [Bug fix](https://github.com/WordPress/gutenberg/pull/30203) for Query `undo trap` during creation. * Add option to [make PostDate a link](https://github.com/WordPress/gutenberg/pull/30499). * [Removed the experimental `scope` from Patterns API](https://github.com/WordPress/gutenberg/pull/30471) and replaced it with `blockTypes`. * My main focus remains on patterns integration and [currently in this iteration](https://github.com/WordPress/gutenberg/pull/30469). [@mamaduka](https://profiles.wordpress.org/mamaduka/) * Still working on the “Most used tags” feature. * [Fixed “the same key” prop issue](https://github.com/WordPress/gutenberg/pull/30555) for gallery list items. * Started doing PR reviews by testing and adding comments. Hopefully, this can help the “Gutenberg CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.” team a little bit. * Currently figuring out the best way to filterFilter Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/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. PRs for reviews. [@mikeschroder](https://profiles.wordpress.org/mikeschroder/) * I’d love feedback on the approach in [this PR](https://github.com/WordPress/gutenberg/pull/30074) for [24337](https://github.com/WordPress/gutenberg/issues/24337), please. If it seems appropriate, I can built it out for the rest of the existing blocks that support the feature, but thinking it’s possible this change should happen higher up somewhere so that blocks don’t have to adjust for it. [@annezazu](https://profiles.wordpress.org/annezazu/) * I’ve mainly focused on the FSE Outreach Program responding to the current call for testing and pausing to get some feedback for how to improve the program. * I plan to ship another call for testing shortly after this current one ends alongside a summary post. * I want to experiment tomorrow too with holding a friendly, casual zoom call for about 30-45 min to talk through some fun FSE issues/designs/PRs that have caught my attention! Join [#fse-outreach-experiment](https://wordpress.slack.com/archives/C015GUFFC00) to stay tuned if that’s of interest. [@aristath](https://profiles.wordpress.org/aristath/) * I’ve been working on ways to make hybrid themes a reality. Among other things, [there’s a PR to allow loading a block-based header & footer in classic themes ](https://github.com/WordPress/gutenberg/pull/30345) which should help theme-authors to slowly start transitioning parts of their themes to FSE. * Other than that, lots of PR reviews. * Next week I will probably keep working on the same things: FSE MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development."- [WikiPedia](https://en.wikipedia.org/wiki/Minimum_viable_product) & hybrid-themes. [@joen](https://profiles.wordpress.org/joen/) * I’ve been continuing on the Navigation block, polishing and polishing. While it’s in a good place, it’s opening up some grand questions about the next steps, all exciting ones. And I’m excited to delve into patterns for it as soon as I can. ## Open Floor **Are there any updates for a home/name for Site Editor Documentation? Raised by [@poena](https://profiles.wordpress.org/poena/). ** Carolina brought up a [previous post from early February](https://make.wordpress.org/docs/2021/02/18/a-home-and-a-name-for-site-editor-documentation-full-site-editing-feature/) asking whether there was an update around the name and place for documentation as currently it’s causing blockers/confusion for how to proceed. Currently, the documentation in the block editor handbook that’s related to FSE is in several places and pretty difficult to find. At the same time, as interest grows around FSE, people are seeking out more information. For example, one of the concerns that Carolina shared was around how if the documentation is in the theme developer handbook or the block editor handbook, it will be difficult to find and likely not visible enough for when a large number of people are first introduced to FSE. Carolina then passed along a suggestion to have a “front page” with basic explanations of the key concepts that then guides visitors to user or developer docs depending on their interests. After some back and forth discussion, a loose consensus was reached on the following: * The lack of a decision around name and placement shouldn’t stop us from creating docs and organizing them properly when these things get clarified. * The go/no go dates should provide clarification this month around what needs to be documented first. * An introduction page that can guide people curious about FSE likely needs to be created or at least explored. * Exploring renaming the “Block Editor Handbook” to something more general might help alleviate some of these concerns by making the Handbook more flexible to allow for FSE items. **Next steps: **[@mkaz](https://profiles.wordpress.org/mkaz/) will kick off a discussion for renaming the handbook and create an issue for an initial intro FSE page to direct people. [#core-editor](https://make.wordpress.org/core/tag/core-editor/), [#core-editor-summary](https://make.wordpress.org/core/tag/core-editor-summary/), [#gutenberg](https://make.wordpress.org/core/tag/gutenberg/) [ ](https://profiles.wordpress.org/boniu91/) [Piotrek Boniu](https://profiles.wordpress.org/boniu91/) 12:50 pm _on_ April 7, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [test ( 16 )](https://make.wordpress.org/core/tag/test/), [testing ( 25 )](https://make.wordpress.org/core/tag/testing/) # 󠀁[Early test scrub for WordPress 5.8](https://make.wordpress.org/core/2021/04/07/early-test-scrub-for-wordpress-5-8/)󠁿 As a part of the 5.8 release, we’ll be hosting early test scrub for WordPress 5.8 on [2021-04-09 13:30](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210409T1330) in the [core-test](https://app.slack.com/client/T024MFP4J/C02RQBWTW) 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/32579) [https://core.trac.wordpress.org/ticket/52226](https://core.trac.wordpress.org/ticket/52226) [https://core.trac.wordpress.org/ticket/52521](https://core.trac.wordpress.org/ticket/52521) [https://core.trac.wordpress.org/ticket/52662](https://core.trac.wordpress.org/ticket/52662) [https://core.trac.wordpress.org/ticket/40570](https://core.trac.wordpress.org/ticket/40570) [https://core.trac.wordpress.org/ticket/39108](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](https://wordpress.org/plugins/wordpress-beta-tester/)( choose the “Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as [trunk](https://make.wordpress.org/core/2021/page/43/?output_format=md#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./ RCrelease 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)](https://make.wordpress.org/core/2021/page/43/?output_format=md#alpha-beta). 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](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` ```wp-block-preformatted npm run grunt patch:35449 ``` How to fetch and then checkout a PR, for example, PR 828 ```wp-block-preformatted git fetch upstream pull/828/head:pr-828git checkout pr-828 ``` or for PR: ```wp-block-preformatted npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/828 ``` Check the handbook for more ways to [test patches](https://make.wordpress.org/core/handbook/testing/patch/). Looking forward to seeing you! [#test](https://make.wordpress.org/core/tag/test/), [#testing](https://make.wordpress.org/core/tag/testing/) [#5-8](https://make.wordpress.org/core/tag/5-8/) [ ](https://profiles.wordpress.org/francina/) [Francesca Marano](https://profiles.wordpress.org/francina/) 5:20 pm _on_ April 6, 2021 Tags: [5.7.1 ( 20 )](https://make.wordpress.org/core/tag/5-7-1/), [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [agenda ( 1,142 )](https://make.wordpress.org/core/tag/agenda/), [dev chat ( 922 )](https://make.wordpress.org/core/tag/dev-chat/)    # 󠀁[Dev Chat Agenda for April 7, 2021](https://make.wordpress.org/core/2021/04/06/dev-chat-agenda-for-april-7-2021/)󠁿 Here is the agenda for this week’s meetings to occur at the following times: [April 7, 2021 at 5:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210407T0500) and [April 7, 2021 at 20:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210407T2000). ## Announcements * [Gutenberg 10.3 released](https://make.wordpress.org/core/2021/04/02/whats-new-in-gutenberg-10-3-31-march/) * ETA [Early test scrub for WordPress 5.8](https://make.wordpress.org/core/2021/04/07/early-test-scrub-for-wordpress-5-8/) * ETA The [5.7.1 maintenance release candidate](https://core.trac.wordpress.org/tickets/minor/workflow) is scheduled to be released at 2300 UTC on April 7th ## Blogblog (versus network, site) Post Highlights * [[[A Week in Core – April 5, 2021](https://make.wordpress.org/core/2021/04/05/a-week-in-core-april-5-2021/) * [Core Editor Improvement: Easier than ever to find the blocks you need](https://make.wordpress.org/core/2021/03/31/core-editor-improvement-easier-than-ever-to-find-the-blocks-you-need/) * [Did you know there is a new podcast in town? ](https://wordpress.org/news/podcast/) ## Blog posts that need feedback * [Thoughts on Marketing, FSE, and What’s Next](https://make.wordpress.org/marketing/2021/03/30/thoughts-on-marketing-fse-and-whats-next/) * [ETA Finalize the release schedule](https://make.wordpress.org/core/2021/03/30/5-8-pre-planning/) ## Components check-in and status updates * Check-in with each component for status updates. * Poll for components that need assistance. ## Open Floor Do you have something to propose for the agenda, or a specific item relevant to our standard list above? Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly. This meeting happens in the [#core](https://wordpress.slack.com/messages/C02RQBWTW) channel. To join the meeting, you’ll need an account on the [Making WordPress Slack](https://make.wordpress.org/chat/). [#5-7-1](https://make.wordpress.org/core/tag/5-7-1/), [#5-8](https://make.wordpress.org/core/tag/5-8/), [#agenda](https://make.wordpress.org/core/tag/agenda/), [#dev-chat](https://make.wordpress.org/core/tag/dev-chat/) # Post navigation [← Older posts](https://make.wordpress.org/core/2021/page/44/?output_format=md) [Newer posts →](https://make.wordpress.org/core/2021/page/42/?output_format=md)