Josepha 7:54 pm on April 8, 2021  

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
sarayourfriend 12:45 pm on April 9, 2021  

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.

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/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

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

annezazu 5:28 pm on April 7, 2021
Tags: , ,   

Editor chat summary: 7 April, 2021

This post summarizes the weekly editor chat meeting (agenda here) held on 2021-04-7 14:00 UTC in Slack. Moderated by @annezazu.

Announcements

Monthly Priorities & Key Project Updates

Full Site Editing from @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 themes as well which should provide a nice transition point.

Global Styles from @nosolosw

Shipped:

  • Block Supports: added a gutenberg_block_has_support helper function and support for padding in dynamic blocks 30322, border for search block #30227.
  • Fixes: title in the save panel of the site editor 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.

Ongoing

  • Block supports: border for button block #30194, add border color/style/width properties #30124, spacing #30333 #30371.
  • Theme.json: Update format #29891, there’s now a draft PR at #30541, conversation about whether and how to expand the use of CSSCSS Cascading Style Sheets. Custom Properties #29714

Navigation Block from @mkaz and @andraganescu

Updates and improvements keep chugging along! The dependency on responsive nav will likely get merged today, and then the responsive PR can move forward. A new update attempts to fix the HTML produced by the block. This is blocked by the lack of advancement in the discussions opened by @talldanwp (Issue30007 and Issue30006). 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. The best way to follow along is by labels in 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/ PRs or this tracking issue.

Navigation Editor from @andraganescu

The Block based Navigation editor is advancing with a host of PRs aimed at polishing various functionality (PR30374, PR30403, PR30524 , PR30340) and some that could use a review and testing (PR30446, PR30440, PR30349).

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

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

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)

New In Progress

  • Slash inserter

Still In Progress

  • Dual licensing Gutenberg: planning to merge the PR with interim license 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

@ntsekouras

@mamaduka

  • Still working on the “Most used tags” feature.
  • Fixed “the same key” prop issue 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. 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

  • I’d love feedback on the approach in this PR for 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

  • 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 to stay tuned if that’s of interest.

@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 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 & hybrid-themes.

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

Carolina brought up a previous post from early February 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 will kick off a discussion for renaming the handbook and create an issue for an initial intro FSE page to direct people.

#core-editor, #core-editor-summary, #gutenberg

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

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 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!

#test, #testing

Francesca Marano 5:20 pm on April 6, 2021
Tags: ,   

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 and April 7, 2021 at 20:00 UTC.

Announcements

Blogblog (versus network, site) Post Highlights

Blog posts that need feedback

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 channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #dev-chat