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

The Block Registration RFC and the Gutenberg RFC process

While Slack is a critical tool for keeping in sync for project status and priorities, it has proven to be an ineffective platform to engage in detailed, long-lived discourse around complex engineering problems.

Inspired by other open source projects like React, Yarn, Rust… we started experimenting with a new RFC (Request For Comments) process in the Gutenberg repository in order to propose, discuss and adopt technical solutions for these big features or complex technical challenges.

The Block registration RFC

The first open RFC in the Gutenberg repository concerns the Block Registration API and intends to address the server-side awareness of blocks and simplify the block discovery for the block directory project.

The block registration API is the most important API in the block editor with a lot of technical challenges. Its implementation should fulfill a number of requirements:

  • A block type registration should be declarative and context-agnostic. Any runtime (PHP, JS, or other) should be able to interpret the basics of a block type (see “Block API” in the sections below) and should be able to fetch or retrieve the definitions of the context-specific implementation details. The following things should be made possible:
    • Fetching the available block types through REST APIs.
    • Fetching block objects from posts through REST APIs.
    • This API should be backward compatible with what we have at the moment.
    • It should be possible to statically analyze a block type in order to support advanced use-cases like the block discovery required by the Block Directory project.
  • It should not require a build tool compilation step (e.g. Babel, Webpack) to author code which would be referenced in a block type definition.
  • It should allow to dynamically load (“lazy-load”) block types, or parts of block type definitions. In practical terms, it means that the editor should be able to be loaded without enqueuing all the assets (scripts and styles) of all block types. What it needs is the basic metadata (title, description, category, icon, etc…) to start with. It should be fine to defer loading all other code (edit, save, transforms, and other JavaScript implementations) until it is explicitly used (inserted into the post content).

This RFC has already received a lot of feedback and technical explorations already started to clarify feasibility already started but I’d like to encourage everyone to chime-in and share thoughts.

What type of features/problems should be submitted as RFCs

All ideas/PRs/proposals require discussions before moving to implementation. When the proposed changes are small then a GitHub issue is fine but in addition to the block registration API, all the features and technical problems with impact across different areas of the code base, new patterns for extensibility APIs, technical problems that are hard to solve without making compromises are good candidates for RFCs.

Some examples for the Gutenberg project include:

  • The Block Registration API.
  • The Block Invalidation and Deprecation handling.
  • Block areas storage mechanism and widgets migration.
  • Block Bahaviour reuse (colors, alignments…).
  • Responsive Image Handling and Block Alignment awareness in nested contexts.
  • Editor Styles.

The RFC workflow

The flow to propose a new RFC is the following:

  • Create a RFC document for your proposal.
  • Submit a pull request to the Gutenberg repository (markdown file added to the `docs/rfc` folder).
  • Discuss and incorporate feedback into the PR
  • After discussions in the weekly meetings, RFCs may or may not be accepted.
  • If the RFC is accepted, the PR is merged.

Accepted RFCs means the proposed feature is approved for implementation. Once implemented, the RFC becomes the de-facto documentation for it.

What makes a good RFC document

A good RFC document can be broken into the following sections:

  • Description of the problems solved by the RFC
  • Current status and previous attempts
  • Solution Proposal
  • Unsolved Problems

Who can submit an RFC

Anyone can submit an RFC.

We’re looking forward to start receiving RFC proposals!

#core-editor, #gutenberg, #meta

Building JavaScript

The Gutenberg Handbook shows JavaScript examples in two syntaxes: ES5 and ESNext. These are version names for the JavaScript language standard definitions. You may also see elsewhere the names ES6, or ECMAScript 2015 mentioned. See the ECMAScript Wikipedia article for all the details.

ES5 code is compatible with WordPress’s minimum target for browser support. It can run straight in your browser and does not require an additional build step. In many cases, it will be perfectly fine to follow the same approach to start experimenting with your plugin or theme quickly. As soon as your codebase grows to hundreds of lines, it might be a good idea to take advantage of all the great JavaScript features included in ESNext syntax.

With the release of Gutenberg 5.3, the @wordpress/scripts package was updated to include webpack and Babel configurations. The update makes setting up an ESNext development environment much easier for building blocks and creates a standard method for developers to set up their plugin.

The documentation in the JavaScript tutorial and the ESNext examples in the gutenberg-examples repository are both updated to include the new process.

Here is a quick overview of how to set up an environment. First, you need to install @wordpress/scripts package:

npm install --save-dev @wordpress/scripts

You can then update the scripts section of your package.json to include:

"scripts": {
    "start": "wp-scripts start",
    "build": "wp-scripts build"
}

No webpack config (e.g., webpack.config.js) or Babel config (e.g., .babelrc) is needed.

The scripts expect the source file to be found at src/index.js and will output the build to build/index.js. So if you are migrating an existing plugin, you will need to move your source and enqueueing to these new locations.

