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


¿Cómo puedo enviar feeaback u obtener ayuda con un error?

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.

¿Cómo puedo contribuir?

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?


Fantastic, about time too!

Really impressed with the work done to this. It brings WordPress up to the standard of the rest of the web, if not exceeding it. I haven’t found a legit review yet that gives any bad points. They are peoples fears, lack of knowledge or lack of skill.

This will revolutionise WP and the web. It opens huge opportunities to current WP, to clear the WP world of the amateur rubbish that floods the system and gives WP it’s bad name among devs.

Brilliant job WP team, keep it coming, keep modernising!

Not Good

My initial impression is that WordPress is making a huge mistake. This new editor just being the start, will WordPress make itself so hard to use that everybody moves on to something else? I’ve already got a love/hate relationship with WordPress, and the direction that it’s headed doesn’t seem good at all.

Gutenberg is an abomination to WordPress!

I have thoroughly read over 100 of the 1-star reviews pertaining to this plugin, and I noticed that the Plugin Author’s responses (or Admin’s responses) have basically stated or implied that we (the coders & users) aren’t being clear nor detailed enough with our complaints. Well, if you have a good attention span, then I have taken my time out to list the slew of flaws associated with this plugin.

BELOW is a list of bullet-points. Each bullet-point represents a complaint and/or issue with the plugin.


#1: The “Settings” panel on the right-hand side is very slow and buggy. For example, every time I edit a post, ALL of the tabs are ALWAYS collapsed, so I have to expand the tabs every time I edit a post. It is unnecessary and time-consuming!

#2: There is no option to drag the post-type $support tabs (i.e “Revisions”, “Categories”, “Tags”, “Excerpt”, “Comments”, etc.) across the post editor screen. For instance, I like to keep “Discussion” & “Comments” BELOW the content-edit area the_content(), but with Gutenberg that customization has now vanished!

#3: Speaking of the “Comments” tab, that is missing. Where are the comments?! With Gutenberg, I do have the option to enable & disable comments under the “Discussion” tab, but the “Comments” tab (showing the 20 most recent comments) has disappeared!

