Editor chat summary: 7 August 2019

This post summarizes for the weekly editor chat meeting on Wednesday, August 7, 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Task Coordination

Open Floor

@karmatosed and @chrisvanpatten brought up the need for leadership in user focused documentation for Gutenberg.

Graphics requested for Gutenberg documentation can be found on the Design team’s board.

@paaljoachim offered to reach out to the docs team for assistance in moving forward. If you’re interested in helping with user-focused docs for Gutenberg, please reach out in the comments here or in the #core-editor channel!

@kadamwhite mentioned that the REST API team is working on catching up with requests for feedback on tickets and invited folks to the the #core-restapi channel to connect.


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

The agenda for the next meeting, 14 August 2019 13:00 UTC is here, please add anything you want to discuss.

#editor, #gutenberg, #meeting-notes

What’s new in Gutenberg? (31 July)

The number of Gutenberg contributors is growing significantly and it’s a pleasure to see how people from all around the world come together to build and improve the software. I’d like to take this opportunity to thank the 48 contributors that participated in this release.

Among the improvements of Gutenberg 6.2, a feature that might seem small but which a lot of people were waiting for: the possibility to customize the target of the Button block (open the link in a new tab).

We also had a lot of people asking for the possibility to use all kinds of block types in the Cover and Media & Text blocks, so we’ve removed their nested block restrictions.

From a Developer Experience perspective, this release introduces a new PHP API to simplify the registration of block styles variations.

// Registering a style variation using a registered WP style.
register_block_style(
	'core/quote',
	array(
		'name'         => 'fancy-quote',
		'label'        => 'Fancy Quote',
		'style_handle' => 'myguten-style',
	)
);

// Registering a style variation using an inline style.
register_block_style(
	'core/quote',
	array(
		'name'         => 'not-fancy-quote',
		'label'        => 'Not Fancy Quote',
		'inline_style' => '.wp-block-quote.is-style-not-fancy-quote { color: blue; }',
	)
);

6.2

Enhancements

New APIs

Bug Fixes

Documentation

Divers

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.2.0 4.8s 67.2ms
Gutenberg 6.1.0 5.9s 67.2ms
Gutenberg 5.3 (WordPress 5.2) 7.6s 80.13ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Dev chat summary: July 17

@earnjam led the meeting. @marybaum took notes and is writing this summary.

Announcements

Gutenberg 6.1

@earnjam announced the release of Gutenberg 6.1 last week. New features include animations/motion to block reordering, improved messaging for REST API errors and more.

Check out the release post for more details: https://make.wordpress.org/core/2019/07/10/whats-new-in-gutenberg-10-july/

Look for version 6.2 RC to land next week.

PHP Coding Standards

@pento posted a followup to some proposed coding standards changes from a few months back.
See the decisions on these changes here (they might surprise you!): https://make.wordpress.org/core/2019/07/12/php-coding-standards-changes/

And keep in mind these affect only the code for WordPress Core. In your own Themes and Plugins, use the coding conventions that make sense for you.

Releases

5.2.3

With four tickets in the queue and none of them affecting functionality, it’s still not clear that they warrant a separate 5.2.3 release. Scheduling for that is still pending further info on a roadmap for 5.3, which should land in early fall.

5.3

As yet the Core team is progressing on current open tickets — there are 57 in the queue — while @chanthaboune continues gathering data from component maintainers on feature priorities for 5.3.

Component maintainer updates

Core-media

@azaozz asked for more eyes on #40439.

If you can help test, please check out the ticket or head to #core-media.

Site-health

@clorith pointed to the call for input for bumping the PHP recommendation and said that soon a Make blogpost will outline next steps—and next versions.

For now, the site-health team isn’t looking to raise the hard minimum. This will be a soft bump up to nudge users toward the minimums that will follow.

Open Floor

Triage Team

@joyously asked about progress from the Triage Team, and the responses came from several quarters.

@desrosj posted a link to his three-month summary: https://jonathandesrosiers.com/2019/06/wordpress-triage-team-3-month-reflection/ and plans to post more often on https://make.wordpress.org/updates.

@karmatosed mentioned that Design holds two triages a week, and that from where she sits, triage seems to be going gangbusters and spreading across the WordPress Project.

@azaozz pointed the group to his efforts on TinyMCE: https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&component=TinyMCE&order=priority

@marybaum mentioned having been in an accessibility triage last Friday.

Gutenberg Phase 2

Newcomer @Lu asked about the timing of Gutenberg Phase 2, with a particular interest in widget blocks. @earnjam answered with a summary of the release discussion earlier in the chat.

Strings

@marybaum asked the group for their thoughts on a more systematic, global approach to the copy in strings.

For now, the group agreed to have #meta add two keywords to tickets—needs-copy-review and has-copy-review.

Props to @garrett-eclipse, who opened meta#4609 and its counterpart meta#4610 on the spot.

Right at the close of the official chat, @audrasjb linked to https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance

#dev-chat, #gutenberg, #releases, #strings, #triage-team

#summary

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

Introducing useDispatch and useSelect

Coming soon via the pending Gutenberg 5.9 plugin release (and the subsequent @wordpress/data package release) are two new apis to use in implementations interacting with the wp.data api. useSelect and useDispatch are custom React hooks that enable a more declarative interface to registered stores in the registry. In this post I’m going to try to give some highlights of these new apis.

