Gutenberg is more than an editor. While the editor is the focus right now, the project will ultimately impact the entire publishing experience including customization (the next focus area).

Discover more about the project.

Editing focus

The editor will create a new page- and post-building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery. — Matt Mullenweg

One thing that sets WordPress apart from other systems is that it allows you to create as rich a post layout as you can imagine — but only if you know HTML and CSS and build your own custom theme. By thinking of the editor as a tool to let you write rich posts and create beautiful layouts, we can transform WordPress into something users love WordPress, as opposed something they pick it because it’s what everyone else uses.

Gutenberg looks at the editor as more than a content field, revisiting a layout that has been largely unchanged for almost a decade.This allows us to holistically design a modern editing experience and build a foundation for things to come.

Here’s why we’re looking at the whole editing screen, as opposed to just the content field:

  1. The block unifies multiple interfaces. If we add that on top of the existing interface, it would add complexity, as opposed to remove it.
  2. By revisiting the interface, we can modernize the writing, editing, and publishing experience, with usability and simplicity in mind, benefitting both new and casual users.
  3. When singular block interface takes center stage, it demonstrates a clear path forward for developers to create premium blocks, superior to both shortcodes and widgets.
  4. Considering the whole interface lays a solid foundation for the next focus, full site customization.
  5. Looking at the full editor screen also gives us the opportunity to drastically modernize the foundation, and take steps towards a more fluid and JavaScript powered future that fully leverages the WordPress REST API.


Blocks are the unifying evolution of what is now covered, in different ways, by shortcodes, embeds, widgets, post formats, custom post types, theme options, meta-boxes, and other formatting elements. They embrace the breadth of functionality WordPress is capable of, with the clarity of a consistent user experience.

Imagine a custom “employee” block that a client can drag to an About page to automatically display a picture, name, and bio. A whole universe of plugins that all extend WordPress in the same way. Simplified menus and widgets. Users who can instantly understand and use WordPress — and 90% of plugins. This will allow you to easily compose beautiful posts like this example.

Check out the FAQ for answers to the most common questions about the project.


Posts are backwards compatible, and shortcodes will still work. We are continuously exploring how highly-tailored metaboxes can be accommodated, and are looking at solutions ranging from a plugin to disable Gutenberg to automatically detecting whether to load Gutenberg or not. While we want to make sure the new editing experience from writing to publishing is user-friendly, we’re committed to finding a good solution for highly-tailored existing sites.

The stages of Gutenberg

Gutenberg has three planned stages. The first, aimed for inclusion in WordPress 5.0, focuses on the post editing experience and the implementation of blocks. This initial phase focuses on a content-first approach. The use of blocks, as detailed above, allows you to focus on how your content will look without the distraction of other configuration options. This ultimately will help all users present their content in a way that is engaging, direct, and visual.

These foundational elements will pave the way for stages two and three, planned for the next year, to go beyond the post into page templates and ultimately, full site customization.

Gutenberg is a big change, and there will be ways to ensure that existing functionality (like shortcodes and meta-boxes) continue to work while allowing developers the time and paths to transition effectively. Ultimately, it will open new opportunities for plugin and theme developers to better serve users through a more engaging and visual experience that takes advantage of a toolset supported by core.


Gutenberg is built by many contributors and volunteers. Please see the full list in


How can I send feedback or get help with a bug?

We’d love to hear your bug reports, feature suggestions and any other feedback! Please head over to the GitHub issues page to search for existing issues or open a new one. While we’ll try to triage issues reported here on the plugin forum, you’ll get a faster response (and reduce duplication of effort) by keeping everything centralized in the GitHub repository.

How can I contribute?

We’re calling this editor project “Gutenberg” because it’s a big undertaking. We are working on it every day in GitHub, and we’d love your help building it.You’re also welcome to give feedback, the easiest is to join us in our Slack channel, #core-editor.

See also

Where can I read more about Gutenberg?


Not everyone needs everything to be blocks. Gutenberg must focus on writers