#4: The “Trackbacks” & “Ping-backs” are missing completely as well. Nowhere to be found on the post editor screen!
(UPDATE #3: “Trackbacks” & “Ping-backs” are showing up under the “Discussion” tab after the plugin was reinstalled. However, the other issues still exist.)

#5: The “Categories” tab is simply not working for me, so I am not able to choose a category for any of my posts. For instance, when I click on the “Categories” tab, the content will expand from the tab, but without any categories to choose from — It’s just a blank white screen. Where are my categories?!
(UPDATE #3: The “Categories” content is showing up after the plugin was reinstalled. However, the other issues still exist.)

#6: I have two custom Taxonomies for customization purposes, and neither one of those two Taxonomies are showing up anywhere on the post editor screen. Where are my two custom Taxonomies?!

#7: Every time the “Tags” tab is expanded, it takes a second or two for all the chosen tags to display. Sometimes, the tags won’t display until I click on the content box that stores the tags. This is very annoying! I guess I should be fortunate the tags are at least showing up, unlike my missing custom taxonomies!

#8: The “Content” edit area the_content() it terrible. For instance, It’s only about 600px in width, and there is no option to expand the width of the “Content” edit area ―― it should behave like a textarea HTML element, but it doesn’t.

#9: In order to switch between “Visual Editor” & “Code Editor”, I have to click the 3-dotted button in the upper right-hand corner, then choose “Visual Editor” or “Code Editor”. This is yet again unnecessary and time-consuming.

#10: I have another plugin which allows me to switch “Post Types” (not Post Formats) within the post editor screen, but that option has completely disappeared!

#11: Under the “Status & Visibility” tab, it provides me with the option to choose between 3 different Post Formats, but I don’t have Post Formats supported for any of my themes (via functions.php file) ―― I create my own themes.
**literally shaking my head at this point**

#12: When I switch from the “Visual Editor” to “Code Editor,” I get the following coding in a lot of the HTML DIV elements. The coding I get is related to CSS Bootstrap. However, I despise Bootstrap, and I purposely avoid plugins that have Bootstrap, because it interferes with my CSS coding. I have my own, personal-made CSS library for columns & grids, and I make my own accordians, tabs, etc with my own HTML, CSS & JavaScript, so Bootstrap is essentially useless for me and it conflicts with my coding.

Example of coding that Gutenberg adds:
div class=”col-md-9 col-sm-10 col-xs-8″

#13: The “Custom Fields” tab is gone! What is the purpose of this? Custom Fields are crucial for many of my Post Types & Metadata.

#14: The “Permalink” isn’t displaying. I tried right-clicking & clicking on different options, but I can’t find a way to edit the permalink. Is this intentional?

#15: The “Slug” isn’t displaying. This is the same issue as #14 above. How come the slug isn’t available to edit?

#16: The “Add Media” Quicktag is all the way at the bottom of the content-area the_content(), and Gutenberg doesn’t provide the option to adjust the content-area’s HEIGHT. Thus, if there is a long post, the person adding media content to the post has to scroll all the way to the bottom of the content-area. Yet again, this is not time-efficient. It’s another inconvenience!

#17: When in “Visual Editor” mode, there aren’t as many Quicktags options to choose from. This is another example of Gutenberg eliminating and omitting options that are present in the current WordPress post editor.


That fact that Gutenberg is in the plans of becoming part of the WordPress core makes absolutely irate ―― particularly because I have spent a long time customizing my post editor screen with API/Actions & API/Filters — i.e. functions remove_post_type_support() , add_post_type_support() , wp_editor() , and so on.

I am aware that there is the Classic Editor plugin, but that’s not fair to us users & coders. Gutenberg should remain an optional plugin. My gut is telling me that if Gutenberg becomes part of the WordPress core, and people like myself have to use the Classic Editor plugin, then there are going to be compatibility/coding-conflict issues. As far as functionality and appearance, is the Classic Editor plugin EXACTLY the same as the current WordPress post editor? Will API/Actions & API/Filters work with the Classic Editor plugin the same way these APIs work with the current WordPress post editor?

The future

Gutenberg is a bold leap in the right direction. It may appear limited at the moment but the new interface standard will make for a much better and more consistent overall user experience and the new data model will allow developers to build amazing things.

From what I have read and heard, Gutenberg is being built with flexibility and extensibility in mind, this is not a capricious move.

Yes, some things may break along the way but we have some very interesting times ahead of us in which the Themes and Plugin echosystem is going to change dramatically .

I am specially looking forward to its integration with the Customiser, which is truly going to push WordPress 1o years into the future.

Thankyou and Keep up te good work!

Great future with Gutenberg

I have to say that I’m looking forward to have a brand new user experience with Gutenberg. I already have two sites in production with Gutenberg and custom blocks. I’m big fan of React.js and WordPress and with Gutenberg I can build great user interfaces for page and custom post types editor. Cool and keep going! On the other hand I have to say that Gutenberg API is not stable, but hey, it’s not intended for production use at the moment, so it’s ok 🙂

Some suggestions

You are adding visual interface to the editor but they are in different places, it should be a bit handy. Maybe a drop-down above the editor.
While it’s good that you have added the visual part but it would be better if it can be a third tab in addition to the current two.
I would also request you to make the border more prominent, I keep low brightness and contrast to reduce strain on my eyes and I was not able to distinguish the border.

Read all 511 reviews

Contributors & Developers

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


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

Traducí “Gutenberg” a tu idioma.

¿Interesado en el desarrollo?

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



  • Implement Tips Interface to guide a user in the new editor interface.
  • New design version of sibling inserter (the ability to insert blocks between other blocks).
  • Allow users to re-enable Tips.
  • Allow the user to preview changes to a published post without first updating the post.
  • Show the preview mode for HTML blocks converted into shared blocks. This streamlines the process of creating straightforward HTML blocks and letting users insert them visually.
  • Exclude the currently focused block from the block completer options. (i.e. don’t show paragraph as an option if already on a paragraph)
  • Trigger autosave as standard save for draft by current user.
  • Add mime type checking to the pre-upload error messaging system when uploading media.
  • Allow block hover outlines to draw color from admin theme.
  • Allow transforming multiple paragraph blocks into a single quote block.
  • Block API: move useOnce block configuration to supports.multiple = false.
  • Add strikethrough support for Markdown conversion when pasting.
  • Add yAxis=middle support to Popover to allow showing arrows vertically centered for NUX tips.
  • Add BlockIconWithColors component and use it for the block header with description in the inspector.
  • Add error notices mechanism directly to media placeholder.
  • Refactor the initialization of the editor to only require a post ID.
  • Optimize the default column width for character length and use the same width for the text editor.
  • Incremental improvements and polish to the mobile block toolbar.
  • Visually compensate nested blocks for block padding.
  • Prevent slash autocompleter from letting users insert two cases of a useOnce block.
  • Let screen readers announce the block aria label.
  • Improve the accessibility of featured images.
  • Make aria-multiline true by default in RichText so the content field is properly announced.
  • Add back role textbox to the List block and improve aria-multiline usage.
  • Replace the renderBlockMenu prop with Slot/Fill.
  • Hide disabled blocks from shortcut inserter.
  • Avoid deprecated React Lifecycle hooks in withAPIData.
  • Improve the element serializer to avoid double ampersand encoding of valid character references.
  • Update drop-cap design to better balance line length.
  • Describe expanded state of “more options” panel.
  • Improve DotTip positioning fix.
  • Implement Button component as assigning ref via forwardRef (new React API).
  • Improve serialising JSON to PHP-compatible query strings.
  • Introduce rendererPathWithAttributes() for ServerSideRender.
  • Refactor the getPostEdits selector to avoid relying on Lodash’s _.get.
  • Refactor withSelect to use getDerivedStateFromProps.
  • Replace JSON-escaped quotation mark with unicode escape sequence in Block API. Fixes PlainText component not properly escaping attributes under some specific user roles.
  • Fix regression in Columns block’s front-end style.
  • Fix regression in SVG support for block icons.
  • Fix PHP 5.2 notice by ensuring $memo is always an array.
  • Fix margins of embed block content.
  • Fix autocomplete behaviour in IE11.
  • Fix regression with formatting toolbar not showing divider between some block controls.
  • Fix issue where pasting an inline shortcode would produce a separate shortcode block.
  • Fix issue when copy pasting images in Chrome.
  • Fix typos in code comments.
  • Fix consistency of hover styles in toolbars.
  • Fix option for linking to attachment page on gallery block.
  • Fix Classic Editor adding paragraphs from block boundaries.
  • Fix post publish panel showing incorrect UX for contributors who don’t have publishing capability.
  • Fix issues with floats and the side UI on wide and full-wide.
  • Fix issue where server side upload errors disappear automatically.
  • Fix block inserter popover in RTL mode.
  • Fix mp3 uploads on chrome.
  • Fix getMimeTypesArray return documentation.
  • Avoid showing error if autosave runs and there are no changes to save.
  • Prevent any disabled button from changing the cursor to pointer.
  • Remove ‘who’=>’authors’ compatibility shim as it’s part of WP 4.9.6.
  • Remove confusing “wrap text” from Button settings.
  • Remove the usage of the componentWillMount lifecycle.
  • Remove the componentWillReceiveProps lifecycle usage.
  • Remove createInnerBlockList utility / context. This should be a simplification of block context, potentially with some performance and/or memory improvements, as an intermediary component is no longer created.
  • Improve translatable strings containing “%s” to have a translator comment.
  • Move trash post URL change to the BrowserUrl component. Consolidates all browser navigation (url changes and actual navigation).
  • Simplify the withColors HOC so we can avoid the usage of memoize while still having a correct implementation without unnecessary rerenders.
  • Refactor Higher-order components in data module to avoid the use of componentWillMount.
  • Use mdash for block description in cover image.
  • Ensure that only the latest promise updates the autocompleter state for more predictable behaviour.
  • Wrap PluginPostStatusInfo with PanelRow rather than Slot. Fix issue with hard to style divs.
  • Update demo content to avoid dirtying embed.
  • Allow using ServerSideRender component without defined attributes.
  • Avoid loading Gutenberg assets in other admin pages.
  • Add a new @wordpress/api-request package. Instead of relying on globals to set the nonce/rootURL, it users configurable middlewares. Preloading support is also built as a middleware.
  • Move the Core Data Module to packages.
  • Move Plugins module to packages.
  • Rename all the hooks moved from blocks to editor.
  • Add NUX e2e tests.
  • Add e2e tests for Plugins API.
  • Add es5 samples to edit-post and plugins.
  • Add e2e test to blocks.BlockEdit filter.
  • Add snapshot test for MoreMenu component.
  • Fix broken links in readme files.
  • Build tooling: add linting for package.json files.
  • Further explanation for why .normalize() is optional in raw-handling.
  • Update icon color readme example.
  • Generate docs for the data module.
  • Enable Strict-Mode of React.
  • Publish new versions of WP packages.
  • Regenerate integrity checks to sha512.
  • Drop deprecations slated for 3.1 removal.
  • Upgrade React 16.3.2 to React 16.4.1.