What’s new in Gutenberg? (15th May)

More than 48 contributors participated in this Gutenberg release. It includes a number of valuable improvements.

The use of the new Block appender improves the usability of the Group and Columns blocks.

Group Block with the new block appender
Group Block with the new block appender

It’s now possible to set different widths for each column in the columns blocks. The use of a column resizer is planned for a future release.

Custom width support for the columns block
Custom width support for the columns block

The release also comprises important writing flow bug fixes that are going to be shipped as part of the WordPress 5.2.1 release.

5.7

Features

Enhancement

Bug Fixes

Documentation

Various

Mobile

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience, but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 5.7.0 7.8s 81.89ms
Gutenberg 5.6.0 9.1s 96.52ms
Gutenberg 5.3 (WordPress 5.2) 6.5s 73.55ms
Gutenberg 4.8 (WordPress 5.1) 14.6s 245.21ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Editor chat summary: May 8

This post summarizes the weekly Editor meeting on Wednesday, 8th May 2019, 13:00 UTC held in Slack.

The agenda followed can be found here.

Volunteers for Note-Taking Requested

As there are not very many folks who are taking notes for the chat at the moment, volunteers were requested. @nosolosw, @andraganescu, and @jorgefilipecosta offered to help out.

WordPress 5.2

WordPress 5.2 was released! Thanks to everyone who helped!

@youknowriad noted that he wasn’t sure why all of these things weren’t highlighted in the release post, but updates include:

  • No more TinyMCE in blocks
  • Block Management UI
  • Performance more than doubled in async mode
  • All widgets ported to blocks
  • A lot of improvements to existing blocks (cover block with inner blocks, focal point picker,…)
  • Stability improvements
  • Zero-config scripts to help authors create blocks

Accessibility Audit

The accessibility audit has been published. This is a great resource to improve the accessibility of the editor. Thank you to everyone that worked on it!

@andraganescu, @karmatosed, and @mapk attended the Accessibility chat to collaborate (recap was posted on the agenda post).

Design has done two triage sessions focused on the report (the next is on Friday, May 10, 2019 at 14:00 UTC), and development has already started in fixing some of the issues found.

The project board can be found here, and issues are also being grouped into labels (like [a11y] Keyboard & Focus). There’s interest in solving all validated issues that were found.

Several folks expressed interest in an a11y focused WordPress release, with the note that it would need to be a broader conversation with core + leadership.

@bemdesign mentioned, and others agreed, that while automation can help, a11y should ultimately be built into the process. Tenon, the company that ran the audit, provided documentation on how they tested.

Some recommended next steps included:

  • Aim for closing the project board by the end of May
  • Focus all triages until that can happen
  • Consider adding a column for deeper conversations / focuses and make issues for those
  • Dev-triage session focused on the board next week (Monday)
  • If you’re looking for an issue to tackle, take a look at this board first 🙂

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

Open Floor

@karmatosed asked if anyone would be interested in working with them on more detailed RC notes to be included in calls for testing.

@aduth raised a question about merge permissions.
“Is there a good sense of criteria for this to be granted? Or similar to core committer status, at discretion of leadership?”

Folks present seemed to be in consensus that this should be clarified, even if it’s only in terms of documenting general expectations.

Recommendations on criteria often included a number of contributions (committed PRs or other activities), ranging from 3-10 — with a note from @gziolo that Gatsby automatically adds access after one.

In closing, a quote from @andraganescu, “The thing with merge access is that as long as we have the triage/review/automated testing process the only thing you need is to prove some kind of good faith I guess”

Have thoughts on the above? Please leave a comment on this post!

The agenda for the next meeting, on 15 May 2019 at 13:00 UTC, is here; please add anything that you want to discuss.

#accessibility, #core-editor, #editor, #gutenberg, #meeting-notes

What’s new in Gutenberg? (1st May)

More than 31 contributors participated in this Gutenberg release. It comprises of a number of improvements, including to the button block focus states, theming, and block mover controls with full- and wide-aligned blocks.

Improved Button block focus state
Improved block breadcrumb placement with movers present

5.6

Enhancements

Bug Fixes

Various

Documentation

Mobile

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience, but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 5.6.0 6.7s 94.2ms
Gutenberg 5.5.0 6.6s 88.7ms
Gutenberg 4.8 (WordPress 5.1) 8.6s 154.1ms
Gutenberg 4.7 (WordPress 5.0) 11.2s 191.44ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Miscellaneous Developer Updates in 5.2

