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

Block Editor Detection Improvements in 5.2

In 5.0, WP_Screen::is_block_editor() was introduced to allow developers to conditionally execute code depending on whether the block editor is being loaded. This method returns the is_block_editor property of the WP_Screen instance. However, there were some large gaps in the loading process where an incorrect value could potentially be returned.

For example, when using the current_screen action hook, the value was always false, even when the user was visiting a block editor enabled screen. This happened because block editor support is flagged much later in the loading process when edit-form-blocks.php is included.

function myplugin_current_screen( $screen ) {
	if ( $screen->is_block_editor ) {
		// This conditional would never execute.
	}
}
add_action( 'current_screen', 'myplugin_current_screen' );

This has been fixed in 5.2 to account for all possible scenarios when a post is edited. However, there are still a few very narrow edge cases when a new post is created where WP_Screen::is_block_editor() may still incorrectly indicate block editor support.

Edge Cases When Creating New Posts

The use_block_editor_for_post() function and replace_editor filter require a WP_Post object to be passed as a parameter. Because a new post has not yet been created when WP_Screen is instantiated, it can only make its best guess whether the page is loading the block editor.

When creating a new post, WP_Screen will set is_block_editor property to the value returned by use_block_editor_for_post_type() for the current post type. In most cases, this guess will be correct. But, the following scenarios have edge cases to consider.

  • When the replace_editor filter is used to replace the editor, this value may be incorrect.
  • When the use_block_editor_for_post filter is used to change block editor support.

For both of these scenarios, the use_block_editor_for_post_type filter can be used to ensure the correct value in most circumstances.

function myplugin_replace_editor_filter( $replace_editor, $post ) {
	// Logic to replace editor.
}
add_filter( 'replace_editor', 'myplugin_replace_editor_filter', 10, 2 );

function myplugin_replace_editor_post_type( $use_block_editor, $post_type ) {
	// Similar logic to replace editor, but without a WP_Post object to work with.
}
add_filter( 'use_block_editor_for_post_type', 'myplugin_replace_editor_post_type', 10, 2 );

With this filter, all scenarios that do not require checking a specific property of a post (a taxonomy term, meta value, etc.) can be accounted for. For example, filtering based on user capability, site option, or user meta value for editor preference are all possible using use_block_editor_for_post_type.

When WordPress creates a new post, it uses the get_default_post_to_edit() function. This function creates a new post in the database using wp_insert_post() and then allows the default content, title, and excerpt to be filtered. When terms, post meta, or content are added to posts with actions such as save_post or wp_insert_post, it is possible that this could change the block editor support for the post being created.

This scenario would result in WP_Screen:is_block_editor possessing an incorrect value from the current_screen action until roughly the load-{$pagenow} action.

Logic should be added to the use_block_editor_for_post_type filter to account for these scenarios (which are normally post type specific) and guarantee the accuracy of WP_Screen::is_block_editor().

