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:

The block unifies multiple interfaces. If we add that on top of the existing interface, it would add complexity, as opposed to remove it.

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.

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.

Considering the whole interface lays a solid foundation for the next focus, full site customization.

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

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.

Compatibility

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.

Contributors

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

FAQ

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.

Reviews

Well, I won’t be needing a crystal ball to see that 2018 will be the year of WordPress problems. There hasn’t been any evidence why this couldn’t continue as a plugin until it’s polished and free of problems. I won’t be updating to 5.0 if this comes along. What I’ll do after that will need some serious thought.

This is the part of WordPress that I dislike. These megalomanic delusions of grandeur which makes them think that they can shove down our throats anything they please, cause they are too big to fail.

The idea of the plugin is great but yet it can only be considered as another page builder (and even not a good one). The way it drops compatibility to existing plugins, metaboxes, existing themes and sites is terrible. It should not become a core feature in WP 5.0 and it should not be rushed.

Do not force the web-designers and web-developers into the situation requiring to update (or redoing) existing sites and requiring to explain this to customers only because the update notification pops up. Customers would not understand what this ”For developers: huge upgrade, require to modify everything and need the time to do so / For customers: Just do this update. We have a maintenance contract with you” situation is and they would require time to understand and they would need to also collect the budget/money for this change.

As for now, the plugin is in a such alpha state that preparing the customers for this change does not make any sense yet since it isn’t clear at all, how the transition could be done and where to go (e.g. of things unclear: Gutenberg adaptations to existing plugins / Plugins update to be compatible with Gutenberg / Content conversion requirements / Block creation efforts of extra features actually delivered by plugins such as ACF / integration in highly customised templates and themes not using the standard post types, content section, … at all).

Most of plugin that I developed are not working and will need reworking.

We usually develop custom type that uses description section to get detailed information on particular post. We have been using wordpress because it made every thing easier as shown on the image link below. (NOTE I am using WooCommerce for example)

https://imgur.com/AO0eBN3

The page looks very different after installing Gutenberg as shown below.

https://imgur.com/ZFWES0r

This is very confusing because we do not intend to submit a post but we are only adding product description. The Classic Editor had advantage of Keeping It Simple and Smart(KISS).

Gutenberg should only be used on adding blog post and should not replace every area custom types are used. There should be an option to choose whether to use Gutenberg or not when developing custom types.

Example: We have customs type for Job, Faqs and Testimonials. Why would I need Gutenberg when posting? The post description is usually one paragraph or two and does not require column,blocks etc.

Suggestion: Let use use Gutenberg on submitting post, but on custom types let us allow the use of classic editor where it is needed.

i can’t speak english well. please understand me^^ i used a translator so many times.

its simple design is good. but it is so Uncomfortable to use it. for example, when i upload many photos, i can’t move its arrangement. even i can’t do ‘ctrl x / ctrl c / ctrl v’ to photos. and it is not intuitive. some options are on block and some options are on the right part. so i feel confused little. i thought there is no font size option. and there is no full-text option. i have to set my posts block by block.

i think if there is a customization like tinymce(there are many icons and features but i can use and set it free. i can use only what i want to use.), then it will be good. for example, if it can be set that some options are on block, some options are on the right part, then it will be both simple and professional. and i think it needs a full-text option. when i use gutenberg, i have to set block by block. it is sooooo uncomfortable. and it needs to be more free. i think it is so Rigid plugin. its block system needs to be free.

when i first see it, i feel so excited to it(until i use it in real). i think gutenberg can be future of wordpress. i wrote criticism much, but, frankly speaking, it is already innovative plugin. there are many good and amazing features too. i want to feel excited again.

Interested in development?

Changelog

2.2.0

Block Nesting is live! It comes with an experimental Columns block. (Note: converting a nested block into a reusable block is disabled on this first version.) Furthermore, this is not a specific implementation for columns alone — any block author can take advantage of defining nested areas.

Refined block insertion experience:

Introduce block shortcuts on every empty paragraph block. This also temporarily disables the sibling inserter as we work on refining this interaction.

Add trailing text area at the bottom of a post to continue writing.

Preview saved blocks while hovering on the inserter. Allows users to quickly see what they are inserting before inserting.

Enable triggering onChange events within RichText component on every keystroke. This was an enforced limitation that prevented saved post checks from being faithful.

Rework undo levels to use history “buffer” and leverage the mechanism to aid in continuous syncing of RichText history records.

Collapse the publish sidebar when making edits to a published post automatically.

Improve writing flow by triggering isTyping mode as soon as the user clicks on the default text appender.

Hide hover effects when typing.

Add a confirmation message before reverting a published post to draft.

When using the inserter, replace the selected block if it’s empty.

Display reusable blocks in the “recent blocks” tab.

Make sure blue line indicators appear consistently when using dropzones.

Ensure that hitting enter at the end of a paragraph creates an empty paragraph when using RichText.

Ensure the block settings menu and the block movers are shown when the default block is selected and user is not typing.

Deselect individual gallery images when clicking outside the block or selecting another image.

Add support for setting a page template.

Add support for individual image captions in galleries.

Add support for saving a post with Cmd/Ctrl+S shortcuts. This is possible after these RichText changes.

Support unwrapped paragraph text via native block deprecation mechanism. (Ensures paragraphs without p tags are correctly interpreted.) Also readdresses code that was applying autop selectively on the server for posts made with gutenberg as it is handled at the block level when needed.

Add raw handling (pasting mechanism) for iframes (e.g. Google Maps).

Allow WP to make images responsive via class.

Drop focus/setFocus props in favor of isSelected prop.

New PlainText component for raw content that is styled as editable text. Renamed Editable to RichText for extra clarity and separation.

Add RawHTML component, drop support for HTML string block save.

Absorb multiple-image uploads in generic image placeholder component and reuse it for galleries.

Refactor Default Colors and the ColorPalette component. Moves the default colors to the frontend making the Editor script more reusable without the need of the server-side bootstraping.

Make sure the inspector for a gallery block is shown when it has just one image.

Accessibility improvements for inline autocomplete components.

Update caption color for contrast.

Update visual display of the “remove x” button on gallery-items.

Improve classic block toolbar display and behaviour.

Dismiss tooltip when clicking a button or when wrapper node becomes disabled.

Restore block movers on floated items.

Add spacing around date and label.

Adjust raw handler “mode” option for readability.

Improve e2e testing performance.

Add fixture for undelimited freeform block.

Hold jQuery ready only when there are metaboxes and ignore advanced ones.

Make sure image size values are integers.

Fix floated gallery styles in the front-end.

Fix issue with image block not loading properly.

Fix issue with missing function in IE11.

Fix transformation of empty images into gallery and back.

Fix overflow issues on mobile.

Fix accidental block hover on iOS.

Fix toolbar state issue with slot-fill utility.

Fix case of too many undo levels building up.

Fix stylesheet load ordering issue.

Prevent input events from URLInput from being captured by Editable.

Force onChange to be updated with TinyMCE content before merge.

Polish heading toolbar buttons.

Remove image resizing on mobile.

Remove findDOMNode usage from Autocomplete component.

Rename references of rawContent as innerHTML.

Add tests and handle empty fills in slot-fill.

Add tests for block mover.

Add multi-select e2e test and fix issue with escape key.

Bump node version to active LTS.

Update TinyMCE to 4.7.2, fixing several bugs like toolbar flickering, visible placeholders when there is text, navigation breaks when encountering format boundaries, typing in FF after starting a bullet-list.

1.6.1

Handle pasting shortcodes and converting to blocks.

Show loading message when opening preview.

Fix inline pasting (auto-link feature).

Fix undoing multi-selection delete operation.

Remove focus state after a selection is finished during multi-select.

Remove the “command” shortcut to navigate to the editor toolbar.

1.6.0

Move the block toolbar to the editor’s top header. This experiment seeks to reduce the presence of UI obscuring content.