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 in the core, please

Gutenberg already caused me an headache and a couple of days of time wasted. It will break some plugins I have paid for, and if you put it into the core you will force many people to change their websites hardly.

The classic-editor plugin is absolutely a non-sense. You will put out a plugin to fix the problems you’re going to cause to thousand of websites. Why don’t just let Gutenberg be a plugin, and don’t break wordpress core with something almost useless?
I don’t see the reason why you want to make WordPress something stupid like Wix.

If I have to spend days and money to re-build my website, I sill most probably change CMS entirely.

WP Team Violates Important Principles

I Prefer A Guten-Free Diet …

FIRST, I wish I could upvote other Reviews. I would upvote a LOT of the 1-stars. They have been VERY informative and confirmed some of my less educated suspicions and experiences with the new WP editor.

My Basic Thoughts about it all — WP Gutenberg, that is — are from the world of Internet Marketing & User Experience:

1. One of the principles of marketing is to make a REALLY big difference, you have to be willing to say the same old thing, over and over again, what feels like FOREVER, until YOU are bored stiff with it.

Maybe the WP Team is getting bored with the Classic WP Editor?

Too many marketers get bored with their message JUST about the time it starts to take hold in the marketplace, in the minds of the target market. JUST when they’re about to hit critical mass (say, 25% of website creators), they say, “Let’s modernize our marketing!” “Let’s change our logo.” or “Let’s <whatever>.” … And then, they LOSE their momentum because they changed their primary message or visuals JUST when it was starting to resonate with the mass market. …

And with ALL those FREE videos out there by independent creators showing how to set up and be running & blogging with WordPress in FIVE minutes or less! Talk about a Great Message! Self-Publish your stuff with a 5-minute setup (and a few dollars a month for hosting) and VERY easy usage!

Yet a Pro-Guten Diet person implied the Classic WP Editor was too difficult for too many people! Really? For WHO? With ALL those people writing their VERY first blog post after only a FIVE MINUTE install process? Something not much more difficult than operating Microsoft Word? Is it really THAT big of a challenge?

The WP Team might be doing the SAME counterproductive thing. JUST when the mass market is starting to catch on, JUST when the momentum is about to hit high gear, and JUST when all of us “lower tech” people can publish our thoughts at will with almost NO resistance, WP is now changing the game? And throwing its momentum off in a — potentially — wrong direction?

Maybe because the WP Team has gotten too bored with their own creation? And they are projecting their boredom out onto us WP Users who just want to type our words, maybe press the Add Media button a few times, and press Publish? Oh, and maybe make Yoasts little light turn green? All with very little resistance or even effort?

2. Another principle from marketing & user interface guidelines (and the name of a book from a few years ago) is “Don’t Make Me Think!” The idea is to make the technology as invisible as possible so the creative & innovative process is NOT interfered with any more than necessary. …

(Like when some “Creative Genius” decided to get rid of blue-underlining for links, and now we all have to drag our cursors all over the screen to find whether anything is clickable or not. That STILL bugs me to this day. Almost as much as these “Parallax” pages bug me. Call me primitive, but to ME, they are nothing but an irritating distraction.)

So when I went into the new WP Gutenberg system, I could NOT make it do basic things I usually do without ANY effort at all in the Classic WP Editor. (Or even in TextEdit on my Mac!) I got hung up RIGHT at the beginning of trying to write a new post. … I was staring at the screen, then clicking around, looking for ways to do stuff that took NO thinking at all to accomplish with the Classic WP Editor. And I’m no dope (I hope), and the guy many of my friends look to to help solve their problems on Macs and WordPress.

(I think it was formatting the Title block of the page that hung me up IMMEDIATELY. I have a particular style I use in all my posts and articles, and could not for the life of me figure out how to apply ANY custom formatting, let alone my preferred style.) …

And it looked like there was WAY too much space between everything. And it looked like I could not embed images where I wanted them, either. (Someone suggested that using the right THEME would solve the spacing issue. REALLY? I have to switch themes to change my margins and spacing?)

SOOO … MAYBE the editing solution is deceptively simple. Or are The Pro-Guten Diet Gurus making me — inadvertently, I assume — think too hard and slowing down my creative process? But I could not find the editing I needed. Maybe I’m just too dumb? Or the editing process is too deceptive?

