What’s new in Gutenberg? (10 July)

A few weeks ago, Matías shared a post about using motion to express change in reactive UIs. This release is a first step in implementing those ideas. It introduces motion to block changes, creation, removal, reordering.

In addition to a number of other improvements and bug fixes, the contributors also worked on typing performance. As of this release, typing is 30% faster on long posts.

6.1

Enhancements

Experiments

Bug Fixes

Performance

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 6.1.0 5.2s 56.89ms
Gutenberg 6.0.0 5.4s 80.2ms
Gutenberg 5.3 (WordPress 5.2) 4.9s 66ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Editor chat summary: 26 June 2019

This post summarizes the weekly editor chat meeting on Wednesday, 26th June 2019, 13:00 UTC held in Slack.

The agenda followed can be found here.

Gutenberg 6.0

Gutenberg 6.0 was released and includes various fixes and improvements including a way to pick a pre-defined layout in Columns block.

WordCamp Europe

Props

Folks discussed the difficulty in attribution of work in props due to a manual process being used to collect it. This has caused some contributors be missed in the last few releases.

@youknowriad requested help from someone to research GitHub/WordPress.org username matching.

Folks seemed to agree that the most immediate step would be to list props in the merge commit, which would be similar to the way Core handles them.

There was also discussion about what constitutes a contribution, with discussion leaning towards the core description.

Many favor automating the process as much as possible, with some concerned that this would include folks that commented in unhelpful ways.

@desrosj agreed to create a post on the subject, summarizing and listing actionable items and proposals. He also requested feedback from those not aware of the topic of conversation or who were not able to attend WCEU.

Themes, Content Areas, and Editing more than post_content.

There was discussion on how themes could best register content areas, and how the editor should best expand to edit content outside of post_content.

@youknowriad created three issues to hold the discussion, with more likely to come:

  • https://github.com/WordPress/gutenberg/issues/16281
  • https://github.com/WordPress/gutenberg/issues/16282
  • https://github.com/WordPress/gutenberg/issues/16283

@matias recommended a focused chat with the themes group, and many folks agreed.

Task Coordination

Open Floor

Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!

The next meeting is scheduled for July 3, 2019 at 13:00 UTC. The agenda is here; please add anything you’d like to discuss!

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

What’s new in Gutenberg? (26th June)

Last week saw WordCamp Europe bring many contributors to Berlin, an event which brings us together across focuses and even languages. Still, we’re back to business as usual and Gutenberg 6.0 is a release packed with bug fixes and improvements.

The Widgets screen is being polished, the Group block is being improved and Accessibility remains an important focus.

This release also features a layout picker for the Columns block, allowing the user to choose from pre-defined layouts or to start from scratch.

6.0

Features

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 6.0.0 5.1s 80.39ms
Gutenberg 5.9.0 4.8s 69ms
Gutenberg 5.3 (WordPress 5.2) 7.1s 77ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

What’s new in Gutenberg? (12th June)

More than 40 contributors participated in this Gutenberg release. 6 of them submitted their first PR to the repository.

Some very important improvements to the Block Editor UI landed in this release. A new type of notices called Snackbars has been introduced.

A Snackbar displays a succinct message that is cleared out after a small delay. It can also offer the user options, like viewing a published post but these options should also be available elsewhere in the UI.

For a distraction-free experience, all the notices used in the editor to inform about the post saving/publishing, reusable blocks creation and updates have been updated to use this new type of notices.

Snackbar Notices

This release also adds the grouping/ungrouping feature that makes it easy to select a number of blocks and group them inside a container block.

An important usability change has been made to how nested blocks are selected. Now you click through each layer to reach the deepest nesting level, making it easy to configure each block along the way.

From a developer perspective, this version introduces useDispatch and useSelect APIs to the data module. If you’re building custom plugins relying on the data module, make sure to check out the dedicated post.

5.9

Features

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.9.0 4.9s 66.3ms
Gutenberg 5.8.0 4.8s 62.8ms
Gutenberg 5.3 (WordPress 5.2) 5s 58.4ms
Gutenberg 4.8 (WordPress 5.1) 7.6s 147.9ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Rich Text Chat

Last Wednesday, we had a chat about rich text and writing in Gutenberg. We went through some questions and looked at what’s next. We also decided it’s worth having another chat. Let’s do one Wednesday, 19 June 2019, at 16:00 UTC, unless someone else would like to hold the meeting next week as I’m not around.

Agenda

  • Any urgent issues?
  • Ensure the roadmap is clear and up-to-date.
  • Questions.

Please comment if you’d like to see something discussed and I’ll add it to the agenda.

#editor, #rich-text

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

More than 42 contributors participated in this Gutenberg release. It includes a number of valuable improvements and two important bug fixes that are going to be backported into the next WordPress 5.2.2 release.

The work to improve the built-in block library is still ongoing. Heading blocks support custom text colors and we plan to expand this to other textual blocks in the future.

Gallery images can now be reordered inline without opening the media modal. Drag and drop support is being explored.

This release includes a working proof-of-concept of the block-based widgets screen. You’ll be able to edit/update your widgets areas using any available block. This will allow us to polish the UI and clear out bugs in the next releases.

5.8

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.8.0 5.4s 64.9ms
Gutenberg 5.7.0 5.6s 65.8ms
Gutenberg 5.3 (WordPress 5.2) 6.1s 64.2ms
Gutenberg 4.8 (WordPress 5.1) 7.7s 150.6ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

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.

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