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?


Gutenberg is great!

I find that most of the negative reviews on here are from people who are unwilling to learn new technology. It’s sad to see them flame the app when it’s really a great step in the right direction. Gutenberg is snappy, simple to create new content and fun to create templates for my clients to consume. The asynchronous behavior of node will be perfect for a page building app. Bravo to the people involved, I’m excited to see what’s in store for the future of Gutenberg.

Reducing trust

I’ve tried Gutenberg and agree with the other 1 star reviews.

I could go into what I don’t like about the plugin technically but it has all been said by others.

What concerns me is the way this plugin is being forced onto WP, as well as the lack of clarity around how and when.

These are my concerns:

1) I know that I will NOT use Gutenberg when it is forced into WP 5x. Yet I do not know when 5.x will be distributed. So I wait with trepidation each week wondering when that may happen. I will have to change over dozens of sites away from Gutenberg once it is forced onto WP. I do not know if this forced update will break some of my sites and in which way.

I really really do not appreciate being put in this position by the devs.

2) The devs say “Oh but you can just use the Classic editor plugin, preemptively”. This gives me the impression if I install the Classic editor plugin now, then when WP is updated, Gutenberg will automatically not be activated. Yet last time I checked, the plugin clearly says it is in beta and should not be used in production sites.

So the devs are telling people something which is not practical.

3) I use different custom field plugins for various sites and I have read in numerous locations, concerns about compatibility.

The devs say “oh yeah we are working on compatibility” – ok, but with ALL custom field plugins?

So I am also being put in the position of having to worry if some of my sites will be broken when Gutenberg is forced onto WP.

4) When I read the responses of the devs to these 1 star reviews I see a lot of “Thank you for your review”, “What do you like about the plugin”, ie in my opinion the responses do not seriously consider the 1 star feedback.

5) The above 4 points give me the impression that the plan is to force Gutenberg when ever, in whatever state, with whatever negative effects on other plugins, and who cares if the majority of reviewers don’t like it.

6) The above 5 points have really given me a strong feeling of disappointment and reduced trust in WP team, and hence using WP in future.


The current editor is good, stays good for foreseeable future.
This unnecessary breaking change is not welcomed.

Not to pile on, but this is not a step forward

The last target release date I heard for Gutenberg was “April 2018” — so, as little as one and no more than 5 weeks from now. Really???? I know lots of people probably are burning a ton of hours trying to make Gutenberg at least marginally viable so it can be pushed out the door and the team can declare Phase 1 victory. I do not make these comments to disrespect the efforts of the individual contributors, who are not to blame for this hideously unintuitive thing. It’s impossible to offer truly constructive criticism about this tool. It is so far away from something that I would ever imagine wanting to use that I simply wouldn’t know where to start. That the leadership at the top of this project apparently doesn’t recognize this makes me truly fear for the future of WordPress. My advice: try to learn from what you’ve done so far, but SCRAP this thing and start over with a blank slate. And bring some people on board who have a real clue about what an intuitive UI looks like.

Gutenberg is Terrible

What is this crap? Honest to God, it is AWFUL! I just installed it on a sandbox site to experiment and I am extremely disappointed. I want to be able to code as I have for years, and would even prefer to continue using TinyMCE Advanced than being forced into this.

I (among many others) have a valid concern that rolling this out will negatively impact existing sites that we build for our clients. I did select Quick Edit and chose the option to use the Classic Editor. I sure as hell hope that this remains an option when Garbageberg is unleashed upon us. I will have to research other site building options in the event that this sucks as bad as it appears on the surface.

Read all 401 reviews

Contributors & Developers

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