New wp_body_open Theme Hook

5.2 will introduce a new wp_body_open() function that is used to trigger a wp_body_open action. This action is intended to allow developers to inject code immediately following the opening <body> tag.

Themes are encouraged to begin using this hook as soon as 5.2 is released. The function should be placed just inside the opening <body> tag of the template file. For example:

<body <?php body_class(); ?>>
<?php wp_body_open(); ?>

Usage of this hook should be reserved for output of unseen elements like <script> tags or additional metadata. It should not be used to add arbitrary HTML content to a page that could break layouts or lead to unexpected situations.

Backward Compatibility

In order to support previous versions of WordPress, it is recommended you use a shim in your theme to prevent fatal errors from the undefined function.

<?php
if ( ! function_exists( 'wp_body_open' ) ) {
    function wp_body_open() {
        do_action( 'wp_body_open' );
    }
}

Note that if your theme is going to be submitted to the theme repository, then you won’t be able to use the wp_ prefix, as it will get flagged by the Theme Check. An alternative is to call do_action directly where the wp_body_open() function is placed in the first example, like this:

<body <?php body_class(); ?>>
<?php 
if ( function_exists( 'wp_body_open' ) ) {
    wp_body_open();
} else {
    do_action( 'wp_body_open' );
}

Plugins can detect the use of this function in a theme by calling did_action( 'wp_body_open' ) and falling back to alternative methods if the action has not fired.

See #12563 and #46679 for more information.

Login Header Adjustments

The <h1> on wp-login.php previously used the title attribute inconsistently between multisite and single site. In multisite, the value of this attribute was the title of the network, but on a single site, it merely duplicated the link text. As part of #24766, many of the title attributes throughout core have been removed, as they are often redundant or useless.

In WordPress 5.2, this title attribute has been removed and its associated filter, login_headertitle, has been deprecated. If the deprecated filter is used, it now applies to the link text. A new login_headertext filter has been added in its place.

In addition to the <h1> changes, the link on the WordPress logo now always points to WordPress.org by default. In prior versions, it would point to the primary site of the network on multisite. This URL can still be filtered using login_headerurl.

See: #42537

Editor Image Caption Styles

In the block editor, the font-size and color attributes were removed from the figcaption element unless the active theme has opted into default block styles.

Additionally, a margin: 0; attribute applied to .block-editor-rich-text__editable was removed from the RichText component, so as to allow theme styles to control those margins without high specificity. If your plugin relied on this margin, you’ll need to add this back to the necessary elements.

See: wordpress/gutenberg/pull/14366

Walker_Category HTML Attributes

A new category_list_link_attributes filter has been added to Walker_Category to allow customization of the HTML attributes applied to a category list item’s anchor element.

This complements the page_menu_link_attributes filter in Walker_Page and the nav_menu_link_attributes filter in Walker_Nav_Menu.

See #40666

New Additional Content Filter on User Delete Action

When users are deleted from a site, WordPress checks to confirm that they do not have posts or links assigned to them. However, there are cases where a plugin may have content associated with them outside of a post_author or link_owner relationship.

WordPress 5.2 introduces a new users_have_additional_content filter, which allows plugins to run additional checks for custom content relationships.

Note: This filter specifically doesn’t override the system users_have_content checks to avoid any undesired suppression of the reassign functionality. Instead it enables the ability to flag that a user has additional content.

Developers should note that this filter doesn’t conduct the reassignment operations on the data, this will be done by the delete_user or deleted_user actions which provide the ID of the user as well as the ID of the user for reassignment if selected.

Using the Filter

Below is a simple example of how a plugin could use the filter along with the delete_user action to allow the re-assignment of non-standard content.

First the filter returns true to signify that users have additional content. This triggers the content reassignment UI to appear in the admin for all users being deleted.

It then uses the delete_user action hook to reassign additional content at the same time as any standard core content.

function myplugin_users_have_additional_content( $has_content, $user_ids ) {
	if ( ! $has_content ) {
		// Check if any of the the users being deleted have additional content
		if ( myplugin_check_users_have_content( $user_ids ) ) {
			return true;
		}
	}
	return $has_content;
}
add_filter( ‘users_have_additional_content’, ‘myplugin_users_have_additional_content’, 10, 2 );