For more information on this, consult the ticket on Trac (#46195), or the changeset ([45224]).

#5-2, #block-editor, #dev-notes, #gutenberg

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

The Block Editor JavaScript module in 5.2

One of the goals of the Gutenberg project’s phase 2 is to expand the usage of the Block Editor to other WordPress admin pages like the widgets screen.

In order to achieve this goal, it’s important to be able to reuse the block editor in a context independent from the post editor without any dependency to the post object. That’s where the new block-editor module comes in.

Reorganization

In WordPress 5.1 and earlier, the block editor relied on the editor JavaScript module in order to fetch the post being edited and render the block editor corresponding to this post. This module is available as a registered WordPress script using the wp-editor script and style handles and under the wp.editor global variable.

WordPress 5.2 extracts some parts of the editor module into a new module called block-editor. This module is now available as a registered WordPress script using the wp-block-editor script and style handles and under the wp.blockEditor global variable.

Important distinctions about the new block-editor module:

  • The editor module is kept, but is only responsible for fetching/updating post objects, and rendering post specific UI components.
  • The block editor module is a generic module responsible for rendering block editor UI, updating the list of blocks, and providing reusable components for third-party blocks.

Backward Compatibility

There’s no backward compatibility breakage involved in this reorganization, as usage of the editor module provides proxies for APIs that were moved to the block-editor module in WordPress 5.2.

For example, in WordPress 5.1, blocks had to use the wp.editor.BlockAlignment component to support alignment. This component will continue to work as expected, but wp.editor.BlockAlignmentToolbar is now just a proxy to the block editor component wp.blockEditor.BlockAlignmentToolbar.

However, relying on the editor module as a dependency means that your block/code is loading the full editor module, which might not be needed for the block editor that will be included in the widgets screen in the future.

For this reason, it’s recommended that you make your blocks independent from the editor module and any post object. Instead of relying on the editor module proxies, you are encouraged you to your code to target the block-editor APIs instead.

This involves:

  • Using wp-block-editor instead of wp-editor as script and style dependencies for your WordPress registered/enqueued scripts and styles.
  • Using the wp.blockEditor.* components instead of wp.editor.* ones.
  • Using the core/block-editor data module selectors and actions instead of the core/editor ones.

Components and Higher-Order Components Moved to block-editor

This is the exhaustive list of the components and higher-order components that were moved to the block-editor module.

  • Autocomplete
  • AlignmentToolbar
  • BlockAlignmentToolbar
  • BlockControls
  • BlockEdit
  • BlockEditorKeyboardShortcuts
  • BlockFormatControls
  • BlockIcon
  • BlockInspector
  • BlockList
  • BlockMover
  • BlockNavigationDropdown
  • BlockSelectionClearer
  • BlockSettingsMenu
  • BlockTitle
  • BlockToolbar
  • ColorPalette
  • ContrastChecker
  • CopyHandler
  • createCustomColorsHOC
  • DefaultBlockAppender
  • FontSizePicker
  • getColorClassName
  • getColorObjectByAttributeValues
  • getColorObjectByColorValue
  • getFontSize
  • getFontSizeClass
  • Inserter
  • InnerBlocks
  • InspectorAdvancedControls
  • InspectorControls
  • PanelColorSettings
  • PlainText
  • RichText
  • RichTextShortcut
  • RichTextToolbarButton
  • RichTextInserterItem
  • UnstableRichTextInputEvent
  • MediaPlaceholder
  • MediaUpload
  • MediaUploadCheck
  • MultiBlocksSwitcher
  • MultiSelectScrollIntoView
  • NavigableToolbar
  • ObserveTyping
  • PreserveScrollInReorder
  • SkipToSelectedBlock
  • URLInput
  • URLInputButton
  • URLPopover
  • Warning
  • WritingFlow
  • withColorContext
  • withColors
  • withFontSizes

Selectors Moved to block-editor

This is the exhaustive list of the data module selectors that moved to the core/block-editor store.

  • canInsertBlockType
  • getAdjacentBlockClientId
  • getBlock
  • getBlockAttributes
  • getBlockCount
  • getBlockDependantsCacheBust
  • getBlockHierarchyRootClientId
  • getBlockIndex
  • getBlockMode
  • getBlockName
  • getBlockOrder
  • getBlockRootClientId
  • getBlockInsertionPoint
  • getBlockListSettings
  • getBlocks
  • getBlocksByClientId
  • getBlockSelectionStart
  • getBlockSelectionEnd
  • getClientIdsOfDescendants
  • getClientIdsWithDescendants
  • getFirstMultiSelectedBlockClientId
  • getGlobalBlockCount
  • getInserterItems
  • getLastMultiSelectedBlockClientId
  • getMultiSelectedBlockClientIds
  • getMultiSelectedBlocks
  • getMultiSelectedBlocksEndClientId
  • getMultiSelectedBlocksStartClientId
  • getNextBlockClientId
  • getPreviousBlockClientId
  • getSelectedBlockCount
  • getSelectedBlockClientId
  • getSelectedBlock
  • getSelectedBlocksInitialCaretPosition
  • getTemplate
  • getTemplateLock
  • hasInserterItems
  • hasMultiSelection
  • hasSelectedBlock
  • hasSelectedInnerBlock
  • isAncestorMultiSelected
  • isBlockInsertionPointVisible
  • isBlockMultiSelected
  • isBlockSelected
  • isBlockValid
  • isBlockWithinSelection
  • isCaretWithinFormattedText
  • isFirstMultiSelectedBlock
  • isMultiSelecting
  • isSelectionEnabled
  • isTyping
  • isValidTemplate

Actions Moved to block-editor

This is the exhaustive list of the data module actions that moved to the core/block-editor store.

  • clearSelectedBlock
  • enterFormattedText
  • exitFormattedText
  • hideInsertionPoint
  • insertBlock
  • insertBlocks
  • insertDefaultBlock
  • mergeBlocks
  • moveBlocksDown
  • moveBlocksUp
  • moveBlockToPosition
  • multiSelect
  • receiveBlocks
  • removeBlock
  • removeBlocks
  • replaceBlocks
  • resetBlocks
  • selectBlock
  • setTemplateValidity
  • showInsertionPoint
  • startMultiSelect
  • startTyping
  • stopMultiSelect
  • stopTyping
  • synchronizeTemplate
  • toggleBlockMode
  • toggleSelection
  • updateBlock
  • updateBlockAttributes
  • updateBlockListSettings

Styles and Class Names

The components that moved from the editor module to the block-editor module are internally using CSS class names that follow the package they’re declared in.

For example, the editor-inserter__toggle class name is now renamed block-editor-inserter__toggle.

The old class names have been retained to minimize any backward compatibility concern, but the CSS styles are now targeting the new class names.

Ideally, you should rely on components in your own code instead of the internal class names used in the WordPress admin. But if you do use those classes, make sure to rename them accordingly.

#5-2, #dev-notes, #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

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