Is it good for the WP Guten Team to make me feel dumb? Is it good that I have to stare at the screen and guess several times to figure out how to do that which was dead simple on the Classic WP Editor? Will feeling chronically dumb give me IBS (Irritable Bowel Syndrome)? Or wold a Guten-Free Diet help that problem?

Anyway, I guess I’ll be opting for the Classic plugin option, BUT I’ve read in some reviews THAT is really buggy too. And yes, I’ve been experimenting with SiteOrigin and Elementor, and yes, they are block based, but they are page specific and only ON when I want them on.

So this whole Gutenous transition really bothers me. But I realize people like me have very little pull with Team WP because we are not Big Time Web Developers. I just HOPE it’s a lot more user-friendly when it comes out.

But MAYBE you could wait till 6.0?

Gutenberg shows a lot of promise

I installed Gutenberg on my dev installation and updated some of my custom plugins and custom theme to work with the new html output and blocks plugin architecture.

The blocks architecture in particular makes it very easy to write editor experience plugins and provide great extension points, the experience writing custom content types here is much much richer than was realistically possible with the previous editor, overall I’m very excited to see the ecosystem grow up around gutenberg blocks, they are a very powerful way to write extensions and once you get familiar with the concepts and syntax very easy to write.

The entire editing experience however still needs a little more polish to truely get out of the way while actually editing content. For example once in the editor the text can mostly be navigated by cursor and works as expected but my cursor kept getting stuck in a gallery block and I have to resort to the mouse to get out again. The blocks seem a little too keen to announce their presence when just editing. The editor is plain white in its default state but everything has a hover style and even lowly paragraphs feel it necessary to continually announce their presence when mousing around.

A steaming pile of

Gutenberg as it currently stands is a screaming nightmare. After frequently playing around with just about every major release I figured I would try to do some actual work with it now that it is inching toward release.

Using it has been bringing home the many concerns I’ve had with the project from the start. Gutenberg resembles the core team’s full embrace of modern js development practices and in its haste it has set fire to the kind of development experience that has made WordPress a success. That includes easy debugging, being able to play with code and understand things quickly and a low barrier to entry to figure things out.

So here I’m dealing with one of the many bugs that I’ve encountered while actually trying to put publishable content together. Opening up the editor I notice long delays so I open up the network tab in the dev tools. I see an endless stream of duplicate REST API requests firing needlessly. What is a developer to do? Check a stacktrace maybe. Oh right, the scripts are delivered compiled and minified, so debugging is not a big help there. So let’s turn on SCRIPTS_DEBUG to see if we can actually understand the code that is firing. Nope. In all its wisdom Gutenberg developers thought it fine to omit the option to see unminified code in a plugin that they explicitly want people to test. You *&***£$£$£s

I fear it has been completely lost on many core developers that this kind of stuff matters, but it’s not surprising given the way debate was conducted around the choice of frameworks. Making core code approachable to end-users and non-core developers was simply no priority, instead this new approach was all about tending to the comforts of core developers. One of the arguments used was that how core developers decide to work has no impact on outsiders. This is just fundamentally not true. And as a result we’re actually seeing an invisible barrier erecting between core development and users who would otherwise might have ventured into the code. It will even effect basic bug reporting.

Gutenberg can generate errors at any point. It offers and re-offers annoying prompts, like wanting to convert your content back into blocks (but I wrote it in the $$$W£”$” gutenberg editor, you A£”$£”!) It’s clunky to work with and select text. It does not pair up well with actions taken in the customizer. It won’t be able to deliver a seamless experience in which you see what you get.

I’ve noticed it frequently is just sluggish while typing, with noticeable delays. It’s a below average editor for pure writing and an underwhelming editor for composing rich content. The user experience for writing custom html blocks is horrendous an unwieldy. If you want to display code snippets in your post, it’s easier to write the code in a different editor, because it is a pain to format code otherwise.

While Gutenberg is a portable and can work anywhere, it’s not really that portable in practice. The post meta boxes solution looks patched on and inelegant. The revisions tool feels sluggish and unclear (why does it not show which version is live and which is the revision in a way that you can’t possibly confuse the two?).

