Using multiple stylesheets per block

Prior to WordPress 5.9, each 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. could (but not required to) have a stylesheet attached to it. The way blocks could register a stylesheet was by adding a style and/or editorStyle string in their block.json file.

In WordPress 5.9 we’re enhancing that behavior to allow using multiple stylesheets to be registered for each block. This change can benefit both block developers and theme developers, further reducing the total page-weight by only loading styles for blocks that exist on a page.

Blocks will now be able to register multiple stylesheets, and load styles from other blocks when needed. Themes will be able to add styles on a per-block basis instead of loading monolithic stylesheets that are force-loaded anywhere. This has a greater impact on block themes where stylesheets loading is optimised based on the page & layout contents, but can also be used by classic themes.

Usage for block developers

The style and editorStyle properties inside a block.json file can now be either a string, or an array of strings. Each string can be the handle of a previously registered stylesheet, or a path relative to the block.json file’s path, prefixed with file:./.

If you already have a block that uses a string, you needn’t worry. Everything will continue to work as expected. This is not a breaking change as the values can be either an array or a string, to maintain backward-compatibility.

This allows for complex blocks to reuse styles they need from other blocks without the need to duplicate those styles. For example, the comment-form block in WordPress 5.9 doesn’t need to duplicate the button block’s styles, and can instead reuse these styles by adding them to the block.json file:

{
 	"style": [
		"wp-block-post-comments-form",
		"wp-block-buttons",
		"wp-block-button"
	]
}

The same applies to the editorStyle value: Block developers can now define an array of styles, using the same format as the style value.

Usage for theme developers

Theme developers can also register stylesheets on a per-block basis. This way, no unnecessary styles will be rendered on a page unless the block is rendered (assuming the theme is a block-theme, or has opted-in to load separate stylesheets in the case of classic themes).

To do that, a new wp_enqueue_block_style() function was introduced.

The wp_enqueue_block_style function

The wp_enqueue_block_style function accepts 2 arguments, both of which are required:

$block_name

(string, required)

The name of the block – including its prefix/domain. For example the block_name of the paragraph block is core/paragraph.

$args

(array, required)

The arguments are the same used in the wp_enqueue_style function:

$args = array(
	'handle' => 'my-theme-p-styles',
	'src'    => get_theme_file_uri( 'styles/blocks/paragraph.css' ),
	...
);

In addition to the default wp_enqueue_style arguments, you can also add a path argument. This will allow WordPress to inline small assets when possible – if the theme opts-in to that behavior.

Example

Registering an extra stylesheet for the site-title block from a theme:

add_action( 'after_setup_theme', function() {
	// Same args used for wp_enqueue_style().
	$args = array(
		'handle' => 'my-theme-site-title',
		'src'    => get_theme_file_uri( 'assets/blocks/site-title.css' ),
	);

	// Add "path" to allow inlining asset if the theme opts-in.
	$args['path'] = get_theme_file_path( 'assets/blocks/site-title.css' );

	// Enqueue asset.
	wp_enqueue_block_style( 'core/site-title', $args );
} );

WordPress 5.9 enhances the way stylesheets for blocks get loaded. Though these changes have not been ported to block scripts yet, in future releases we plan to sync the two APIs, so block scripts can take advantage of them as well.

props @gziolo for reviewing this post.

#dev-notes, #developer-documentation

Posts, Post types and Taxonomy changes in WordPress 5.9

In WordPress 5.9, new 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. and functions are added to help developers to work with Posts, Post types and Taxonomies.

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

WP 5.9 introduces the new is_post_type_viewable filter to allow developers to hook into is_post_type_viewable() to override the check performed by this function.

This filter exposes the $post_type object to allow to return either true or false depending on their needs. The expected filtered value is a boolean. As filtered values can change, including the data type, this commit includes a is_bool() check, thus ensuring backwards-compatibility and guard against potential type errors in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.1+. Non-boolean values (even falsey and truthy values) will result in the function returning false.

Usage:

/**
 * Override is_post_type_viewable() value for the "Books" custom post type. 
 */