With the setup in place, the standard workflow is:

  • Install dependencies: npm install
  • Start development builds: npm start
  • Develop. Test. Repeat.
  • Create production build: npm run build

In general, the package should be used with the set of recommended config files. While it is possible to override every single config file provided, if you have to, it means that your use case is more complicated than anticipated. We’d love hearing about it as we’d like to iterate on the current setup and offer more flexibility in the future. At the moment, our recommendation would be to use the underlying tools (webpack, Babel) directly.

See the JavaScript Build Setup documentation for a full explanation and walk through, and see the scripts package documentation for all the details.

Props to @gziolo and @nosolosw for their efforts.

#core-editor, #core-js, #javascript

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

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

More than 51 contributors participated in this release. It marks an important milestone for Phase 2, as it’s the end of the porting widgets to blocks project. Next releases will be focused on explorations around the Widgets screen.

Widgets 2 Blocks

This release also includes a big refactoring to the formatting buttons and the RichText component, allowing us to fix a significant number of issues and to improve the writing flow.

Core blocks (aside from the Classic block) are not using TinyMCE under the hood anymore. This change should not have any perceivable impact, as the APIs of the RichText component and the custom formats registration have not changed.

In addition, contributors have worked on a number of improvements to existing blocks and UI micro-animations.

Enhanced Menus

Click to activate embed blocks

5.1

Features

Enhancements

Bug Fixes

Various

Chore

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.1.0 9.4 seconds 16.4ms
Gutenberg 5.0.0 10.4 seconds 16.4ms
Gutenberg 4.8 (WordPress 5.1) 13.6 seconds 158.2ms
Gutenberg 4.7 (WordPress 5.0) 15.1 seconds 203.5ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

JavaScript chat summary, February 19th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: NPM Mono-Repo Subdirectory Declaration

https://github.com/npm/rfcs/blob/latest/implemented/0010-monorepo-subdirectory-declaration.md

@adamsilverstein quoted @aduth‘s note that we should consider implementing the npm monorepo declaration in the WordPress npm packages.

@aduth added that implementing this declaration would be a straightforward task that would help make npm more “aware” of where to find the specific source for a package in a mono-repository, hopefully improving links.

The idea was well received.

@aduth has created issues related to this task:

Feel free to share your thoughts and provide feedback related to this subject in the issues.

Agenda: Feature Flags

https://github.com/WordPress/gutenberg/pull/13324

Feature flags were merged in the Gutenberg repository. Quoting @gziolo:

feature flags in Gutenberg, it’s very simple approach which will allow us to enable new features only for the plugin while keep it completely removed from WordPress core using dead code elimination.

We went into more detail of what feature flags are and what they allow.

@atimmer noted that most commonly feature flags allow to enable or disable specific features while Gutenberg feature flags apply to a whole set of features e.g.: “phase 2 features”.

@aduth referred that the reason behind this decision may be related at least partly to the objective of simplifying dead code removal.
More information can be found at https://github.com/WordPress/gutenberg/pull/13324.

@adamsilverstein shared that he wants to introduce a feature in the hooks package whose code should only be included when the SCRIPT_DEBUG flag is set. Any feedback to this is welcome and can be provided in https://github.com/WordPress/gutenberg/pull/12038.

During the discussions, it was referred that, although dead code removal is a common and used by famous libraries like React, there are no good resource/references available online to help developers understand how dead code removal works.
If you know any good resource feel free to share the link in the comments or the core-js channel.

Agenda: Build support for wordpress/scripts

Relevant PR’s:

According to @gziolo both PR’s are almost ready, but they need additional testing given the complexity of running the scripts with default configuration in various external projects.

@adamsilverstein noted that webpack setup is a significant barrier to entry for new developers and the more we can improve our tools the better.

@gziolo referred that a tutorial was already created and it will be simplified after latest changes are published.

Open floor

@nerrad referred that he would like to use the new version of React, more specifically React hooks, and asked when a React upgrade should be considered and when a WordPress release will contain the next version of React.

Answering to @nerrad, @aduth noted that upgrading React should be a non-issue although we may need some scrutiny on what is exposed. Regarding the WordPress releases, @aduth expects that anything merged to Gutenberg repository between now and mid-March should be part of the WordPress 5.2 release, but this specific subject will be clarified during the next #core-editor meeting https://make.wordpress.org/core/2019/02/19/editor-chat-agenda-february-20th/.

@nosolosw announced that in the past days the first auto-generated API documentation was merged to the Gutenberg repository: https://github.com/WordPress/gutenberg/pull/13856.
The tool that autogenerated the documentation is proposed in https://github.com/WordPress/gutenberg/pull/13329.
The next package/component that will be used as a testbed for the tool is not yet decided and every suggestion is welcome.

#core-js, #javascript, #meeting-notes