When attempting to develop for a Gutenberg ready site you’ll find that many hooks present in the old interface have no counterpart, so there’s no actual good practice approach to adding controls that were easy to add in the classic interface.

There are so many things about the interface that just make me go ‘hmm?? what are the consequences of touching that?’. Shared blocks sound awesome, but what is actually happening when I make a block a shared block? Is there a screen that shows all the shared blocks etc? What happens if I choose to edit a block in html mode? Am I stuck now if I have chosen that? Oh wait, if I laboriously reopen the context menu and choose edit visually, it reverts to how it looked before. Great. Too bad everything feels like it’s five clicks and four mouse movements away.

The border outline while hovering over blocks is a constant reminder of how the UI makes you treat everything as unwieldy feeling blobs of content rather than a pleasing stream of text. Don’t get me wrong, I am/was very excited about the concept of blocks, but in practice I want text to behave like text and not be reminded that for every interaction you have block level tools adding noise and friction.

So, in short, it’s unfriendly to non-core developers, it’s a migration nightmare, it’s a below-par editor for pure writing, it’s sluggish in performance, it’s buggy, it has many ambiguous feature implementations, it’s falls short of being a proper page builder. Is there anything I do like? It’s quite easy to add a class to a block and add block level styling that way. It’s nice to have drop cap options, even though the implementation has its faults. But to be frank, there’s precious little to be enthusiastic about right now. I’m not even sure that most of this is fixable. It certainly isn’t ready for prime time.

Read all 547 reviews

