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

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

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