What’s new in Gutenberg? (27 November)

More than 51 contributors helped shape the 7.0.0 Gutenberg release. It’s one of the biggest number of contributors we’ve ever had.

The release includes a big number of fixes and enhancements to the Navigation block and marks it as a stable feature.

Navigation block in action

In terms of APIs, developers will be happy to know that this PR introduced some new APIs like allowing the internationalization of strings containing safe HTML, a new Card component in wordpress/components and a few other enhancements we encourage you to try and provide feedback.

7.0

Features

Enhancements

Bug Fixes

New APIs

Experiments

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 7.0.0 5.1s 67.7ms
Gutenberg 6.9.0 6.6s 53.5ms
WordPress 5.3 6.3s 61.44ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

What’s new in Gutenberg? (13 November)

In this newest release of Gutenberg, block content areas and the navigation block continue to be iterated upon. An experimental block pattern API has been added, and themes can now define custom gradient presets!

The navigation block, demonstrating newly improved horizontal block movers.
The navigation block, demonstrating newly improved horizontal block movers.

The block editor provides default gradient presets. Now, a theme can overwrite them and provide its own:

add_theme_support(
    '__experimental-editor-gradient-presets',
    array(
        array(
            'name'     => __( 'Vivid cyan blue to vivid purple', 'themeLangDomain' ),
            'gradient' => 'linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%)',
            'slug'     => 'vivid-cyan-blue-to-vivid-purple'
        ),
    )
);

Note that this feature is currently experimental and subject to change.

6.9 🇦🇷

Features

Bugs

Enhancements

New APIs

Various

Experimental

Documentation

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.9.0 11s 77.36ms
Gutenberg 6.8.0 11s 74.78ms
WordPress 5.3 10.6s 80.85ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Join the Gutenberg Customization Conversations 🎨

As we head towards the end of the year, two last projects surface as the culmination of the Gutenberg Customization phase. If you are interested in contributing, or want to join the ongoing discussions, this post outlines what the main focuses are and the threads to follow.

Full Site Editing.

Over the past eight months activity has focused on refining the editor experience, converting widgets to blocks, defining block areas, creating a new navigation block, introducing global blocks like site title, and several new tools to improve the customization capabilities of blocks. The idea is for all these elements to come together in an editor mode that comprehends the full structure of a site, including its global elements and dynamic pages.

Label “[Feature] Full Site Editing” in the repository for more details.

Block Patterns.

While blocks are powerful visual tools to achieve many different designs, it can take time and knowledge to combine them properly to achieve the most pleasing results. Since Gutenberg already supports block templates, it should be possible to offer users designs and patterns that are already assembled for them — made of various existing blocks — which users can then customize to their will with familiar tools. Part of this work includes exposing relevant APIs so these can be more easily developed and discovered.

You can also join the weekly meetings held in the #core-editor channel in the Making WordPress Slack, every Wednesday at 13:00 UTC.

Thanks for the help!

#gutenberg

What’s new in Gutenberg? (30 October)

Work on block content areas and the navigation menu block is accelerating in this release.

In the meantime, this release continues the work on Gradients support and expand it to the Cover block while relying on classnames instead of inline styles

Screenshot 2019-10-17 at 14 59 27

Block Nested selection and interactions is still being improved with a new Block Breadcrumb Bar allowing to quickly navigate the block hierarchy of . the current selection.

Capture d’écran 2019-10-16 à 11 34 50 AM

6.8

Features

Enhancements

Bugs

Experiments

New APIs

Various

Add knobs to the ColorIndicator Story.

Documentation

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.8.0 5.68s 47.28ms
Gutenberg 6.7.0 5.83s 47.92ms
WordPress 5.2 6.1s 63.22ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Editor chat summary: Wednesday, 23 October 2019

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, October 23, 2019, 13:00 UTC.

Gutenberg 6.8

Gutenberg 6.8 RC is scheduled for release next week Monday.

Weekly Priorities

These week priorities are same as last week. There has been some progress on the PRs and some are getting close to merge.

Task Coordination

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

@ella

@andraganescu

@youknowriad