function wporg_books_is_not_a_viewable_post_type( $is_viewable, $post_type ) {
	if ( __( 'Books', 'my-plugin' ) === $post_type->label ) {
		return false;
	}
	return $is_viewable;
}
add_filter( 'is_post_type_viewable', 'wporg_books_is_not_a_viewable_post_type', 10, 2 );

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

is_post_status_viewable filter

Similarly to is_post_type_viewable, the is_post_status_viewable filter allow developers to hook into the related PHP function. This filter exposes the $post_status object to allow to return either true or false depending on their needs.

Usage:

/**
 * Override is_post_status_viewable() value for the "Unread" custom post status. 
 */
function wporg_unread_is_not_a_viewable_post_status( $is_viewable, $post_status ) {
	if ( __( 'Unread', 'my-plugin' ) === $post_status->label ) {
		return false;
	}
	return $is_viewable;
}
add_filter( 'is_post_type_viewable', 'wporg_unread_is_not_a_viewable_post_status', 10, 2 );

Related ticket on Trac: #54375.

post_thumbnail_url filter

WP 5.9 Introduces the new filter post_thumbnail_url which allows overriding the default url returned from wp_get_attachement_image_url() function. It passes the following parameters:

  • $thumbnail_url: The Post thumbnail URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org (or false if the post does not exist)
  • $post: The Post ID or WP_Post object. Default is global $post
  • $size: The Registered image size to retrieve the source for or a flat array of height and width dimensions. Default value: post-thumbnail

Usage:

/**
 * Override the post thumbnail URL for a specific template.
 */
function wporg_change_post_thumbnail_url_for_about_template( $thumbnail_url, $post, $size ) {
	if ( 'templates/about.php' !== get_page_template_slug( $post ) ) {
		return wp_get_attachment_image_url( get_template_directory . '/images/my-specific-image.png' );
	}
	return $thumbnail_url;
}
add_filter( 'post_thumbnail_url', 'wporg_change_post_thumbnail_url_for_about_template', 10, 3 );

Related ticket on Trac: #40547.

post_thumbnail_id filter

Similarly, WP 5.9 introduces the new post_thumbnail_id filter which allows overriding the default id returned from get_post_thumbnail_id(). It passes the following parameters:

  • $thumbnail_id: The Post thumbnail ID (or false if the post does not exist)
  • $post: The Post ID or WP_Post object. Default is global $post

Related ticket on Trac: #23983.

New labels available in register_taxonomy()

In WP 5.9, some static strings were replaced with additional label options to allow developers further flexibility for customizing the Edit {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.} screen.

The following labels were added:

  • name_field_description: Description for the Name field on Edit Tags screen. Default: “The name is how it appears on your site.”
  • parent_field_description: Description for the Parent field on Edit Tags screen. Default: “Assign a parent term to create a hierarchy. The term Jazz, for example, would be the parent of Bebop and Big Band.”
  • slug_field_description: Description for the Slug field on Edit Tags screen. Default: “The « slug » is the URL-friendly version of the name. It is usually all lowercase and contains only letters, numbers, and hyphens.”
  • desc_field_description: Description for the Description field on Edit Tags screen. Default: “The description is not prominent by default; however, some themes may show it.”

Related ticket on Trac: #43060.

New function to get the URL for existing 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. of a post: wp_get_post_revisions_url()

Since WP 5.9, the wp_get_post_revisions_url() function can be used to get a link to a given post’s revisions.

Parameters:

  • $post_id (optional): Post ID or WP_Post object. Default is global $post.

This function returns the URL for editing revisions on the given post (or null otherwise).

Related ticket on Trac: #39062.

New built-in post types in WP 5.9

Please note that WordPress 5.9 introduces four new built-in post types related to the new full site editing experience and are used when a 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. Theme is activated.

  • wp_template: The templates to include in your theme.
  • wp_template_part: The template parts to include in your templates.
  • wp_global_styles: The styles created and saved by the site adminadmin (and super admin) for the current theme.
  • wp_navigation: The navigation menus that can be inserted into the site.

Additional dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. will be published to introduce the new full site editing experience. Note the above post types are reserved terms for WordPress internal usage.

Thanks @mkaz for proofreading.

#5-9, #dev-notes

Editor Chat Agenda: 15 December 2021