TLDR: I think Gutenberg, as it is now, is made for web developers, and not so much writers. I want Gutenberg’s many improvements to also benefit those writers, therefore I suggest making blocks implicit for simple text markup, so the writer can think of their text as a text, not as a series of blocks.


I’ve tried out Gutenberg a little bit, and wanted to chime in some thoughts. Especially because of the high number of unsubstantiated negative reviews. I haven’t been able to test out Gutenberg on any non-web-developer myself, so this is based on my thoughts after trying the editor, thinking it was passable (though a bit weird), then being surprised by the reviews. So please take this with a grain of salt.

I have worked with HTML and CSS for the majority of my life at this point. I also find the concept of the Gutenberg editor easy to grasp, and I understand how to get the desired result. One of the stated goals of the editor is to make it effortless to write rich posts, and for me, Gutenberg delivers on that goal.
I realize, however, that I’m no ordinary user. Through my knowledge and familiarity with HTML and CSS, I know the HTML box model very well. Gutenberg’s mental model – considering everything as a box/block – maps almost one-to-one to the mental model of HTML. As a web designer, I can feel right at home in the Gutenberg editor.

Ordinary users are not web designers. They are writers, focusing on creating engaging content, conveyed primarily through text. They are, in their mind, writing one long text, not a series of “blocks” each containing some text or an image. They do not care about the technical details of HTML – and they shouldn’t need to either. (I’m not saying that you cannot be both a web designer and a writer. Just that the Gutenberg editor should target also those who are not a web designer.)

The Gutenberg editor, in my opinion, forces writers to learn the mental model of HTML, essentially moving the job of converting text into HTML tags from WordPress to the user. They shouldn’t need to care about how each paragraph is a block of its own, yet they are presented with controls aligned inside each paragraph, controls split between the paragraph and the header, and a border around each paragraph as they hover over it. They shouldn’t need to care about where one block ends and another one starts, yet they cannot select the last sentence of one paragraph and the first sentence of the next. They also cannot drag and drop the resulting selection, instead they’ll be making a new selection. Writers essentially have to learn a new way of writing text on a computer, one radically different from the one they are used to from working with Microsoft Word, LibreOffice Writer, Google Drive and almost any other WYSIWYG text editor out there. And I don’t see how that is necessary.

Gutenberg does solve a lot of problems, though. Replacing short-codes and many other mechanisms with blocks is great. Just like writers shouldn’t need to think of their text in terms of blocks, they shouldn’t need to learn short-code markup. Granting the writer more flexibility without needing to dive into the theme’s HTML and CSS is also great. I like how the block model makes (image) placement easier, since they are stopped from being placed in the middle of a paragraph. And being able to preview and edit the non-text blocks without needing to bring up a modal is super-cool, and grants Gutenberg an edge over many other editors. The block mental model is great for designing rich posts, where the writer may be expected to be tech-savvy and have some familiarity with HTML.

I think it is possible to reconcile Gutenberg’s improvements with the traditional way of writing on a computer. It does require moving away from the mental model of “everything is a block”, so I don’t expect this to be an easy decision to make. Either way, my suggestion is to introduce an option, enabled by default, that makes text blocks implicit rather than explicit. By that, I mean that the fact that the text is organized into blocks should not affect, nor need to concern, the user. The only exception would be the constraints placed on block placement, so you wouldn’t be able to place e.g. an image in the middle of a paragraph (except for any inline image blocks, of course). This also only needs to apply to text blocks in the same container. Some examples of concrete changes this would require:

  • Text formatting controls (like making text bold, italic, text size, changing between paragraph and headings and so on) are docked to the top of the document, not the active block
  • No border or any other visual indication of blocks are shown when hovering over implicit text blocks
  • When you select text, you do not start to select entire blocks when crossing a block border. It should basically function like any other editor
  • You should be able to drag and drop your text selection to move it
  • The explicit blocks (like images, embeds, galleries) need not be changed, and can keep their block behaviour. They are already special in the user’s mind, I think, and they act like blocks in other editors too. Clicking the arrows to move them will still move them one block at a time