@jorgefilipecosta

  • Worked on the gradient related tasks.
  • Submitted a core patch to make KSES allow gradient backgrounds.
  • Proposed a solution for automatic editor styles generation.
  • Will work on oprn PR/Patch.
  • Will work on iteration to custom gradient picker.

@get_dave

@gziolo

  • Helped with Storybook, explored unit test generation for stories.
  • Fixed ESLint warnings.
  • Ensured repository works with Node 12.x.
  • Reviews and general help with tasks:
    • Card components.
    • Accessible toolbar.
    • prettier code formatter integration.
    • new packages with the base styles.
  • Will start work on Patterns API for blocks and continue working on items listed.

@karmatosed

  • Triaged and organized the project board.

@retrofox

@vindl

Open Floor

  • @bharath asked for update on adding background image support for group block https://github.com/WordPress/gutenberg/issues/14744.
  • There was some discussion around removing cover block in favor of group block with background image support.
  • @gziolo mentioned for backward compatibility reasons Cover block will have to exists forever.

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

What’s new in Gutenberg? (16 October)

Work on stability and performance continues, and these bug-fixes have now been included in WordPress 5.3 RC 1.

In addition, this release starts the work on gradient backgrounds. First, the support is added to the Button block. Improvements to the gradients palette API and support in more blocks will be worked on for future releases.

Storybook

For Developers, this release also introduces a Storybook.

