A Week in Core – July 4, 2022

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

  • 32 commits
  • 34 contributors
  • 63 tickets created
  • 5 tickets reopened
  • 52 tickets closed

The Core team is currently working on the next 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., WP 6.1 and on the next minor, WP 6.0.1 🛠

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

Code changes

Build/Test Tools

  • Add support for WP_Error in the test suite’s wp_die() handlers – #55652
  • Correct some 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/ Action workflow inline documentation – #55652
  • Enable loopback requests to work on the local development environment – #52708
  • Include the actual _doing_it_wrong() message or deprecation notice in the output – #55652
  • Remove an unused build configuration file – #52604
  • Remove the workflow_run event from the 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/. notification workflow – #56095
  • Run the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher container with PID > 1 so Ctrl+C works correctly – #55702
  • Update 3rd party GitHub Actions – #55652
  • Update NPM devDependencies to their latest versions – #55652
  • Update the actions/cache action – #55652

Bundled Themes

  • Twenty Eleven: Replace deprecated function calls on theme options page – #54833

Coding Standards

  • Escape the home URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org in the “Background updated. Visit your site” message – #56133
  • Escape the home URL in the “HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. updated. Visit your site” message – #56132

Comments

  • Use more appropriate escaping functions in class WP_Comments_List_Table#56101

Docs

  • Add @since tags for _doing_it_wrong() and deprecation notice handlers in the PHPUnit test suite – #55652, #55646
  • Add @since tags for wp_die() handlers in the PHPUnit test suite – #55652, #55646
  • Add missing docblockdocblock (phpdoc, xref, inline docs) description for install_themes_upload()#55646
  • Adjust some DocBlocks in wpdb per the documentation standards – #52506, #55646
  • Misc fixes in ShortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. 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. function and hook descriptions, as per documentation standards – #55646
  • Update the version in which Meetup.com was removed as an oEmbed source – #55997
  • Use third-person singular verbs for function descriptions in WP_Comments_List_Table class, as per docblock standards – #55646

Editor

  • Alphabetize 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. lists in various places – #56131
  • Ensure only the main query is modified when resolving template for new posts – #56058
  • Register the Comments Query LoopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. block from metadata – #56093, #55809
  • Update block editor packages for WordPress 6.0.1 – #56058

General

  • Revert an earlier define of the WPINC constant in src/index.php#54233

Help/About

  • Add help tab info for available row actions in the Media Library – #55800
  • Typo correction in the Media Library help tab text – #55800

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

  • Add missing options to the settings endpoint – #56058
  • Use the integer type for page_on_front and page_for_posts options – #56058

TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.

  • Pass the $args parameter to all actions and filters in wp_insert_term() and wp_update_term()#55441

Widgets

  • Add a comment in WP_Nav_Menu_Widget::form() to clarify the esc_attr() usage – #56128

Props

Thanks to the 34 people who contributed to WordPress Core on Trac last week: @SergeyBiryukov (5), @costdev (4), @hztyfoon (3), @gziolo (3), @zieladam (2), @Mamaduka (2), @kebbet (2), @mukesh27 (2), @audrasjb (2), @rudlinkon (2), @peterwilsoncc (2), @viralsampat (1), @jameskoster (1), @spacedmonkey (1), @manfcarlo (1), @sajjad67 (1), @ndiego (1), @poena (1), @petitphp (1), @sabernhardt (1), @tomjdv (1), @cu121 (1), @afragen (1), @Presskopp (1), @mboynes (1), @jakariaistauk (1), @robinwpdeveloper (1), @chintan1896 (1), @adamziel (1), @bernhard-reiter (1), @cbravobernal (1), @hasanuzzamanshamim (1), @sandrasanzdev (1), and @aristath (1).

Congrats and welcome to our 7 new contributors of the week: @hztyfoon, @petitphp, @tomjdv, @cu121, @jakariaistauk, @robinwpdeveloper, @sandrasanzdev ♥️

Core committers: @sergeybiryukov (17), @audrasjb (6), @desrosj (5), and @johnbillion (4).

#6-1, #core, #week-in-core

Editor chat summary: Wednesday, 29 June 2022

This post summarizes the weekly editor chat meeting on Wednesday, 29 June 2022, 14:00 UTC held in Slack.

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/ 13.6 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).

@jorgefilipecosta Released Gutenberg 13.6 RC today. The release could be downloaded at https://github.com/WordPress/gutenberg/releases/tag/v13.6.0-rc.1. The changelog could also be checked on the same link.