This way, I think the user can still focus on their writing without the block borders getting in their way, while enjoying the benefits of WYSIWYG special (explicit) blocks replacing the short-code mechanism. Though, it’s hard to say without trying and comparing it. It would be interesting to try this out and compare between explicit and implicit text blocks.

I think the Confluence editor is a good example of combining special blocks with text, though the Gutenberg WYSIWYG blocks are a clear improvement over Confluence’s, the latter using modals to configure blocks (widgets) which are represented with placeholders in the editor itself. The Medium editor also comes to mind as an example.

There are many other things that needs addressing, this is just the biggest one in my opinion. I also agree 100% with @matthewhollett’s review, which touches on some of the same points.

I hope this can be of some help.


I am forever fighting against the problem of Visual Composer and other such tools that make the web overly complex, poorly semantic and less accessible. While this is probably great for those who are just managing some blog pages, it is an absolute kick in the teeth to actual web developers doing actual web development. That this is intended to become the default editor is a travesty and the biggest misstep made by WordPress.

Zero Stars – terrible editor

This editor is horrible. He is aimed at absolute amateurs. The user should not concentrate on writing but on idiotic clicks. Which leads to the fact that there will again be websites like 1998: Colourful, shrill and ugly. Responsive websites no longer work because the user can resize the items even more easily.
On top of that, he is not interrested in a little a bit of privacy.
What would WP really need? Twig, bootstrap and sensible caching and really responsive images (image sizes to maintain over the admin area), but no there must be such a nonsense built in.

Gutenberg gets WordPress wrong and is a terrible writing environment

I’ve been developing with WordPress for 10 years, and currently administer about 40 client websites. I’ve spent some time with Gutenberg, and I’m certain that if this is where WordPress is headed, it’s probably the beginning of the end of my reliance on it as a content management system.

WordPress has always been focussed on writing. The classic editor works wonderfully as a writing environment. My clients find it intuitive because it mimics the interface of Word and similar software. I’ve rarely had to explain to anyone how to compose a post in the classic editor – they just get it.

As a writing environment, Gutenberg is obscenely clunky. Little labels and toolbars fly around when I move from paragraph to paragraph. It’s visually distracting and disruptive – I want to be able to click and edit writing without having to worry about a toolbar jumping in the way. The sidebar seems designed to encourage users to futz around with font sizes and colours rather than writing. It breaks basic OS-level text editing features like being able to highlight text and drag it to a new location.

I understand the usefulness of “blocks”, and I think a more minimal approach to creating “blocks” in WordPress could work well. uses a similar concept and still manages to be a pretty great writing environment. Gutenberg is not. It is not ready for wide release, and should never be made the default editing experience. I hesitate to call it an “editor” at all – it feels like an overly complex, knockoff page-builder.

For example – I type a line of text, then decide to make it a heading. To do that, have to click the “paragraph” symbol, which makes no sense (and the button does not even look “clickable”, since it’s already highlighted). Gutenberg makes it far easier to just make the font size bigger so it looks like a heading, which is what 90% of casual users will probably do, which seems like a disaster for accessibility.

Some of your UI decisions are bizarre. Why is the “Publish” button crammed in the top right corner, where it is much less visible? Why did you remove the word count tool? Why on earth does a “Change Permalinks” button show up when I’m editing the post title? (Also, the permalinks for new posts are being displayed in “Plain” format, when my settings specify “Post Name”).

Gutenberg litters HTML code with cruft, and seems likely to break a ton of plugins I rely on, such as Advanced Custom Fields. It makes WordPress less intuitive for casual users, and is basically a nightmare for longtime developers. Please rethink what you are trying to accomplish with this.

Read all 997 reviews

Contributors & Developers

“Gutenberg” is open source software. The following people have contributed to this plugin.


“Gutenberg” has been translated into 34 locales. Thank you to the translators for their contributions.

Translate “Gutenberg” into your language.

Interested in development?

