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?

Vi vil elske at høre på jeres fejlrapporter, funktionsønsker al anden feedback! Fortsæt venligst over til GitHub problemside og søg blandt eksisterende problemer eller opret en ny melding. Selvom vi forsøger videresende problemer rapporteret her på pluginforum’et, så vil du få meget hurtigere respons på (og reducere dobbeltarbejde) ved at holde det hele centraliseret på GitHub repository.

Hvordan kan jeg bidrage?

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?


Please, kill your darlings.

The future of WordPress is doomed with this plugin.

Really, why force a block-builder-like editor – when every single developer in the world hates it?

The first thing I (and many other serious developers) do when encountering a clients site with a block-builder-theme, is requesting to take me of the job;

I don’t do block-builder sites, I don’t work with block-builders, I do not repair, fix or develop those pieces of junk.

In my opinion, there are two types of website (and thus developers);

1). Those who develop a site
2). Those who use block-builders

When the future of WordPress is in the block-builder-editor, than WordPress is not my future as a serious, professional developer.


The new so called interface is very cumbersome and a step BACK from what we had.
It is def not even close to WYSIWYG…. when one publishes the new page. Pfff
If the final release can postponed till the year 2318 than that would be much appreciated.

Bad UX design

This is worse then I thought. I understand that people need to get use to new design and new features, but this just seems so hard that its not worth to learn.

  • pasting text ( even with right click -> paste as plain text) to a list element is impossible
  • pasting text from a word ( or any other document) is way to hard. You need to understand that many people write their content in word or docs ( and sharethem with others, correct them,..) and only then they past it to WP. With gutemberg this just became super hard
  • options are very unintuitive. Everything is displaced on all sides and there seems to have to many options but when you try to do something you realize you actually have very limited options per specific block

Gutemberg just seems way off the standard editor and its so different that its just to hard to get use to.
This project looks like it was done by someone who doesnt write much text or is writing just for debbuging. Its to complicated for posts and lacking major functons to be a page builder.
As I said before, most people I know write their content somewhere else, then they paste it to WP and there they only want to adjust some smaller details ( like headings,etc.). I suggest you create a demo blog and paste there 20-30 posts, measure time it takes you to do that with old editor and with gutemberg.

Very bad

With Gutenberg writing content is harder (more complicated and time consuming) and making a mess is easier. If it becomes the default editor anyone can make a beautiful and well designed site look ugly by adding a huge text block on a bright orange background or something like that.

Some potential – Reporting a UI/UX issue with shortcodes and AMP video codes

We’ve had issues with the current/legacy visual WordPress editor removing metadata and AMP video codes upon saving or updating a post in visual editing mode. Optimistically, this issue does not seem to be occurring with Gutenberg.

One UI/UX problem we are seeing, is that we are inserting videos into our posts, and we need to insert the code twice, once for standard HTML, as a shortcode, and right underneath that, as a separate AMP video code snippet for AMP pages. We tested it using the built-in Gutenberg shortcode block and it almost worked. Upon saving the shortcode in visual mode, we could see it, but the Code Editor view just showed an empty wp-shortcode bracket. It was saved, but not rendered. We logged out and came back in, and could see the shortcode on both editors. Mystery.

Another issue is the AMP code, which we insert via the Code Editor as a wp-paragraph. We can see the contents in the Code Editor, but when switching to the Visual Editor, it shows an empty paragraph with no content in it, which is very misleading. Can we show something in the Visual Editor for post editors to know that this paragraph contains content?

Attaching 2 screenshots:

Too complicated

I’m a web developer. My clients are mostly not tech-savvy and use their sites to publish statutory information as part of their work. I had a look at Gutenberg and feel it is totally unsuitable for my clients.
Gutenberg should not be imposed on all WordPress users, but instead released as a plugin for those that want it.
A few observations:
1. Please don’t insist that each paragraph be in a separate ‘block’. Maybe the first block could be a multi-functional block similar to the current editing screen (that would allow lots of paragraphs, heading types, bullets etc) and then if users wanted they could add extra blocks. These extra blocks could provide more complex features such as columns or galleries.
2. I use ‘Screen Options’ to set up all my client sites with a simplified interface consisting only of the Title, Content and Publish metaboxes. I cannot see a way to do this in Gutenberg.
3. The ‘Publish’ button has been renamed ‘Schedule’. This is will be really confusing for my users (as it was for me).
4. I tried to set up a Gallery block and add some photos, but got a JSON error. I’m using Firefox as a browser.
The imposition of Gutenberg would create a lot of extra work for me as I would need to disable it on all my client sites or spend a lot of additional time supporting it. It’s making me question whether I can continue to use WordPress.

Read all 1.047 reviews

Contributors & Developers

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


“Gutenberg” er blevet oversat til 35 lokalområder. Thank you to the translators for their contributions.

Translate “Gutenberg” into your language.

Interested in development?

Gennemse koden, tjek SVN repository, eller abonner på udviklerloggen via RSS.



  • Restore min-width to popover.
  • Fix wide toolbar regression
  • Add e2e test for publishing a page
  • Fix typo for removing excerpt block stripping


  • 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.