WordPress 6.0.X

Information related to future 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. releases of 6.0 can be checked on https://make.wordpress.org/core/2022/06/25/wordpress-6-0-x-release-team-and-6-0-1-schedule/.

On the editor side @zieladam is going to help with 6.0.1 for future releases there is an opening if someone is able to help.

WordPress 6.1

The planning post for WordPress 6.1 is available at https://make.wordpress.org/core/2022/06/23/wordpress-6-1-planning-roundup/. There are some positions opened on the release squad so if something interests feel free to volunteer in that post.

The BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 & Feature Freeze is scheduled for September 20, 2022.

Key project updates

Building with patterns & Styles

Now we have the ability to use start patterns on a modal on other post types besides pages https://github.com/WordPress/gutenberg/pull/41791. A much-requested feature.

@jorgefilipecosta proposed PR to target descend 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. styles in a block using s shape equivalent o 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. on https://github.com/WordPress/gutenberg/pull/41922. It allows more styling flexibility when building a pattern.

Task coordination

@get_dave

@jorgefilipecosta

  • Previously:
    • Proposed a mechanism to allow the usage of the start post pattern modal on other post types besides pages.
    • Added an 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. to allow a pattern to be restricted to some post types
    • Proposed an API to allow blocks to style their descendent blocks.
    • Multiple bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, code enhancements, and reviews.
  • Future:
    • Implement the rendering of block-level presets.
    • Help the effort to expand the templates that can be created on the site editor.

@mamaduka

Is looking for technical feedback/review for my new PR to allow locking inner blocks from the container block – https://github.com/WordPress/gutenberg/pull/41876.

Open Floor

Toolbar regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5.

@get_dave said that the toolbar has suffered a regression whereby it now obstructs blocks that are at the top of the viewport. The Nav block is badly affected by this. If anyone is available to work on this that would be great. I know @talldanwp has also promised to give it some attention.

@jorgefilipecosta asked if already know the PR that caused the regression. @get_dave said the popover component upgrade is the probable cause and added @talldanwp is investigating.

Weekly bug scrub

@NickDiego shared in the meeting that now we are now holding weekly Editor Bug Scrubs at 1400 UTC on Tuesdays here in #core-editor he and @mamaduka held the first one this week. Everyone is encouraged to participate and help on the weekly bug scrubs.

Request for RTL testing

@poena said:

There is a PR for RTL styles that could use more testing by someone who uses an RTL language as their default for the editor:

https://github.com/WordPress/gutenberg/pull/41762

So if you usually use RTL language your help is greatly appreciated.

#agenda, #core-editor, #editor, #summary

Proposal: Better REST API handling in JavaScript

This call for feedback will be open for the next two weeks until July 18th.

I propose extending the useEntityRecord hook to support editing and deleting WordPress data. It should make building features and plugins on top of WordPress 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/. easier.

The hook is a part of @wordpress/core-data, a 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/. package providing tools for interacting with the WordPress REST API. You may know coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-data from Redux selectors, actions, and ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. like  getEntityRecord, saveEntityRecords, useSelect.

Today, useEntityRecord enables easy access to data

The useEntityRecord hook enables fetching data with just a single line of code:

import { useEntityRecord } from '@wordpress/core-data';
 
// Inside of a React Component:
function PageTitle() {
    const { record, hasResolved } = 
        useEntityRecord( 'postType', 'page', 15);
    return hasResolved ? record.title : 'Loading...';
}

It was introduced to 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 in PR #38782 and will land in WordPress core in 6.1, the next 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..

For comparison, achieving the same result without useEntityRecords requires much more knowledge about the Gutenberg internals:

import { useSelect } from '@wordpress/data';
import { store as coreDataStore } from '@wordpress/core-data';

// Inside of a React Component:
function PageTitle() {
	const { page, hasResolved } = useSelect(
		( select ) => {
			const selectorArgs = ['postType', 'page', 15];
			return {
				page: select( coreDataStore )
					.getEntityRecord( ...selectorArgs ),
				hasResolved: select( coreDataStore )
					.hasFinishedResolution(
						'getEntityRecord',
						selectorArgs
					),
			};
		},
		[]
	);
	return hasResolved ? page.title : 'Loading...';
}

Tomorrow, useEntityRecord could ease editing data

In PR #39595, I proposed taking useEntityRecord one step further to make editing WordPress data equally easy:

const { record, edit, editedRecord, hasEdits, save } =
	useEntityRecord( 'postType', 'page', pageId );

// edit({ title: “My new title” });
// save();

// After React re-render:
// console.log( record.title );
// "My new title"

In comparison, this is how it’s done today:

const {
	editEntityRecord,
	saveEditedEntityRecord,
} = useDispatch( coreStore );

const { record, editedRecord, hasEdits, isSaving, saveError } =
	useSelect(
		( select ) => {
			const args = [ kind, type, id ];

			return {
				editedRecord: select( coreStore )
					.getEditedEntityRecord( ...args ),
				hasEdits: select( coreStore )
					.hasEditsForEntityRecord( ...args ),
				isSaving: select( coreStore )
					.isSavingEntityRecord( ...args ),
				saveError: select( coreStore )
					.getLastEntitySaveError( ...args ),
			};
		},
		[ kind, type, id ]
	);

// editEntityRecord(kind, type, id, { title: “My new title” });
// saveEditedEntityRecord(kind, type, id);

// After React re-render:
// console.log( record.title );
// "My new title"

I combed through the WP Directory and found existing plugins that could already benefit from this pattern.

If this resonates with you, speak out before July 18th!

Introducing new APIs means having to maintain them indefinitely. Therefore, I would like to confirm this proposal offers an attractive solution to a real problem. This post attempts to do just that, and I would love to hear from you! All opinions are welcome, especially if:

  • Your JavaScript code interacts with the WordPress REST API
  • You’re maintaining code that leans on wordpress/core-data
  • You’ve struggled to learn how to use it
  • This new 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. would be helpful for you
  • You’re not convinced there’s a need to introduce such an API

I’m also interested in all the code samples related to editing and saving entity records that you are willing to share. It would be a great way to validate and exercise the proposed API.

This call for feedback will be open for the next two weeks until Jul 18, 2022.

Props to Anne McCarthy (@annezazu) and Grzegorz Ziółkowski (@gziolo) for their help in putting this proposal together.

#editor, #gutenberg, #proposal

Performance Chat Agenda: 5 July 2022

Here is the agenda for next week’s performance team meeting scheduled for July 5, 2022, at 15:00 UTC.


This meeting happens in the #performance channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

X-post: Exploration: improving DevHub

X-post from +make.wordpress.org/meta: Exploration: improving DevHub

Plan for adding WebP & multiple MIME support for images

This post is a follow up to the “Enabling WebP by default” proposal post (and the follow up to that post). 

TL;DR – The Performance Team has reviewed feedback, conducted research, and reassessed the approach based on our findings. Our new approach – outlined below – aims to address the concerns raised on the original proposal.

Overview

The Performance Team takes community feedback very seriously. As a result of the concerns around our previously proposed approach to serving WebP, we took a step back to reassess and dig deeper into the specific issues raised in post comments, chat, and elsewhere. This work has included:

  • Reviewing comments from the original and follow-up posts
  • Engaging in research (as noted in #289 & #290) on the storage impact of additional WebP images being created on upload and WebP compatibility across browsers, email clients, etc.
  • Sharing a survey with hosting providers to gather information about their storage and disk space infrastructure

What we found

Our goal with this research and reassessment was to collect data and additional context about each of the concerns raised by the community. With this additional information, we were then able to better understand and prioritize concerns, as well as determine how and why our approach to adding WebP should be modified.

WebP Compatibility

The team did additional research on WebP compatibility to better understand where compatibility issues might cause issues for users. Our research indicated that most compatibility issues were very minor and/or addressable:

  • Web browser compatibility: Only Safari on Mac OS < 11 and iOSiOS The operating system used on iPhones and iPads. < 14 do not support WebP, which is < 3% of all browser usage. This small percentage of non-supporting browsers will be served JPEG images. 
  • Email clients: > 97% of clients support WebP.
  • Mobile apps (web views): iOS 14+ supports WebP (and otherwise will be served JPEG images with the new approach). Android supports WebP natively from Android 4.0.
  • RSS readers: Top RSS readers all support WebP, so RSS feeds can likely leverage WebP.
  • Other: Open Graph tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) consumers have mixed support, so OG tags should remain JPEGs for compatibility.

Storage

To assess the overall impact of generating WebP images on site storage, the team surveyed hosting providers. With a total of 17 responses, the results show that the number of stored files is generally not an issue for most hosts/sites, although storage space could become an issue for some users over time. Still, for large hosts (with 1,000 or more hosted sites), the vast majority of sites (> 86%) would be unaffected, even if their storage requirements doubled. We also learned that some lower-end hosting plans with limited storage also lack WebP support in their hosting stack, which means they won’t get extra image generation anyway.