function myplugin_reassign_user_content( $deleted_user, $reassigned_user ) {
	if ( $reassigned_user ) {
		// Re-assign the content from the deleted user
		myplugin_reassign_coauthor( $deleted_user, $reassigned_user );
	}
}
add_action( ‘delete_user’, ‘myplugin_reassign_user_content’, 10, 2 );

See: #36860

Other Updates of Note:

  • As part of the 2019 focus of improving automatic updates, the sodium_compat library will now be included in WordPress. Sodium Compat is a polyfill for the Sodium cryptography library for PHP versions <7.2. Including this will facilitate security enhancements, with the initial focus of enabling more secure signing and verification of update packages. See: #45806
  • Twemoji is now updated to version 12.0.1. See: #46805
  • Fixed a bug where an Allow header was not being returned for OPTIONS requests to the REST API. See: #45753
  • A $domain parameter has been added to translate_user_role(). This will allow translations of custom user roles added in plugins. See: #38736

#5-2, #dev-notes, #editor, #themes

What’s new in Gutenberg? (17th April)

More than 48 contributors participated in this Gutenberg release. It marks the addition of the very expected Group block (sometimes referred to as container or section block). It’s a minimal version at the moment and improvements about the flows to add inner blocks, group/ungroup blocks are expected in follow-up releases.

The bug fixes from this release will be backported to WordPress Core in order to ship in the upcoming WordPress 5.2 release.

This release includes a lot of improvements to existing blocks and flows.

Enhanced Media & Text Block
Resizing blocks and images

5.5

Features

Enhancements

Bug Fixes

Documentation

Various

Mobile

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience, but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 5.5.0 6.4s 71.1ms
Gutenberg 5.4.0 6.5s 78.5ms
Gutenberg 4.8 (WordPress 5.1) 8.6s 154.1ms
Gutenberg 4.7 (WordPress 5.0) 11.2s 191.44ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

What’s new in Gutenberg? (3rd April)

Foundational work and initial UI explorations to implement the block-based widgets screen are on-going. In the meantime, the contributors worked on a number of bug fixes and improvements. All the bug-fixes will be included in the next beta of WordPress 5.2.

Vertical alignment support

5.4

Features

Enhancements

Bug Fixes

Documentation

Various

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience, but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 5.4.0 5.61s 74.88ms
Gutenberg 5.3.0 5.65s 73.37ms
Gutenberg 4.8 (WordPress 5.1) 8.21s 150.22ms
Gutenberg 4.7 (WordPress 5.0) 14.15s 201.27ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

What’s New in Gutenberg? (20th March)

This is the last Gutenberg release that will be entirely included in WordPress 5.2 and it’s an exciting one.

First, it introduces a block management modal with the ability to enable/disable blocks from the block inserter.

Block Management Modal

The release also includes the possibility to nest different kind of blocks in a Cover Block container.

Title, paragraph and buttons nested in a Cover Block.

The journey to improve different parts of the editor UI is continuing as well with improvements to the hover and selected block states with better a11y and less distraction.

Hover and selected block outlines

5.3 🇵🇹

Features

Enhancements

Bug Fixes

Documentation

Various

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience, but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 5.3.0 17.19 s 42.57 ms
Gutenberg 5.2.0 16.79 s
41.85 ms
Gutenberg 4.8 (WordPress 5.1) 23.43 s 82.75 ms
Gutenberg 4.7 (WordPress 5.0) 27.60 s 99.13 ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Editor chat summary: March 13th

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, March 13, 2019, 14:00 UTC.

Block Directory Proposal

  • @youknowriad shared the block directory proposal post and raised that the current block registration APIs do not allow for this kind of plugins, and therefore this would need to be be resolved before building the directory. It is proposed that a private API is created first for use only with core blocks to allow iterations.

Discussions are to continue on the above post and the relevant pull requests.

Code Owners Experimentation Feedback

A few weeks ago, a code owners flow has been introduced to the Gutenberg repository. This allows to  automatically ping people to review pull requests based on their interests on a certain area of the codebase.

A Discussion took place on the goal for this and whether it was achieved.

  • @aduth raised that one of the goals is to raise awareness and to get more core contributors.
  • @nosolosw felt that sometimes too many pings were sent out, and as a new contributor couldn’t commit the required time to review the codebase.
  • @youknowriad feels that the new workflow is not useful for occasional contributors.
  • @mcsf feels that the file paths do not map to the topics that people are interested in.