Accessible on this link for the master version, but also available on each Pull Request (https://deploy-preview-{PR_number}--gutenberg-playground.netlify.com/design-system/components/). Storybook is an isolated environment where the reusable WordPress UI components (@wordpress/components) are developed, tested and showcased.

Down the road, the netlify integration and the exact URLs can be adapted. This tool is meant to be directly integrated into WordPress Developer Docs.

6.7

Features

Bug Fixes

Performance

Enhancements

Experiments

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 6.7.0 5.52s 51.98ms
Gutenberg 6.6.0 5.57s 51.47ms
WordPress 5.2 6.53s 61.13ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

What’s new in Gutenberg? (2 October)

This is release is essentially focused on stability and performance. These bug-fixes and improvements have now been included in WordPress 5.3 beta 2.

At the same time, architectural work is continuing to prepare the block content areas editing capabilities.

6.6

Enhancements

New APIs

  • Implement EntityProvider and use it to refactor the meta block attributes.

Experimental

Bugs

Performance

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.6.0 4.7s 38.96ms
Gutenberg 6.5.0 4.68s 42.96ms
WordPress 5.2 5.69s 57.65ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Editor chat summary: 18 September 2019

This post summarizes the weekly editor chat meeting on Wednesday, 18 September 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Many folks were in transit, which made this a less busy meeting than usual.

Gutenberg 6.5 Release

Releasing shortly. You can see the RC here.

This will be the last release that goes completely into WordPress 5.3.

This is released now!

Weekly Priorities

Help test the RC!

Now released and in trunk — Please help test!

Task Coordination

  • @nadir is working with @joen on improvements to the Separator block (may end up as new Divider block), and looking into making the Stylelint config more strict.

Open Floor

@paaljoachim wanted to bring attention to a couple tickets:

@mikeschroder brought up https://github.com/WordPress/gutenberg/issues/6652, which is in regards to adding height and width attributes back to images in Gutenberg.

This ticket had conversation that started on Twitter with a tweet from Jen Simmons. There is a WICG recommendation that Mozilla is testing (and sounds like Chrome is planning as well) that makes rendering faster if height and width attributes are provided for images.

@desaiuditd is looking for feedback on https://github.com/WordPress/gutenberg/pull/17311, specifically regarding details on how the proposed useFilter would work.


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

The next meeting is on 25 August 2019 at 13:00 UTC.

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

What’s new in Gutenberg? (18 September)

More than 46 contributors participated in the Gutenberg 6.5 release. It’s the last release that is going to be entirely included in the upcoming WordPress 5.3.

This release comes with a huge number of features, improvements and bug fixes. Among these, the long asked for Social links block.

It also adds support for local auto-saves to avoid content loss even in environments with unstable internet connections. Edits are saved locally, and a warning is displayed with the possibility to restore the local edits if available.

Several blocks have been updated with new features such as the support for border radius changes in the Button block and the possibility to add a caption to the Gallery block.

This release includes the possibility to install blocks that are not available locally directly from the block inserter if you have the required permissions. This feature is marked as experimental feature. A dedicated call for testing will be published soon.

6.5

Features

Enhancements

Bug Fixes

Experiments

APIs

Various

Documentation

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.5.0 4.46s 54.43ms
Gutenberg 6.4.0 4.67s 53.30ms
Gutenberg 5.3 (WordPress 5.2) 6.16s 62.43ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Defining Content–Block Areas

One of the major projects from this year’s focuses is to expand the block editor beyond the content area and into other parts of the site. This included, so far, explorations to bring blocks into other screens within the dashboard as well as converting existing widgets into blocks. One of the remaining things to figure out is the specification of content areas themselves. In this post I’d like to start discussing what content areas are and present an example of how it can tie several concepts of phase two of Gutenberg together.

What Are Content Areas?

In its simplest form, content areas represent parts of a site where blocks can be added and manipulated. Since content has a very specific meaning in WordPress already, we can also refer to these as block areas more generally to avoid opaqueness. Block areas would include headers, footers, sidebars, and any other meaningful template part outside of the post content that contains blocks.

The concept of block areas helps provide a way to meaningfully organize blocks within a full page, but is also a way to differentiate between global elements (navigation, site title, and so on) and local elements (the main content of a post, page, or custom post type).

This proposition groups the general Gutenberg roadmap into the following three ideas — how blocks are organized within the main content area, how block areas are organized within the page, and how pages are organized within the site.

Phase one focused, for the most part, on the first idea. The following video tries to illustrate aspects of the second formulation.

Showing how block areas can be organized within the page, with some blocks from the Kioken library making an appearance.

Let’s dissect what is going on a bit more in detail — this will be a fairly technical overview.

Block Areas

Displaying a "header" block area as a single editor view.

Technically, block areas are defined as individual entries in a wp_template custom post type. These structural units can hold any number of blocks and have loose semantics. Also within wp_template are special root templates that can aggregate various block areas. Areas are equivalent to the general use of template parts in themes for this scenario.

wp:area { id: "header" }
    wp:site-title
    wp:navigation
    wp:paragraph { content: "Hello, world!" }
wp:area { id: "post" }
    wp:post-title
    wp:post-date
    wp:post-content

They exist as their own retrievable entries (from `wp_template`) and can be combined within larger template units, providing both conceptual separation and a potentially unified editing flow at the same time. The editor application is capable of saving the different elements to the right places.

Areas can contain general blocks or context-specific blocks (like “post title”, “post date”, and “post content”), making it possible to have more complex theme layouts and designs. In this context, any block offered by WordPress can be a widget in that it could be added to global areas of a site.

Block areas can only be used directly within templates and are not accessible in regular editing sessions. (These are equivalent to theme-editor responsibilities.) The content of block areas, however, becomes easy to edit in a familiar block-editing environment. It is important, then, to distinguish the ability to modify what block areas contain and the ability to insert and define block areas themselves.

It is worth noting that block areas are initially indifferent to where data is sourced and have a non-dependant relationship with editor providers. That means they can define the structure of a theme or layout but don’t deal with granular data allocation; only the blocks used within determine where specific data is allocated. (For example, a Site Title block would be saving its content to the relevant site option regardless of whether it is inserted in a header block area or a footer block area.)

The block navigator can identify different template parts and their contents.

An editor view that understands block areas would be able to display a site design either entirely or in parts. While being able to display areas together is crucial for a faithful representation of the design, the system is still able to separate and orchestrate how data is saved, keeping clear boundaries between local and global content, and allowing flexibility in representing dynamic content. Since block areas are internally blocks defining an inner blocks group they can be exposed through the regular block navigator and identified by display name.

It’s not the most important right at this time to dwell on the implementation details of how a template is defined by a theme declaration, as this could be established through a PHP structure or JSON objects (internationalization is a good subject to keep in mind here) while the anatomy of block areas remains equivalent.

// Example of a root template using various block areas.
{
  "slug": "single",
  "content": [
     [ 'theme/header' ],
     [ 'core/paragraph', { content: "Some content..." } ],
     [ 'core/post' , {}, [
         [ 'core/post-title' ],
         [ 'core/post-content' ],
     ] ]
     [ 'theme/footer' ],
  ]
}

In the example above the `theme/footer` is not a real block but something that gets swapped with a `core/template-part` referencing the corresponding block area.

With this specification, the full layout and design of a given page can be represented through blocks and block areas.

Open questions:

  • Looking further into the future, should wp_templates reflect the current template hierarchy? Example: an entry with an archive slug would map to how archive.php operates today and so on. What would this unlock for users that was harder to do before? (Easy customizations for specific category pages, for example.)
  • How should declaration work from a theme perspective? What would be the most idiomatic in the current paradigm? What would offer most convenience for the future?
  • How can we incorporate more granular add_theme_support into the areas so that color palettes, content widths, etc, are more refined and contextual?
  • Is it worth establishing common semantic areas for added portability? Current templates can be validated and there could also be transformation tools (same as block to block, block area to block area).

Relevant Issues:

Full-Page Editing

The “selector” presentation in the header of the demo is merely a convenient prototype tool and not an implementation proposal.

While block areas provide the structure to handle global elements, the editor also needs to understand how to work with them. There are largely two possibilities: a single editor that could handle all block areas together —providing a comprehensive full view of the site— or multiple editor views for each specific area.

Since each block area is effectively a post-entry, it is already easy to edit them in a regular Gutenberg session. However, as shown in the video, we can also augment the editor so that it can combine all the block area definitions from a template together in a single editing session, providing a comprehensive view of the full page.

Modes allow to explore various configurations and aspects of the editing session, such as focusing on certain areas (the post and its content, the header, sidebar, or footer in this example) and tailor tools to each task at hand. They can also control what is editable and what is locked down, providing the most convenient tools and interactions for each context. We could imagine a site-building mode that exposes more advanced theme tools, or a design mode that helps with alignment issues, balance, and document semantics.

Editing modes can also take into account the currently available block areas to expose specific modes centered around each of these template parts. These views can potentially take over many of the dedicated appearance menus.

While in “writing” mode, only the post properties are saved, whereas full-site editing orchestrates saving not just the content but also each individual template part plus the container template together.

Modes could also be extended by plugins to cover other editorial needs, like toggling between member / non-member states, ads / no-ads, and could also help as a presentational foundation for multi-language in the near future.

Open questions:

  • How should saving work from a UX perspective when there are multiple blocks with global data?
  • Should modes be toggleable within an editing session or should they be isolated to full page views (like the customizer)? (Full-site editing, design mode, etc, could all be part of a specific admin section like the customizer is now.)
  • Implicit relationships between modes and user roles.

Relevant Issues:

  • Selection Tools –17088.
  • Expanding editor beyond post_content –16281.
  • [Explore] Template mode and declarative post blocks: –17263.

Entities & Sources

With block areas handling global elements there is a need to access and manipulate site-wide data from individual blocks and for the editor application to centrally orchestrate its saving mechanisms. The goal is to eliminate the need for block authors to have to handle update mechanisms for non-HTML data.

For this purpose, the current data entities system would absorb more responsibilities and allow blocks to have bindings with data sourced from multiple places in WordPress including sourcing and updating. The block can then consume it as any regular attribute and doesn’t have to handle requests or saving operations. This stays true to the fact that blocks define primarily an interaction model, not a data model.

The architecture of entities has been iterated multiple times already and is meant to be low level so we can do all these optimizations and streamline block declaration.

This mechanism is used in the demo to create a “Site Title” block which operates like any other block in the page, yet doesn’t save to the document HTML source but to the proper site option. These attributes are synchronized from the entity value, so if the block appears multiple times (like showing the title both in the header and the footer of the site) they are kept in sync and reflect all edits within the session. The goal is arriving at a declarative API for custom entity blocks that allows the editor to handle saving the block harmoniously in the same saving flow as everything else.

Relevant Issues:

  • Updating the store to use Core Data entities –16932.
  • Implementing EntityProvider and using it to refactor custom sources –17153. (This work also provides a considerable performance boost.)
  • Add a Site Title block and required functionality –17207.

If you’d like to help with any of these three efforts, join the conversations on GitHub or in Slack at #core-editor!

#gutenberg