The revised approach

Based on the results of the research outlined above, our new proposed approach addresses compatibility issues by:

  • Providing a tiny (355 bytes uncompressed) 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/. snippet that detects browsers that lack WebP support and loads JPEGs instead [tracking issue]
  • Only using WebP for user-facing content in the front-end (template) context. Images in other contexts like Open Graph tags, RSS feeds, and REST endpoints would continue to use JPEGs [tracking issue]
  • Adding a new parameter to the `add_image_size()` function that lets developers control whether to generate additional MIME types for each size registered. For the vast majority of image sizes this should be set to `true`; the only exceptions are image sizes that are being used exclusively outside of user-facing front-end content, such as Open Graph tags. Only for those special cases should the parameter be set to `false` to not generate additional MIME types. Developers registering custom image sizes with `add_image_size` will need to specify if the size should generate secondary MIME types by version 6.2, when we plan to make this behavior the default in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

This new approach also addresses concerns around storage requirements by:

  • Automatically generating WebP versions of only core image sizes in 6.1 by default. Custom image sizes will initially have to opt in to receive automatically generated WebP versions, or opt out if they are exclusively used for special cases where WebP is not beneficial or supported.
  • Keeping secondary (WebP) sub-sizes only if they are smaller than the primary MIME type.
  • Only generating WebP images for image sizes that are intended for use in user-facing front-end content. This avoids wasting storage space for WebP images that will never be used.
  • Introducing a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to control the generation of additional MIME types based on image sub-sizes. This enables developers to exclude certain image sizes, such as those that are not used in front-end content. 

Next Steps

The approach in the core patch is being updated to reflect the revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. outlined above. The current plan is to merge this change early in the 6.1 release cycle so that it can be thoroughly tested. Additional feedback regarding this revised approach can be left on this post or the Trac ticket.

#core-images, #media, #performance

Devchat summary, June 29, 2022

@marybaum led the meeting on this agenda.

For your records, last week’s summary came from @chanthaboune.

Announcements

@craigfrancis gave a big shoutout to the folx who helped him on tickey #52506, which will likely be ready to land in 6.1. (TL;dr it’s a much-needed database-access improvement).

Blogblog (versus network, site) posts of note

A Week in Core from @audrasjb

A call for testing from @afragen

And two reposts from @chanthaboune‘s summary:

There’s a discussion about how to update the wp-admin experience.

There’s a discussion on Yoda conditions (which started in the WPCS repo)

Upcoming releases

The next major is 6.1.

@bph shared @priethor‘s 6.1 planning roundup. Leave a comment there if you’d like to volunteer!

Birgit also shared this report. The current schedule, which is not confirmed, shows feature freeze is September 20, roughly eleven weeks from now.

There was some discussion.

The next minor is 6.0.1.

Here’s the plan!

Open floor

@craigfrancis asked for eyes on #54042 (PR:2191).

@sergey reported on his components.

  • Build/test tools:
    • #55652 updates npm and other dependencies to their latest versions.
    • #39265 continues progress on adding missing `@covers` tags for the WordPress 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. suite.
  • General: #56009 and #56033 are starting the process of modernizing code to support PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.2.

    On those tickets, Sergey thanked @desrosj, @jrf, @azaozz, @pbearne, @hellofromtonya, @antonvlasenko, @ironprogrammer, and @costdev.