Facilitator and notetaker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, December 15 2021, 03:00 PM GMT+1.

This meeting is held in the #core-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

  • GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 12.2 RC
  • What’s new in Gutenberg 12.1 ( 8 December)
  • WordPress 5.9
    • revised release schedule.
    • 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. 3 release 14 December.
    • “Must Haves” review – what’s left?
  • Updates based on updated scope for site editing projects:
    • Navigation 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..
    • Template editor.
    • Patterns.
    • Styling.
    • Mobile Team.
    • Components Team.
  • Task Coordination.
  • Open Floor.

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • If you have an update for the main site editing projects, please feel free to share as a comment or come prepared for the meeting itself.
  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

WordPress development environment

As a community, we need unified documentation on setting up a WordPress development environment. The current problem is that we have several different ways and locations documented, so depending on how a developer may start in WordPress may differ greatly from others.

The ideal scenario is one set of quality documentation that all the handbooks can point to help guide someone new to the project in setting up a development environment.

A few new wrinkles as this is not just a documentation issue.

There has been a fair amount of effort going towards making wp-env that standard. The benefit is wp-env allows for a small set of commands to get started. A developer doesn’t need to setup web servers, PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, or databases, it is all handled by containers. In this case, Docker.

Unfortunately with recent news, Docker Desktop is no longer free. The Docker engine itself is open-source and one of the main reasons it has grown in popularity. However, the Docker Desktop is not, and it is the primary (and easiest) way to install a Docker VM on Windows/Mac. Linux doesn’t require a VM to run Docker, can’t we all just switch to Linux? 😉

The services agreement for Docker Desktop:

4.2 Specific License Limitations – Docker Desktop.

(a) The Docker Desktop component of the Service at the level of the Personal Offering (as described on the Pricing Page) is further restricted to: (i) your “Personal Use”, (ii) your “Educational Use”, (iii) your use for a non-commercial open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project, and (iv) your use in a “Small Business Environment”.

(b) For purposes of this Section 4.2: (i) “Personal Use” is the use by an individual developer for personal use to develop free or paid applications, (ii) “Educational Use” is the use by members of an educational organization in a classroom learning environment for academic or research purposes or contribution to an open source project and (iii) a “Small Business Environment” is a commercial undertaking with fewer than 250 employees and less than US $10,000,000 (or equivalent local currency) in annual revenue.

The Section (a) restrictions above reads that Docker Desktop is allowed for personal and open-source use, but not if you work for a company with more than 250 employees or more than $10m revenue.

These restrictions are not in-line with the WordPress community and the open source ethos we want to promote. This makes it difficult to suggest Docker as the primary tool for setting up a development environment.

Which leads us to this post and discussion. What development environment should we recommend for new WordPress developers?

The main criteria I see for a tool are:

  • open-source
  • ease of use to setup and run
  • cross-platform (Windows, Mac, Linux)

If there is no good solution, do we consider creating our own? Or reviving a previous attempt at creating a simple development environment?

These are some initial thoughts to get the discussion started, what do y’all think?

Thanks to @cbringmann and @tellyworth for reviewing this post.

New Committers: 2021

2021 has sped by with two major releases and a final one underway. These releases have are made possible by many coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers who actively review and merge contributions (on top of other things). This year six new people were added to that list of committers, so please join me in welcoming and thanking them for their contributions.

First up is David Baumwald (@davidbaumwald). David served as Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Release LeadRelease Lead The community member ultimately responsible for the Release. for releases 5.3, 5.4, and 5.5 and has acted as a mentor throughout the 5.6 and 5.7 releases.  David has also served as a Component Maintainer for Comments.

Our next new 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. is William Patton (@williampatton). William, a self-proclaimed lover of all things sandwich, has been a diligent contributor since 2010 and has brought his expertise to the Theme Team, as well as to 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., WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/, and Plugins.

Jonny Harris (@spacedmonkey) has been an active member of the WordPress project since 2009! While Jonny is a professional WordPress developer, he gives back to the project by working in CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. and Core and now working as one of our new committers.