“Gutenberg” has been translated into 26 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.



  • Show the full block inserter (+ button) to the left of empty paragraphs and the default appender. Quick block options (based on compound frequency and recency) remain on the right.
  • Insert default block as provisional — this reduces the proliferation of empty blocks as the editor removes these provisional blocks when unfocusing.
  • When pressing enter from post title, insert initial block as provisional.
  • Fade out the side inserter when typing on the newly created block.
  • Group common block definition on inserters. Use ‘frecency’ to sort items on top of it.
  • Improve the visual focus style for inbetween inserter.
  • Move isTyping behaviour to a separate component.
  • Inserting a block should only shift focus to a text field, otherwise focusing the block’s “focus stop”.
  • Example: Inserting an image should focus the top-level placeholder.
  • Pressing backspace or enter from the block’s focus stop should respectively delete or insert a subsequent paragraph block.
  • Example: Pressing enter or delete on an image placeholder.
  • Pressing down arrow from a non-text-field should proceed with a tab transition as expected.
  • Multi-selection at the last text field in a block now accounts for non-contenteditable text fields.
  • Better internal identification of text fields for writing flow transitions. Previously, if a block contained a checkbox, radio, or other non-text input tags, they would be erroneously included in the writing flow sequence.
  • Inserting paragraph block (quote, etc; those with text fields) via autocomplete should move focus to the cursor.
  • Shift-arrow from a text field engages multi-selection, but not if there are other text fields in the intended direction in the same block.
  • Cancel isTyping state when focusing non text field.
  • Improve reliability of the block click-to-clear behavior.
  • When clicking below the editor move focus to last text field — this includes creating a new provisional block if last block is not text. This is equivalent to the default block appender spanning the entire viewport height of the editable canvas.
  • Introduce same undo buffering for general text to the post title (and other post properties).
  • Allow breaking out of List block upon Enter on last empty line.
  • Address conflicts between WritingFlow’s selection transitioning and nested blocks by moving selection to the block’s focus handler.
  • Improve reusable block creation flow by focusing the title field and allowing the user to name their block immediately.
  • Avoid calling callbacks on DropZone component if a file is dropped on another dropzone.
  • Improve settings UI on mobile devices.
  • Allow text to wrap within Button block.
  • Restrict Popover focusOnMount to keyboard interaction. This seeks to improve the experience of interacting with popovers and popover menus based on usability and accessibility concerns.
  • Optimize the behavior of subscribe to avoid calling a listener except in the case that state has in-fact changed.
  • Move the behaviors to transition focus to a newly selected block from the WritingFlow component to the BlockListBlock component.
  • Extract scroll preservation from BlockList as non-visual component
  • Add Upload button to audio and video blocks.
  • Refactor image uploads and added auto-filled captions using the image metadata.
  • Limit CSS rules for lists to the visual editor area.
  • Add aria-label to the post title.
  • Add new distinctive icon for Cover Image block.
  • Refactor PostTitle for easier select, deselect.
  • Use ifViewportMatches HoC to render BlockMobileToolbar as appropriate.
  • Introduce a new reusable Disabled component which intends to manage all field disabling automatically.
  • Expand editor canvas as flex region improving deselect behaviour.
  • Bump minimum font-size to 13px.
  • Allow emojis to be displayed in permalink visual component.
  • Respect HTML when readding paragraph-tags.
  • Allow undefined return from withSelect mapSelectToProps.
  • Update datepicker styling to inherit font-family/colour scheme.
  • Move QueryControls and expose them for general use under components module.
  • Address design issues with block dialog warnings on blocks that are too tall.
  • Preserve “More” order during block conversion.
  • Add capabilities handling for reusable blocks mapping to default roles.
  • Add a “Write your story” filter.
  • Return focus from Toolbar to selection when escape is pressed.
  • Improve keyboard interaction on inserter tab panels.
  • Simplify state management for the sidebar to make it easier to maintain.
  • Update cover image markup and CSS.
  • Fix sent parameter in onChange function of CheckboxControl.
  • Fix errors in some localized strings.
  • Fix problem with arrow navigation within Block Menu buttons.
  • Fix issue with demo page being marked immediately as unsaved (and the subsequent autosave).
  • Fix issue with a Reusable Blocks being keyboard navigable even when it is not supposed to be edited.
  • Fix focusable matching elements with “contenteditable=false”.
  • Fix issue with empty paragraphs appearing after images when the images are inside an anchor.
  • Fix issue when a block cannot be removed after being transformed into another block type.
  • Fix issue with updating the author on published posts.
  • Fix edgecases in Windows high contrast mode.
  • Fix regression with inserter tabs colors.
  • Fix handling of HTML captions on gallery and image.
  • Fix heading subscript regression.
  • Resolve a performance regression caused by a bailout condition in our chosen shallow-equality library.
  • Handle calculateFrequency edge case on upgrading.
  • Use lodash includes in NavigableMenu to address IE11 issue.
  • Refer to reusable blocks as ‘Shared Blocks’.
  • Add domain argument to localization functions. Allow setting locale data by domain.
  • Update localization functions to absorb errors from Jed.
  • Make UrlInput a controlled component.
  • Decode HTML entities in placeholders.
  • Only allow whitespace around URL when attempting to transform pasted Embeds.
  • Make preferences reducer deterministic.
  • Remove max-width for meta boxes area inputs.
  • Default to content-box box-sizing for the metabox area.
  • Adjust inside padding of meta boxes to better accommodate plugins.
  • Remove !important clauses from button styles.
  • Keep update button enabled when there are metaboxes present.
  • Clarify some inner workings of Block API functionality with comments.
  • Rewrite data document as a walkthrough of wordpress/data.
  • Revert the eslint –fix Git precommit hook.
  • Extract shared eslint config.
  • Add tests for the BlockSwitcher component.
  • Add test cases for REQUEST_POST_UPDATE_FAILURE effect.
  • Fail the build via ESLint error when deprecations marked for removal in a given version change are not removed.
  • Update redux-optmist to 1.0.0.
  • Update package-lock.json.
  • Remove Deprecated Features planned for this release and start documenting them in a deprecated document.