Browse the code, check out the SVN repository, or subscribe to the development log by RSS.



  • Fixed an issue that caused page publishing to fail.
  • Fixed an issue with the block options menu appearing too narrow.


  • Updated block inserter and library with new icons for all core blocks.
  • Allow showing the sidebar and inspector controls when editing a block in HTML mode.
  • Add new block keyboard shortcuts and consolidate their display in menus:
    • Insert Before / After block.
    • Duplicating block.
    • Toggling the inspector.
    • Remove block keyboard shortcut.
  • Updated block inserter and library with new icons for all core blocks.
  • Allow showing the sidebar and inspector controls when editing a block in HTML mode.
  • Add new block keyboard shortcuts and consolidate their display in menus:
  • Insert Before / After block.
  • Duplicating block.
  • Toggling the inspector.
  • Remove block keyboard shortcut.
  • Add new keyboard shortcuts help modal documenting available shortcuts.
  • Hide keyboard shortcuts on mobile screens.
  • Open new window if prior preview window has been closed.
  • Bring the preview tab to the front when clicking the preview button.
  • Avoid changing the label of the “publish” button if an auto-save is being performed.
  • Update the Block Inserter to allow searching for terms that contain diacritics.
  • Take into account children blocks when handling disabled blocks.
  • Offer chance to add and revise Tags and Post Format during pre-publish flow.
  • Let menus grow based on the length of its elements.
  • Add visual padding to menus.
  • Avoid scrollbars on Audio block when shown full-width.
  • Improve permalink UI and make it responsive.
  • Change color of links in gallery block caption.
  • Simplify the styling of the “Toggle publish panel” aria-region to avoid content jumps.
  • Make active pill button look pressed.
  • Make sure Latest Posts alignment class behaviour is consistent.
  • Show drop-zone background when file is dragged.
  • Reset active sidebar tab on initial load.
  • Apply new checkbox CSS to radio buttons and fix border radius.
  • Add a couple new dashicons for insert before / after block.
  • Add styles for Spinner component (was relying on core before).
  • Add styles for Notice component.
  • Refactor template select field to use SelectControl.
  • Correctly handle per_page=-1 in the queried data state.
  • Create dummy context components for type switch.
  • Add RegistryConsumer export to data module.
  • Add has_blocks function to the repertoire.
  • Add has_block function and unit tests.
  • Add has_block function and unit tests for it.
  • Introduce strip_dynamic_blocks() for excerpts.
  • Fix issue with default appender placeholder on IE11.
  • Fix issue with shortcode block UI on IE11.
  • Fix tag input interface on IE11.
  • Fix issue with custom element serializer on IE11.
  • Fix issue with meta boxes overlapping the content on IE11.
  • Fix invalidation case of custom block classes.
  • Fix unhandled error dialog styling issue.
  • Fix paragraph splits on react native implementation.
  • Fix code block style regression.
  • Fix issue with code font-size on heading contexts.
  • Fix case where crashed block would overlap with surrounding blocks.
  • Fix issue with block styles on IE11.
  • Fix the heading level buttons on IE11.
  • Fix issues with drag and drop over text.
  • Fix small bug with recent blocks hover style.
  • Use argument swapping instead of named arguments for string placeholders.
  • Pass the the search result object to props.onChange on UrlInput.
  • Add localization context to occurrences of “More” string.
  • Add a Heading block implementation for mobile app.
  • Add the react-native entrypoint to all runtime packages.
  • Move MoreMenu specific styling away from Popover CSS.
  • Ensure meta box functions are available in editor context.
  • Ensure the full content integration test is run.
  • Remove client-side document title updates.
  • Remove TinyMCE shim that was removed in WP 4.9.7.
  • Remove the workaround for intermittent multiple-tab preview test failure.
  • Remove Promise.resolve call that’s already handled by the JS runtime.
  • Remove redundant event handlers from default block appender.
  • Deprecate withContext HOC and remove its usage.
  • Some localization & spelling fixes.
  • Update docs for templateLock’s insert option.
  • Extract Core Blocks to a block-library npm package.
  • Add a license checker script.
  • Allow access to the WordPress installation if DOCKER_ENV=localwpdev.
  • Bring the handbook design up to date.