Next up is Jeff Ong (@jffng)! Jeff’s introduction to WordPress began in 2013 when he made a blogblog (versus network, site) to document his media art. Fast forward to today, Jeff contributes 40 hours a week to the Themes team. In addition to seeing him in his committer role, you’ll often see his name associated with default themes (looking at you twenty twenty-two).

If you have visited our 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/. #core channel, you will have seen our next committer, Jb Audras (@audrasjb). Jb is a current WordPress Core team representative, is one of the French General Translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. Editors since 2017, has acted as a Widgets and Menus components maintainer, and was an 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) team representative. He has also been a focus lead on WordPress releases 5.3 (accessibility), 5.4 (documentation coordinator), 5.5 (accessibility lead), 5.6 (Core auto-updates wrangler), and 5.7 (documentation lead).

Last but certainly not least is the inimitable Tonya Mork (@hellofromtonya). Tonya has been part of WordPress since 2015 and has since been triage lead for WordPress releases 5.6 and 5.7, a team representative for Test, and is now a Core committer!

Please join me in congratulating this excellent cohort of committers! 🎉💫

#committers

#commit

Performance team meeting summary – November, 30 2021

This is the agenda for the meeting. You can read the logs here on Slack.

Focus groups updates

Images

@adamsilverstein gave a great update on the progress of the focus. First, all issues and ideas related to focus will be tracked in this GitHub project. This will facilitate asynchronous contributions and discussions. The top priority issue on the project is this one, for creating a WebP module, and port the code to the repository.

On top of that, the focus meeting last Thursday was a success and the team is planning to hold a next one. Keep an eye on the Make/CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blogblog (versus network, site) and the #core-media channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to keep up with the agenda.

There were also several discussions about the main projects of the focus: WebP by default in WordPress Core and the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. of existing images into the WebP format. Here are the links to the discussion pieces on Slack:

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

Since most of the people in this focus are deeply involved in the next release, there are no major updates at the moment.

Measurement

For this focus, there were some discussions about starting a dedicated side conversation (see thread). Currently, the team is still thinking about the best form for this conversation, chat or video call. If you have any opinions, feel free to leave a comment in the thread linked above or on this post.

Performance features development coordination

There is currently this issue on 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/ repository regarding the code infrastructure of the performance modules. This step is very important to move forward, so feel free to leave a comment or feedback on the issue.

Open Floor

Jérôme Vieilledent (@lolautruche on Slack) mentioned before the meeting that Blackfire and Platform.sh are willing to support the WordPress Performance team initiative. Blackfire might be interested in donating an account to the 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/ organization for the team’s purposes. See Slack discussion here.

#meeting, #performance, #performance-chat, #summary

WordPress 5.9 Revised Release Schedule

A revised release schedule for WordPress 5.9 is available, with the final release planned for 25 January 2022.

Why the delay?

Near the end of the original alpha release cycle, issues arose that related to multiple major features planned for the 5.9 release, including:

  • Full Site Editing (FSE), which is a collection of features, such as global styles interface, Navigation 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., block themes, template editors, and site editing flows.
  • The Twenty Twenty-Two (TT2) theme, which depends on these FSE features.

The 6.0 release isn’t due until April 2022—too long for the community to wait for them. After processing this list of issues, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor team saw the features could ship in 5.9 with the revised schedule. 

This decision, to delay the 5.9 release, was not made lightly. The following section shares the decision-making process.

The decision-making process

Careful, thoughtful, open discussions happened in the release squad channel, that considered  options and impacts:

  • Move the specific pieces needing fixing to 6.0.
  • Move the fixes to a 5.9 minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality..
  • Move the fixes to 6.0.
  • Move these major features to 6.0.
  • Delay 5.9 to include fixes.

As the FSE features are very closely intertwined, removing some of its pieces would risk making the release unstable. To avoid delivering a sub-optimal experience, moving fixes to a 5.9 minor or 6.0 was ruled out.

It came down to a choice between:

  • Option 1: Remove these major features from 5.9 to target shipping in 6.0 in April 2022.
  • Option 2: Delay the release to ship the promised major features in 5.9 in January 2022.

After consulting with advisors from previous release squads and the Core Editor team, based on the current information available, the release squad determined shipping these major features sooner rather than later would have more benefits and less impact.

