gutenberg-workshop Gutenberg Team Panel Talks Release Timeline, Theme Building, and Customization at WCEU design tips

The Gutenberg team took questions from a full room users and developers this morning before diving into the specifics of the editor’s design, block creation, and how to further extend the new interface. The first question they addressed is the one everyone is asking: When will Gutenberg land in core?

The team said the editor is pretty close to feature complete and should achieve that in the next few months when version 3.3 is released. At that point the focus will be on refining the current experience. They estimate this to happen in June or the first week of July but also hinted at more information coming in Matt Mullenweg’s keynote address this afternoon.

Developers also asked about the criteria that will be used to decide that Gutenberg is ready for a WordPress release. The project has a scope and features MVP issue on GitHub that provides an overview for the major functionality that will be introduced in the first version of the new editor. It shows which features have already been shipped and which ones are remaining.

The team explained that many of the final features have come from developer and user feedback. Some features were not necessarily planned for V1, but it became more apparent that these were needed because they improved either the developer or user experience. For example, within the past four or five months the team found that the child blocks would be necessary to allow developers to be more expressive in extending the editor. A few of the remaining issues include inline images and post locking for concurrent users, but the team doesn’t anticipate any major new features on the horizon before V1 is released.

Gutenberg engineers also assured workshop attendees that the project is being built with backwards compatibility in mind. One person asked what will happen when the 5.0 release lands. The team explained that the Gutenberg update will not change all the content on WordPress sites. When users open a post in the editor they will have the option to convert that content to block format so it will work with the new editor. If it doesn’t quite work, users be able to fall back to the classic editor.

The team said they took great lengths not to alter how WordPress deals with data. Gutenberg does not change the content structure. One of the cornerstones for the project is providing an update that will not fragment the content structure. There will be a lot of resources available ahead of the release for helping everyone move forward together.

Gutenberg engineers said they are working to be conscious not to delay the project, because the longer the delay, the more potential users WordPress is losing because the software is not easy enough for them to build and customize content and websites.

How Will Theme Building Change with Gutenberg?

Gutenberg designers and engineers also tackled questions about how the new editor will change the theme building experience. Design lead Tammie Lister emphasized the importance of theme developers first getting better at creating themes that do not try to do everything. The basic purpose of a theme is to style the frontend and provide an editor style. One potential way forward for theme developers is to provide additional features by releasing a suite of blocks via a plugin. Lister said she hopes that themes will become a lot lighter in the Gutenberg era and encouraged developers to utilize style guides.

The team also said that existing themes will continue to function and redesigning a theming API, without the hassle of editing a bunch of PHP files, may be possible in the future. However, it’s too early to know what that will look like. For now, the rendering engine is not changing. Theme developers interested in Gutenberg compatibility should start looking towards deconstructing their themes into individual elements and learn how to express a theme as a list of blocks.

How Will Gutenberg Handle Customization?

Attendees asked several questions regarding the specific plan to implement customization, or live previewing, after Gutenberg is in core. The current phase 1 handles content editing and puts the infrastructure in place to support customization. There are some issues on GitHub for transforming widgets into blocks, which will be a step towards the site building experience. The team has already implemented direct manipulation on the WYSIWYG road but phase 2 will cover more aspects of customization.

Gutenberg is not ready to replace the Customizer anytime soon, but the next phase will explore what a block-based experience of customization will look like. When asked if Gutenberg will “kill off some of the page builders,” the team said the goal is for page building type applications to be able to use Gutenberg as a springboard for different implementations that extend the editor in ways that benefit different types of users.

An attendee asked how the team plans to enhance adoption once Gutenberg lands in core. The team said they are working on an experimental feature called ‘tips’ that offers a story walkthrough of the publishing workflow. It includes helpful nudges to assist users in getting better at navigating the interface. The wider ecosystem has already responded with courses and tutorials to help developers get on board. The WordPress training team is also working on some training materials to use at WordCamps with tutorials for developers to learn how to convert existing plugins and themes to be Gutenberg-ready.