Contributors & Developers

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


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



  • Add block styles variations to the Block API.
  • Add support for Inline Images and Inline Blocks API.
  • Convert Columns to a set of parent and child blocks, including a wrapper element and more reliable front-end presentation.
  • Allow registering new block categories.
  • Add support for locking Inner Block areas.
  • Add File Block for uploading and listing documents, with drag and drop support.
  • Introduce Modal component to expand the extensibility suite of UI components.
  • Redesign block transformation menu.
  • Improve style display of region focus areas.
  • Prevent blocks from being draggable if a template lock exists.
  • Parse superfluous classes as custom classes preventing a block being considered invalid for such cases.
  • Support “Autoplay” and “Loop” in Audio Block “Playback Controls”.
  • Always show “new gallery item” below the gallery.
  • When dragging images to create a gallery, immediately show the images while uploading is happening.
  • Optimize withSelect to avoid generating merge props on equal props.
  • Remove the “scroll shadow” at the bottom of the inserter library.
  • Remove the bottom border on the last collapsible panel.
  • Remove wrapping div from paragraph block (in the editor) for performance audit.
  • Add Image Block ‘Link to’ setting.
  • Allow margins to collapse & refactor block toolbar.
  • Keep NUX tips open when the user clicks outside.
  • Add initialTabName prop to Tab Panel component.
  • Add higher order component to constrain Tab keyboard navigation.
  • Display server error message on media upload when one exists.
  • Improve “add block” text in NUX onboarding.
  • Improve experience of using image resize handles — placing them at the middle of the edges instead of the corners.
  • Update color of the Shared panel icon to be the same as all other icons.
  • Verify if block icon background and foreground colors are readable. Warn in the console otherwise.
  • Address various design details on Plugin API icon treatment in header and popover.
  • Include all image sizes on the media upload object when they exist.
  • Move the delete block action to the ellipsis menu for the block. Introduce separator in the menu.
  • Make the inserter results panel focusable and improve accessibility.
  • Improve publish panel accessibility and add new publish landmark region.
  • Open preview to previewLink if not autosaveable.
  • Make sure autocompleted values make it into the block’s saved content.
  • Avoid setAttributes on end-of-paragraph seeking to resolve unnecessary performance degradations.
  • Avoid re-render and subsequent action dispatch by adopting module constant.
  • Avoid focusing link in new NUX tooltip
  • Avoid showing hover effect if the ancestor of a block is multi-selected.
  • Schedule render by store update via setState. Fixes condition where appender would insert two copies of a block.
  • Inner Blocks refactor:
    • Update deprecated componentWillReceiveProps to equivalent componentDidUpdate.
    • Avoid deep equality check on flat allowedBlocks prop shape.
    • Avoid handling unexpected case where UPDATE_BLOCK_LIST_SETTINGS is not passed an id.
    • Avoid creating new references for blockListSettings when settings not set, but the id never existed in state anyways.
    • Avoid switch fallthrough on case where previous updateIsRequired condition would be false, which could have introduced future maintainability issues if additional case statements were added.
    • Add test to verify state reference is not changed when no update is needed.
    • Consistently name allowedBlocks (previously also referred to as supportedBlocks).
  • Consider horizontal handled by stopPropagation in RichText. Fixes edge case with inline boundaries at the end of lines. With further improvements.
  • Ensure ellipsis icon button is visible when block settings menu is open.
  • Simplify RichText to have a single function for setting content vs. the current updateContent and setContent, by removing updateContent.
  • Optimize RichText by removing the creation of undo levels at split and merge steps.
  • Simplify the RichText component’s getContent function to remove a call to TinyMCE’s isEmpty function, which incurs a DOM walk to determine emptiness.
  • Optimize the RichText component to avoid needing to keep a focusPosition state.
  • Reenable pointer events on insertion point hover for Firefox.
  • Introduce colors slugs in color palette definitions to ensure localization.
  • Respect inner blocks locking when displaying default block appender.
  • Use color styles on the editor even if the classes were not set.
  • Move “opinionated” Gutenberg block styles to theme.scss.
  • Don’t allow negative values in image dimensions.
  • Fix IE11 formatting toolbar visibility.
  • Fix issues with gallery block in IE11.
  • Fix import statement for InnerBlocks.
  • Fix broken links in documentation.
  • Fix text wrapping issues in Firefox.
  • Fix showing the permalink edit box on the title element.
  • Fix focus logic error in Tips and tidy up docs.
  • Fix instance of keycode package import.
  • Fix case where an explicit string value assigned as an attribute would be wrongly interpreted as false when assigned as a boolean attribute type in the parser.
  • Fix the data module docs by moving them to the root level of the handbook.
  • Fix specificity issue with button group selector.
  • Fix CSS property serialization.
  • Fix left / right alignments of blocks.
  • Fix CSS vendor-prefixed property serialization.
  • Fix arrows navigation in the block more options menu.
  • Let ⌘A’s select all blocks again.
  • Check for forwardedRef in withGlobalEvents.
  • Address issues with left / right align improvements in RTL.
  • Different approach for fixing sibling inserter in Firefox.
  • Correctly handle case where ‘post-thumbnails’ is array of post types.
  • Remove blocks/index.native as the default is compatible with React Native app.
  • Allow editor color palette to be empty.
  • Support setup with single array argument in Color Palette registration.
  • Only save metaboxes when it’s not an autosave.
  • Force the display of hidden meta boxes.
  • Implement core style of including revisions data on Post response.
  • Remove post type ‘viewable’ compatibility shim.
  • Remove unused block-transformations component.
  • Use withSafeTimeout in NUX tips to handle cases where plugins modify the $post global.
  • Update HOCs to use createHigherOrderComponent.
  • Deprecate property source in Block API.
  • Documentation: fix rich-text markdown source.
  • Tweak release docs and improve release build script.
  • Add focusOnMount change to deprecations.
  • Add e2e test for sidebar behaviours on mobile and desktop.
  • Add e2e test for PluginPostStatusInfo.
  • Add snapshot update script.
  • Update import from @wordpress/deprecated.
  • Extract “keycodes” into its own package and rework the Readme file.
  • Add shortcode package instead of global.
  • Add package: @wordpress/babel-plugin-import-jsx-pragma.
  • Update nested templates to new columns format.
  • Generate the manifest dynamically to include the data module docs in the handbook.
  • Expose the grammar parser to the mobile app.
  • Drop the .js extension from @wordpress/element’s package.json entry-point so when used in the mobile RN app the correct module (index.native.js) can be resolved by Metro.
  • Add packages Readme files to the handbook.
  • Add link in documentation to supported browsers.
  • Add initial document on copy guidelines.
  • Add missing documentation for InnerBlocks props.
  • Regenerate package-lock.json to address unintentional changes.
  • Use cross-env for plugin build scripts to address issues on Windows machines.
  • Invert JSX pragma application condition.
  • Ignore non-JS file events in packages.
  • Drop deprecations slated for 3.2 removal.
  • Publish multiple new versions of packages.