What happens to withSelect and withDispatch?

The short answer is, “nothing”! withSelect and withDispatch are still usable and are not being deprecated. In fact, under the hood they have both been refactored to use hooks also.

There’s no pressing need to retire these interfaces so you can reliably keep on using them!

Why?

React hooks are becoming an important api in the react ecosystem and this article written by Dan Abramov is a good introduction to them including some of the rationale for why the api was created. For the use case in Gutenberg, the same reasons for hooks in general contribute to why they are being implemented here. Namely:

It’s hard to reuse stateful logic between components

As higher order components, withSelect and withDispatch do a great job at enhancing components to connect with the wp.data registry. However, they contribute to the “wrapper hell” commonly experienced in large react apps where stateful logic is shared between components.

Hooks provide a better primitive for interacting with stateful logic and useSelect and useDispatch in turn provide declarative interfaces for interacting with the store state without changing component hierarchy.

Complex components become hard to understand

While much of the complexity of interacting with store state is reduced in the usage of withSelect and withDispatch. The new hooks take this a few steps further:

  • The api is simplified.
  • The declarative behaviour is more straightforward to follow in the context of their implementation. Instead of having multiple withSelect or withDispatch calls, you can now embed useDispatch and useSelect within the components using them (or, preferably, create a custom hook implementing the multiple useSelect and useDispatch hooks and exposing only the props needed by the component).

Classes confuse both people and machines

While this applies more to hook usage in general, it does allow for not worrying as much about lifecycle methods and for implementing directly in functional components. Note, withSelect and withDispatch could also wrap functional components, but the exposure of hooks allows for integrating with the usage of other React hooks.

How?

There will be documentation updated in @wordpress/data docs eventually, but for now, you can see the api and examples directly in the repository.

I’ve also written an overview/introduction to the hooks that gives some insight into usage.

#wordpress-data, #gutenberg, #javascript, #usedispatch, #useselect

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

The Block Registration API – status update

Build a WordPress.org directory for discovering blocks, and a way to seamlessly install them is one of the 9 priorities in the 2019 roadmap. This post tries to summarize work done so far and identify all the next steps required to land this project in WordPress core later this year.

It has been over two months since the Meta team published a post intended as a starting point for discussion and new ideas for the Block Directory, and a new type of plugin:

Put briefly, I’d like to propose a new type of WordPress plugin that provides blocks and nothing else: Single Block Plugins. These will be hosted in a separate Block Directory section of the Plugin Directory. They will be JavaScript-based, and each plugin will register a single Block. And they will be searchable and installable from within the Gutenberg editor itself.

@tellyworth

Currently, new Gutenberg blocks can be provided by plugins, which often register many blocks, and which are managed from outside the editor. The proposal mentioned above outlines a new type of simple block-based plugin that is intended to be seamlessly installed from within Gutenberg itself. It was later followed up with the call for design on installing blocks from within Gutenberg. There was an essential technical aspect highlighted in the post:

The WordPress.org API will provide an endpoint for searching for blocks by name and description, and return metadata similar to that of plugins. Gutenberg’s Inserter could use that endpoint to also show relevant block plugins that are available to install, with a button and process for seamless installation.

@tellyworth

This new endpoint is going to be based on the Block Registration API RFC which intends to address the server-side awareness of blocks and simplify the block discovery for the block directory project. In practical terms, it means that we are seeking for a solution where block type registration is declarative and context-agnostic. Any runtime (PHP, JS, Android, iOS or other) should be able to interpret the basics of a block type and should be able to fetch or retrieve the definitions of the context-specific implementation details.

Core Editor team reached the point where we believe that the Request for Comments is close to being finalized. However, there are still some areas where we feel that other WordPress teams could have a significant impact on the proposal.

Internationalization

The way how translations are handled inside JSON files is something novel for WordPress core. The current proposal for PHP follows the existing get_plugin_data core function which parses the plugin contents to retrieve the plugin’s metadata, and it selectively applies translations dynamically. It would be also similar for JavaScript, with the remark that we plan to implement a custom Babel plugin which would mirror PHP behavior for ESNext code. The transformation would happen during the build step to ensure that files can be statically analyzed before scripts are enqueued. You can find more details in RFC document in the Internationalization section. There is also an issue#15169 opened which describes the technical details of the proposed JavaScript implementation of the Babel plugin.

Core JS team discussed this topic at the end of the weekly meeting on Apr 2nd. We have received great feedback from @swissspidy which helped to shape the proposal. However, we still encourage other Polyglots team members to voice their opinions.

New REST API endpoints

The long term vision for the block discovery in WordPress includes:

  • Fetching the available block types through REST APIs.
  • Fetching block objects from posts through REST APIs.

The proposed implementation for the server-side awareness of block types should ensure that it stays intact with all recommendations that REST API team might have. That’s why we encourage the REST API team to get involved in the process early on. There is no immediate need to start working on new block type related API endpoints. However, it would be great to have it included on the roadmap. Ideally, they should stay as close as possible to the WordPress.org API and the final shape of the endpoint for searching for blocks.

#block-directory, #core-editor, #gutenberg, #i18n, #meta, #rest-api