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!


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






New APIs


Add knobs to the ColorIndicator Story.


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.





  • 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.



  • 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.


  • Triaged and organized the project board.



Open Floor

  • @bharath asked for update on adding background image support for group block
  • 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.


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} 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.



Bug Fixes






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.



New APIs

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







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, 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, 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.




Bug Fixes





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:paragraph { content: "Hello, world!" }
wp:area { id: "post" }

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 Local Environment Rewrite

With the introduction of the WordPress Local Environment, the next step was to make this shiny new development environment available for Gutenberg to use.

tl;dr: If you currently run ./bin/ to use the Gutenberg environment, switch to running npm run env install, instead.

Gutenberg’s Local Environment was originally an experiment in making it easy to setup a local development environment. It was a success in some ways, in that it was easier than other methods, but it was by no means easy overall, particularly for non-developer contributors. Over time, it grew into a complex set of shell scripts, with surprising interdependencies and side effects. Being written in Bash made the scripts harder to maintain, and limited the potential audience to those who had a Bash-compatible terminal installed.

Basing Gutenberg’s Local Environment on Core’s has several immediate advantages:

  • It’s cross-platform, only requiring Docker to be installed and running. It also works with Docker Toolbox, allowing all Windows users (not just those with Windows 10 Pro) to use it.
  • The WordPress environment uses Docker images that we maintain for the purpose of Core development, which allows us to to customise them as we need.
  • It ensures that tests for Core and Gutenberg run in the same environment.
  • It’s a single environment, which helps avoid the naming clashes we’ve occasionally seen between the Core and Gutenberg environments.

More broadly for WordPress in the long term, tying the development processes of Core and Gutenberg a little closer together helps pave the way for the processes to merge over time.

Architectural Decisions

Removing the Docker config from Gutenberg entirely (barring a minimal template to hook into the Core environment), and requiring wordpress-develop to run on top of gives us significantly more future flexibility with the development environment.

Additionally, this continues to lay the groundwork for an environment that works as easily as possible for non-developer contributors. In particular, this environment is intended to be usable by all feature plugins, allowing them to easily enable new contributions in a familiar environment. (Or, an environment that will become familiar, at least. 😉)

There are several reasons for putting the main Docker config in Core, and extending it in Gutenberg:

  • Having a single docker-compose.yml file in Core, as opposed to having one in Core, one in Gutenberg, and many more in other feature plugins that will be able to use this, means that there’s only set of Docker containers running. Docker has been observed getting a little weird when trying to run containers with the same names, which mount volumes with the same names.
  • Having multiple docker-compose.yml files doesn’t lend itself to testing plugins together: each plugin ends up with its own environment which can’t talk to others.
  • Managing how plugins can mount older versions of WordPress becomes exponentially more difficult if the docker-compose.yml config needs to work for every WordPress branch (this is a requirement, so that auto updates can be worked on in old branches), rather than being able to tweak the config for each branch.
  • Ideally, feature plugins shouldn’t need to do much customisation of the Docker environment, beyond mounting their particular volumes. Exposing the entire docker-compose.yml file is overkill.

That said, not every Gutenberg contributor will have a WordPress source clone, or want to manage one. So, there’s also a helper which will download and install a copy of the WordPress source repo, when needed.

Much like the WordPress environment, however, the Gutenberg environment doesn’t automate everything. As we found with the original Gutenberg environment, too much automation tended to make it difficult (particularly for more advanced contributors) to customise or debug their environment. For example, the scripts no longer install NVM, switch your Node version, or run npm install.

Using the Gutenberg Local Environment

If you don’t have a WordPress repo to work with, just run npm run env install, that’ll take care of downloading WordPress, building it, and connecting Gutenberg into it.

If you prefer to hook into your own WordPress source checkout (particularly useful for fixing issues that span Core and Gutenberg), set the WP_DEVELOP_DIR environment variable to your WordPress source directory, and run npm run env connect. This will write a docker-compose.override.yml file to the WordPress source directory, and restart the Docker containers. The Docker override file contains the appropriate volume settings for mounting Gutenberg within the WordPress environment.

Running npm run env will give you a complete list of the available commands, and what they’re for.

The WordPress Local Environment configuration options are also available for configuring the Gutenberg environment.

Adding the Local Environment to another feature plugin

The @wordpress/scripts documentation includes information about including and configuring the local environment.

There currently isn’t a clean method for sharing a managed WordPress checkout (ie, one installed by npm run env install) between plugins. Let’s figure out how that could work!

Also, this process is still mostly untested, so please ping me earlier rather than later if you run into problems. 🙂

Developing Plugins/Themes with the Local Environment

At this stage, the Local Environment is intended for developing Core, and Feature Plugins: it doesn’t have the config options that the wider plugin/theme ecosystem needs, and the base Docker images are built for Core purposes.

Of course, I know y’all will try to use it, anyway. 😉 Testing and feedback is welcome, but please be aware that fixes and features will prioritise Core/Gutenberg requirements for the foreseeable future. Patches and PRs which recognise and allow for this are the best way for additional changes to land. 💖

What’s Next?

Please try out the new Gutenberg Local Environment, and report any issues you run into over on the Gutenberg repository.

If you have thoughts about making this aspect of contributing to Core/Gutenberg easier, I’d love to hear about them!

#block-editor, #gutenberg

What’s new in Gutenberg? (28 August)

With the date of the WordPress 5.3 beta release approaching, testing Gutenberg is increasingly more critical. Any help testing the plugin is much appreciated as it may avoid bugs in a future WordPress beta release.

The Gutenberg 6.4 release brings some interesting highlights.

The Cover block got two new significant functionalities: the ability to be resized and the ability to use a solid color as a background instead of a video or an image.

Recently we added an API that allows themes and plugin developers to create block styles using just PHP calls. In this release, we continued the improvements to the block styles and added the ability for the users to select their preferred default style per block. Each time the user inserts a block, the preferred style is automatically applied.

Another relevant improvement in this release is the introduction of the “Typewriter experience“. We hope this makes writing more “fun” and overall more comfortable, especially on mobile.

6.4 🇫🇷




New APIs

Bug Fixes




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.4 5.6s 66.36ms
Gutenberg 6.3 5.4s 66.87ms
Gutenberg 5.3 (WordPress 5.2) 6.0s 75.79ms

#core-editor, #editor, #gutenberg