The release squad respects that the community has expectations and plans for these features. The extra time in the new schedule will help everyone involved deliver the 5.9 features the community has been waiting for.

Seasonal considerations

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. and RC release cycles have two jobs: to get the community involved in testing and delivering feedback, and to give contributors a block of time to fix identified issues before the final release.

The third 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. of the year was originally scheduled for the middle of December. Historically, fewer people are available the last two weeks of a year and the first week of a new year, because of various holidays, time off, and end-of-year and annual planning. This means there would be fewer people to test, give feedback, fix reported issues, and help package each release.

The revised schedule takes into account the realities of year-end and offers an optional Beta 4 if needed.

A schedule that delivers the full release 

5.9 is still in feature freeze. Work from here on is strictly to address the changes that get the release to a stable state.

The revised schedule also has a number of built-in safety measures:

  • More transparency. Constant communication between the release squad and Core Editor team throughout each week, so everyone involved knows the status of relevant items and can surface (and meet!) needs as early as possible.
  • 🔺blockers merged by Beta 1. An agreement that blockers (identified as🔺 in the list) must be ready by Beta 1 or risk getting moved to 6.0. (Update: these items were merged last week and are no longer blockers.)

How can you help?

Above all, please help test everything.

  • Get involved in the FSE Program testing calls including testing the site-editing experience. You can find a record of all the FSE Outreach exercises; feel free to go back and test any that interest you, but keep in mind that features have evolved.
  • Spin up a test site that uses Twenty Twenty-Two. If you find issues, please report them by opening a Trac ticket
  • Important: Try to break things to find things that may not work for your test sites. 
  • If you’re available, come to the Beta and 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). (RC) release parties, and bring friends! Test the packages when they drop. The parties take place in the Core channel of the Make 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/..
  • Come to the Slack meetings for Core and the Core Editor, and keep reading the posts on the Make.WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ blogblog (versus network, site).
  • Share feedback! The teams need to know everything that breaks, and everything that works really well, too.
    • For issues with 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/, create an issue on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/.
    • For issues anywhere else, start a ticket on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Props @marybaum, @annezazu, @costdev, @webcommsat, @cbringmann for collaborating and proofreading this post.

#5-9

WordPress JavaScript Standards Change Proposal

This post was authored by @opr18 (Thomas Roberts).

During a recent WordPress #core-js meeting there was a discussion about updating 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/. coding standard. The specific update that is being proposed is to change the rules relating to comments.

Currently, the standard reads:

Comments come before the code to which they refer, and should always be preceded by a blank line. Capitalize the first letter of the comment, and include a period at the end when writing full sentences. There must be a single space between the comment token (//) and the comment text.

The proposal is that the new wording should be:

Comments come before the code to which they refer, and should always be preceded by a blank line. Unless writing a linter override, or a `@see` type comment, capitalize the first letter of the comment, and include a period at the end. There must be a single space between the comment token (//) and the comment text.

The problem with the current guideline is that it is not enforceable by automated tools. It is hard for linting tools to easily distinguish between what is and isn’t a full sentence in the context of code comments.

Code reviews can quickly fill up with noisy comments and suggestions to capitalise or add periods to code comments. If this were fixable with a linting rule then these comments wouldn’t be necessary.

There are instances where it may not make sense to write in sentence case, for example: adding linter overrides or writing `see` comments where the comment may just be the name of a method or file, etc. so we would not enforce the rule on these types of comments.

If this guideline were to be amended, there would be several instances of code in 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 alone that do not follow it. It would be necessary to create a PR that fixes all of these issues. Because the change only relates to comments, a single PR can be made addressing all instances of comments that don’t follow the guideline, because the rule relates to comments only, this would have no impact on functionality so minimal testing would be required.

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. currently uses JSHint for linting JavaScript files, and it does not appear that even the existing style guideline is enforced. Even so, if efforts were made to move to ESLint in WordPress core, implementing a fix for any comments that do not follow the standard should be straightforward.

Initially the rule could be enforced as a “warning” while the PR to fix the issues is completed and after it has been merged the rule could graduate to an “error”.

Here is a draft PR demonstrating the punctuation aspect of the proposed change: https://github.com/WordPress/gutenberg/pull/34964

As a part of next steps, this post is looking for feedback on:

  • How do you feel about the proposed changes to the wording of the standard?
  • Are there any concerns about the plan for implementing this change?

This proposal is open for feedback until October 5th, 2021 at which point a final decision will be made during #core-js office hours that day.

#coding-style, #codingstandards, #proposal

Dev Chat Summary for November 24, 2021

@hellofromTonya led the weekly meeting at 20:00 UTC. Here is the meeting agenda.

Link to this <devchat> in #core on 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/..

Notable News and blogblog (versus network, site) posts

Team Reps

  • @marybaum will be a new Core Team Rep for 2022.
  • Thanks to @francina for serving in this role!
  • @audrasjb will continue in this role until another team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. is found.

Interested in being a Core Team Rep? Reach out to @audrasjb.

WordPress 5.9

  • @jeffpaul asked if there are any 5.9 blockers that are in specific need of help and asked what type of help they need (engineering, design, testing, etc).
  • @hellofromTonya posted an update on 5.9 blockers and scheduling. Design help is needed for Global styles & Design tools.
  • There is an open Call for Testing for Safari.
  • Everyone is invited to help wherever possible.
  • The release squad is keeping a daily close eye on progress, needs, and any blockers that might surface. Discussions and updates are centralized in the #5-9-release-leads channel on Slack.

Component Team Updates

Build/Test Tools

@sergeybiryukov gave an update:

  • Dependabot scanning is now configured for 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. This eliminates the need to manually check all GitHub Actions used within workflow files for updates. See ticketticket Created for both bug reports and feature development on the bug tracker. #54503 for more details.
  • NodeJS is pinned to the 14.x version in the .nvmrc file to ensure contributors are able to contribute without issue until compatibility with version 16.x can be confirmed in both trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. and 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 on GitHub. See ticket #54502 for more details.
  • Some PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher warnings from stdClass::__invoke() callback mocks were fixed in 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/. tests. See ticket #53844 for more details.
  • The timeout for GitHub Actions jobs was lowered so runaway or stalled processes don’t risk running for the default timeout duration of six hours. See ticket #53363 for more details.

@sergeybiryukov shared: No major news this week

Open Floor

  • @afragen asked for feedback on the Plugin Dependencies project for WordPress 6.0. Reach out to @peterwilsoncc if you wish to have editing access.
  • @jeffpaul asked how we are progressing on the Pre Beta 1 tasks and asked if there are any items that need help.
  • @hellofromTonya replied that there are some Dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. that need to be compiled and published.
  • @audrasjb has been marking tickets that need Dev notes.
  • @mkaz noted that documentation for WordPress 5.9 could use some help and posted a link to the requirements. Contributors are invited to reach out to @mkaz with any questions.
  • @jeffpaul is working on the WordPress 5.9 HelpHub page.
  • @abhanonstopnewsuk noted that the latest checks for the About and Help page were carried out on Monday November 22, 2021. The next check is on Monday November 29, 2021 at 20:30 UTC.
  • @audrasjb will be leading 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 on November 25, 2021 at 21:00 UTC. See the 5.9 Bug Scrub schedule.
  • With Thanksgiving taking place in the US on November 25, 2021, @hellofromTonya thanked the community for all contributions.

Props to @costdev for writing the devchat summary.

#5-9, #dev-chat, #summary

New Core Team Rep for 2022

After a call for volunteers, I’m pleased to announce that the new CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. for 2022 (and beyond) is Mary Baum (@marybaum)!

Mary Baum

Mary is the owner of RacquetPress. She is a self-taught developer, and she is a woman of many talents and hobbies: from online fabric, product design, 3D to landscape and macro photography. She is a self-proclaimed tennis bum.

Mary has been part of multiple release squads in different roles since 2019. She is also the maintainer of two components, Help/About and Quick/Bulk Edit.

Headshot of Mary Baum

I, @francina, am stepping down and @audrasjb will continue until another team representative is found. Do not hesitate to reach out to him or ask in #core if you have questions about the role.

I am excited to see Mary stepping into the role and helping Core with all the adminadmin (and super admin) tasks needed to keep the team moving.

#team-reps