The new workflow will be kept for now, and reviewed at a later date.

Key Pull Requests

  • Block Management@aduth is actively working on this PR, some minor decisions still to be made, including wording.
  • Section Block – General consensus is that this should be shipped as an experimental block first. This is hoped to land soon, and will be iterated upon.
  • Block outlines UI – The PR is close to merge, it improves the Block outlines for the hover and selected state. @kjellr would like some feedback and testing on this PR.
  • React 16.8 Upgrade – React is going to be updated  on time for WordPress 5.2

Tasks Coordination

  • @aduth @mapk and the design team will be shipping the block management UI shortly
  • @get_dave and @danr are working on the section block (and related items) and will hopefully land a v1 shortly
  • @kjellr @joen @mapk and others are improving the hover and selected block outlines
  • @gziolo is working on the Block Registration API v2 and Axe tool integration
  • @youknowriad is working on the block editor module
  • @nerrad will resume working on the effects -> controls migration
  • @nosolosw and @gziolo are working on wp-scripts CLI improvements
  • @marekhrabe is working on improvements to the Media & Text resizer
  • @jorgefilipecosta is working on inserter improvements, e2e tests and the widget screen APIs

The meeting archive is here.

The agenda for the next meeting is here, please add anything you want to discuss.

#meeting-notes, #core-editor, #editor, #gutenberg

#agenda, #editor, #gutenberg

What’s New in Gutenberg? (6th March)

As we dive into the block-based widgets screen, foundational work is required to support using the Gutenberg editor outside the Post Editor context. This release falls into this category of releases where it’s more about building the foundations and making the Gutenberg modules more flexible to support these new use-cases.

It introduces a new @wordpress/block-editor module allowing building block editors outside the post editor context and even outside the WordPress Admin context. This has some costs on the performance of the keypress events while working on very long posts that we hope to alleviate in the upcoming releases.


5.2

Enhancements

Bug Fixes

Documentation

Various

Chore

Mobile

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience, but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 5.2.0 11.7 seconds 57.8 ms
Gutenberg 5.1.0 11.4 seconds 22.25 ms
Gutenberg 4.8 (WordPress 5.1) 15.1 seconds 126 ms
Gutenberg 4.7 (WordPress 5.0) 16 seconds 185.2 ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Editor chat summary: February 20th

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, February 20, 2019, 14:00 UTC.

Gutenberg Release 5.1

Gutenberg 5.1 has been released which marks the end of the widget to blocks project. There are a range of essential enhancements which have been made in this release; details can be found on the release post.

WordPress 5.2 Planning

Based on the proposed schedule and scope for 5.2, a proposal to synchronize the Gutenberg plugin release dates with the WordPress feature-freeze date have been shared. Some concerns were raised about the short timeframes. This will be adapted to the final WordPress 5.2 release schedule.

The WordPress 5.2 scope has been discussed including the need for block discovery and management solutions as many users are feeling overwhelmed with the available choices.

Concerns about the short time frame to achieve these goals for 5.2 were shared and it was suggested that being able to turn blocks on/off. Favourite blocks could form part of 5.2. The wp.org directory could be independent of this roadmap.

Updating wordpress.org/gutenberg

The role and the necessary updates for this page were discussed:

  • The copy of the content needs to be refreshed.
  • Consistency with the marketing terminology is important.
  • Whether the page should be a feature page, or more related to the project roadmap.

@joostdevalk shared a call for ideas and thoughts over the next couple of days.

Tasks Coordination

For the next week, this is what everyone is working on:

  • @gziolo is starting to implement the new Block Registration API.
  • @mkaz is continuing on the documentation effort (i18n and JavaScript setup).
  • @youknowriad is starting to plan the block management and the widget screen work.
  • @youknowriad and @aduth will work on landing the generic block editor module.
  • @nosolosw is going to continue on the React deprecated APIs and JS documentation auto-generation.
  • @getdave and @marekhrabe are working on vertical alignment for the columns and media+text blocks.
  • @talldanwp and @andrei are working on the section block.
  • @jorgefilipecosta is working on improvements for the Calendar block, MediaPlaceholder and block insertion restrictions.

Open Floor

The meeting archive is here.

The agenda for the next meeting is here, please add anything you want to discuss.

#meeting-notes, #core-editor, #editor, #gutenberg

#agenda, #editor, #gutenberg