@sabernhardt announced that a special `good-first-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 will start today at 21:00 UTC, right after the usual weekly 6.1 scrub.

And @afragen would like help testing his feature plugin that’s all about plugin dependencies. More details are here.

#core, #dev-chat, #summary

Making the Tech Editor Release Lead Role More Creative and Less Repetitive

Merging 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/ to WordPress on major releases is now more automated than ever.

@zieladam (me) and @gziolo were the tech editor release leads for WordPress 6.0. We’ve quickly noticed that ~30% of the role is about communication and decision making, while ~70% consists of repetitive weekly chores. We want to reverse these proportions.

Most repetitive work falls into one of the two categories:

  • Backporting PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher changes made in the Gutenberg 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 since the previous major WordPress release
  • Releasing weekly 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). versions

Backporting PHP changes made in the Gutenberg plugin since the previous major WordPress release

Finding and backporting all the PHP Pull Requests merged to Gutenberg but not to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is a huge task.

For WordPress 6.0, it took us two days just to prepare the list. From there, it was two weeks of pinging, coordinating, reviewing, and merging code before we were done. Furthermore, not all the authors had the availability to help at that point in time.

This cannot be easily automated, but imagine the alternative: Gutenberg developers prepare PRs against WordPress core in parallel with merging their Gutenberg PRs. Any integration issues get surfaced right away, there are fewer merge conflicts, and the release leads don’t have to spend two weeks investigating the commit history and pinging code authors. The future availability of the developers isn’t a problem anymore either.

If that sounds appealing, come and speak up in the ongoing GitHub discussion!

Releasing weekly Beta/RC versions

The weekly release consists of four repetitive tasks:

  • Cherry-pick triaged code to a Gutenberg release 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".
  • Release Gutenberg @wordpress packages from that branch
  • Update the version of packages used in wordpress-develop
  • Manually stabilize any blocks to be included in the new release

@zieladam (me) and @gziolo added a degree of automation to all of the above.

Cherry-pick triaged code to a Gutenberg release branch

Bringing Gutenberg Pull Requests over to WordPress after Beta 1 requires cherry-picking the relevant commits.

Before, this involved manually resolving conflicts and letting the author know. A few times I got confused and spent more time on it than I hoped to.

Today, the new npm run cherry-pick script automates all of that (except resolving conflicts). Furthermore, it can be repurposed for the Gutenberg plugin releases.

Publish the updated @wordpress packages from the release branch

After cherry-picking the relevant changes to the release branch, the way to bring these changes to WordPress core is through npm packages.

Before, it took publishing permissions, a specific local setup, and remembering the correct command with the proper CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. parameters. With all that in place, you ran the built process, waited a longer while, and then published the packages.

Today, this entire process can now be triggered directly from GitHub UI after approval from any Gutenberg core team member.

Update the version of packages used in wordpress-develop

With fresh @wordpress packages published to the NPM registry, the next step is to update the dependencies in wordpress-develop.

Before, it involved a manual synchronization of the new Gutenberg dependencies with the package.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. file shipped in wordpress-develop. You had to add any new dependencies, update the versions of the existing ones, and delete ones that were no longer used.

Today, the new sync-gutenberg-packages console task automates this effort.

Manually stabilize any blocks to be included in the new release

Finally, a number of steps are required to enable the new stable blocks in WordPress core.

Before, you had to manually list the new blocks in a few .php and .js files and double- or triple-check whether all these lists are in sync. As there are other build steps at play, the resulting Pull Request is quite large. Even though @zieladam and @gziolo were careful, we still ended up making mistakes.

Today, the new sync-stable-blocks console task reduces the entire process to running a single command. All the relevant lists are generated automatically making the process easier and removing any chance for human error.

Next steps

Wiring the above automations to run sequentially would streamline the entire process to a single click of the button:

  • Take a list of Gutenberg PRs as an input
  • Create a Pull Request against wordpress-develop as an output (example)

With the caveat that merge conflicts would still have to be resolved manually.

I’d love to inspire the next release squad to explore this during the 6.1 release cycle.

By simplifying these two large areas, I believe we can truly make the Tech Editor Release LeadRelease Lead The community member ultimately responsible for the Release. role mostly about the decision, communication, and creative work without so many repetitive tasks.

Props to Héctor Prieto (@priethor) and Grzegorz Ziółkowski (@gziolo) for their help in putting this post together.

#6-0-1, #6-1, #core, #core-editor, #gutenberg

X-post: Learn WordPress Development: Creating a Public Roadmap for Content Creation

X-post from +make.wordpress.org/training: Learn WordPress Development: Creating a Public Roadmap for Content Creation

Devchat agenda, June 29, 2022

1. Welcome

Last week’s summary

2. 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/ 13.6 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). 1

3. Blogblog (versus network, site) posts of note

A week in Core, June 27

4. Upcoming releases

The next major is WordPress 6.1.

If you have early tickets, announcements, or you need some help, there’s time here for you.

The next minor is WordPress 6.0.1.

@annezazu has published a team and a schedule!

5. Open floor

Component maintainers with reports have priority. Then, if you have an item, please add it to the comments. If you aren’t going to make the chat, please say so, and the facilitators will bring up your item. If you have a report, the group can post that for you too — again, if a facilitator knows about it.

#6-0-1, #6-1, #agenda