Second look at the WordPress Gutenberg Editor
The development of the new Gutenberg Editor for WordPress 5.0 is progressing continuously. Time to take another look at the ambitious project and test the Gutenberg Feature Plugin. Does the new Gutenberg Editor keep what it promises?
The first beta in the form of a feature plugin for the new Gutenberg Editor was presented in June at WordCamp Europe in Paris and published on WordPress.org.
I tested the plugin extensively immediately after it was published.
If you are not familiar with Gutenberg as a term, I recommend reading my first post for an introduction to the topic:The future of WordPress are blocks: New Gutenberg editor released as beta plugin
In my first test with version 0.2, Gutenberg looked like this:
Development from Gutenberg to the present day
Gutenberg was originally released in version 0.1.0 and has received a new update almost every week since then. The current version (November 2017) is 1.7.0 .
Here is a brief overview of the course of the project so far.
June and July - version 0.2 to 0.6
Important features of the first five releases included:
- Default styling for blocks in the frontend
- API for notifications in the editor
- Navigation of blocks with up / down arrows
- API for inserting text from external sources
- Search function in the block inserter
- New blocks for Custom HTML, Read More, Cover Text and Cover Image
August - Version 0.7 to 1.0
Above all, the text block has been improved and many new blocks have been added:
- 0.7 - Improvement of the placeholders and better integration with WordPress themes
- 0.8 - Five new blocks for categories, text columns, shortcode, audio, and video
- 0.9 - Improved options for colors and font size in the cover text block
- 1.0 - Merge the blocks for cover text and paragraph
September - version 1.1 to 1.2
There were only two updates in September:
- 1.1 - Autocomplete when adding blocks and inline editing in the gallery block
- 1.2 - Support for Postmeta and first concept for Extended Settings
October - Version 1.3 to 1.5
In October the first implementation of metaboxes finally took place:
- 1.3 - Usability improvements, opacity slider for cover image and feedback option
- 1.4 - HTML mode for blocks and adaptation of the REST API for reusable blocks
- 1.5 - Support for metaboxes and inserter button between the blocks
November - version 1.6 and 1.7
The biggest change was the fixation of the block toolbar and metaboxes without iframes:
- 1.6 - Improvement of the writing experience and fixation of the block toolbar
- 1.7 - Metaboxes without iframes and multi-block transform feature
In addition to the larger features, innumerable details were also worked on in order to refine the usability and accessibility of the editor. My brief overview therefore does not begin to do justice to what has changed. The list is very, very long.
For this reason, it is worth retesting the Gutenberg Editor.
Gutenberg Editor in the test
If you want to try the Gutenberg Editor for yourself, you can still find the beta plugin in the WordPress.org plugin directory.
The Gutenberg plugin provides editing, customization, and site building features to WordPress. This beta plugin allows you to test bleeding-edge featu ...
Gutenberg is still rated very poorly. In my opinion, this is due to the very unfinished status of the plugin at the beginning, which was more of an alpha than a beta version. The editor is being very actively developed and continuously improved.
I therefore recommend giving the Gutenberg Editor a chance and testing the plugin yourself, not just reading my article 🙂
First impression - Much tidier, smoother and faster
The first impression of Gutenberg in version 1.7 is very, very good. No more comparison to my first detailed test of version 0.2.
I consider the placement of all buttons and the toolbar in the top bar of the editor to be a significant improvement. This means that the buttons for formatting the text can now always be found in the same place and are no longer directly assigned to the block in the content.
This makes Gutenberg feel much tidier and more elegant. Before, the buttons were displayed by selecting a block in the text, which I found very annoying. The many boxes often obscured the text, faded in too many options at once and thus disrupted the flow of writing immensely. Now that is solved much better.
You can also see the numerous performance updates - Gutenberg now feels very fast and fluid. This is also due to the many small improvements in usability, which have largely eliminated the somewhat awkward operation in the first versions of the plugin. Operation with keyboard only has also been improved.
Improved usability for creating blocks
Many small details now make it easier to create and add blocks.
Block inserter
The block inserter now supports a search to quickly find the right block. In addition, the last used blocks are displayed directly. It is now also possible to insert a new block between two existing blocks.
Insert pictures
Images can now easily be dragged from a desktop folder to any position in the editor using drag & drop. Gutenberg automatically creates a block for the picture and uploads the picture to the media library. It is no longer necessary to manually add an image block before uploading.
Convert blocks
The transform button is also new, with which existing blocks can be quickly converted. A normal text block, for example, can be transformed into a block for headings, quotations or lists with one click.
Insert blocks with keyboard
One point of criticism that was often expressed was the large number of mouse clicks required to create the individual blocks. Due to the constant switching between keyboard and mouse, the writing flow was interrupted unnecessarily often.
In the meantime, an article can be written relatively fluently in Gutenberg. With an Enter, a new text block is automatically created and you can simply continue writing.
If another block is required, it is sufficient to enter a slash / as the first character in the text. Then the name of the block can be entered and selected from the list.
The autocomplete feature automatically shows the blocks that match the entered keyword. Blocks can be added very quickly using the keyboard.
Insert text from external sources
An API has also been worked on so that text from external sources such as Microsoft Word or Google Docs can be easily inserted.
That works pretty well. For example, it is sufficient to simply copy the content of a Google Doc into the first text block. Gutenberg creates individual blocks from these and automatically recognizes text, headings and lists.
Edit block settings and block HTML
The right sidebar now shows two tabs. Document refers to the entire article, therefore contains the typical meta boxes for categories, keywords, article image, etc.
The Block tab, however, always refers to the currently selected block. With a heading block, for example, these settings are displayed:
The block settings can be called up by clicking on the menu symbol of the respective block. Alternatively, the block can be deleted or the HTML code of the block edited with the menu icon.
Editing the HTML code of a single block is a great feature in my opinion. How often have I searched for the right place in the HTML in text mode ...
The text mode, which shows the entire post in HTML, is almost superfluous.
Two-step button for publication
The publish button for publishing an article has also been improved.
This now opens a drop-down menu in which the visibility of the post and the date of publication can be set.
The two-step process is to prevent the post from being published prematurely by mistake, which can easily happen with the current editor.
Change color options and font size
I take a very critical view of the design options for adjusting the colors and the font size. These are available as settings for each text block in the sidebar.
Personally, this is too much in the direction of page builders.
In my opinion, the design should remain the task of the theme. The editor should be a tool for creating and managing content - not for designing content.
After all, WordPress is a CMS, not a website builder.
Work in progress: support for Metaboxes
For a long time it was not clear how exactly metaboxes would be implemented in the new editor. Implementation has now started and metaboxes are available in the Gutenberg Editor. The first concept was still based on iframes, but these were removed in 1.7.
At the moment there are still a few bugs and the technical implementation has not yet been completed. I have therefore omitted extensive tests of the Metaboxes because they still need some updates.
Conclusion
The pace of Gutenberg's further development is remarkable and the new editor is slowly starting to look really promising. Usability has made a significant leap forward and it's just fun to experiment with Gutenberg.
I am not convinced of all features, such as the color and font options mentioned. There are of course still a lot of construction sites, bugs and missing features. Gutenberg seems unfinished in some places, which is completely normal for a feature plugin.
Overall, I'm confident that by the time Gutenberg is released in a few months, all of these problems will be resolved. The development so far speaks for it.
What do you think of Gutenberg?
Good evening,
first of all thank you for this article. I myself am a web developer and a staunch supporter of the Gutenberg Editor. As you already write, the pace of development is remarkable. The features that are already integrated look well thought out and make sense in most cases.
Unlike you, I am also very convinced of the option to manipulate background colors and text properties. On the one hand, I agree with you when you write that you view this feature very critically. On the other hand, WordPress has always wanted to satisfy the greatest possible number of users. We, who use WordPress as a CMS and blog, will use coloring and the manipulation of text properties very carefully and carefully. But there are also users out there who will use this feature excessively.
If I'm honest, I even see the potential to replace these miserable page builders. I'm not a friend of Composer and Co. They are badly programmed, use outdated web technologies, load the system unnecessarily and create such nested markup. You could do that much better with Gutenberg.
Hello Marcel,
Thank you for your comment.
I can understand the desire to be able to change colors and font size. But I see inline styling problematic for individual blocks. Colors and typography should be defined globally by the theme. Options for changing can then also be available there.
Inline styling brings with it problems, e.g. inconsistent font sizes on the website, the use of larger fonts for headings instead of semantically h-tags, problems with adapting the font for other screen sizes - keyword responsive design.
When changing themes, the font usually also changes, with which a completely different font size often makes sense. It's pretty stupid when the font size has been changed individually as an inline style in the content and can no longer be adjusted so easily.
That would be just a few things that occur to me spontaneously. With a little more time, I would probably come up with more reasons against inline styles 🙂
I totally agree with you on the subject of Page Builder. I also have an aversion to the existing solutions and hope that Gutenberg will be a good alternative here and, above all, will ensure standardization.
My wish would be for Gutenberg and the core to stay as lean as possible, but for the editor to be expanded very flexibly with plugins for further blocks and options and thus to be drilled out into a full-fledged page builder. Gutenberg and the block system as the basic framework, so to speak.
An important feature that Gutenberg pushes from an editor towards the page builder are multi-column blocks. This is already planned, but will probably only come in the second version of Gutenberg, not with the first release in WordPress 5.0.
Many Greetings,
Brian
Hello Marcel
Overriding colors and fonts and defining them inline is, in my opinion, a step in the wrong direction. The styles should rather be defined centrally and then assigned to the individual objects.
In this way you can limit the usage for individual users, for example.
There is simply the risk that corporate designs will no longer be adhered to and that a website will no longer be consistent. Later design adjustments are then also associated with search and replace.
This ultimately leads to a time-consuming “tinkering”, as is already the case with the common composers.
For a web agency that creates websites for corporate customers, for example, this is so suboptimal.
regards
Martin
Hello Martin,
Thank you for your comment. You put the problem in a nutshell, I can only agree
Many Greetings,
Brian
Hello Brian,
I also positioned myself for Gutenberg. I noticed on the relevant forums that many users no longer speak of WordPress, but of their builder theme.
I see the danger that WordPress will split up, a bit like Ubuntu with an infinite number of distros ... in the end Mint gnawed at the success of the standard version.
I have nothing against Divi or Enfold, but please in the niche and not as a standard WordPress. Gutenberg is a way to re-bind users and a good compromise between classic WordPress and a modular system.
As for the thing with inline styles: If you only have 5 pages, you can pfriemlen until it fits ... if you have a big blog, hopefully you won't mess around with the colors in every post ... 😉
Greetings from Würzburg
Bernd Schmitt
Hello Bernd,
Thanks for your comment!
I see it the same way. Hopefully Gutenberg will be so good that most websites no longer need a heavyweight like Divi, but can work with the core and possibly a few additional plugins.
The big page builders will probably not die out anyway, because there will still be users who want to configure every little detail as possible. And they already have a huge user base.
Many Greetings,
Brian
Hello Brian, I'm looking forward to Gutenberg too. I set up my homepage with a page builder many years ago and have been trying to get away from it for months. What I only see today is how much crap Enfold has written into my database. And the funny thing is, when I switch back to Enfold after trying to switch, all the layouts are back. I just can't get all this crap out of my database. At the moment it looks like I have to completely redesign the homepage.
And all because I liked the many features for a business website so much back then. I know better today.
Hello Adrian,
Thanks for your comment.
I've never tried Enfold myself, but the lock-in effect is a problem with many page builders, which Gutenberg will better solve.
Many Greetings,
Brian
Hello Brian,
Thanks for the very informative contribution!
Some time ago I tried an early Gutenberg version and quickly put it aside because everything was still very unfinished. I picked up the thread again with version 1.7 and I have to say I'm impressed. I'm gradually getting a feel for where it could go.
The thing about color options - we agree on that. Pink text on a green background isn't just every theme developer's horror vision. These details are placed far too prominently. You also have to be able to color a text, but basically that's the job of the theme. The UI for this should be much reduced and can be a few clicks further away,
My impression is that you can do an amazing amount with Gutenberg. Whereby you never know whether you will find all functions in the next version 😉
What I didn't manage at all: to place two elements, e.g. an image and a text, next to each other. Am I just too stupid or does it just not work out yet?
Best regards
Kirsten
Hello Kirsten,
Thanks for your comment.
It's the same for me, in contrast to the beginning of the project, I'm slowly becoming pretty convinced of the new editor. Gutenberg has clearly improved
Theme developers will at least have the option to specify their own color palettes. This means that the colors offered at least match the theme.
In my opinion, it would be best if the theme can specify different color combinations or styles, which are stored as a CSS class and therefore not included in the content as inline styling.
Multi-column blocks will likely come in the second version of Gutenberg, not the first release. To do this, nested blocks must first be technically implemented, which then makes a column block possible, for example, that contains other blocks.
To arrange an image and text next to each other should work by aligning the image left or right. Here a float: left or float: right is simply set for the picture, just like with the old editor.
Many Greetings,
Brian
“To arrange an image and text next to each other should work by aligning the image left or right. Here a float: left or float: right is simply set for the image, just like with the old editor. "
I tried that and I would have managed to do it if I had pulled the HTML a bit, but my feeling was (as you write too) - that this is probably still in the works.
The elements in the editor could be pushed around using the alignment icons (float left / right), but the result was not stable. In other words: You can't see anything in the FE.
"In my opinion, the best thing would be if the theme could specify different color combinations or styles, which are stored as a CSS class and therefore not included as inline styling in the content."
That would be absolutely awesome.
I am missing the customizer / theme connection. That is the reason why I am still a bit unfamiliar with the customizer.
I would like a way to get the colors that I define in the customizer into the stylesheet. So that I can continue to use them as variables there (I hope that was understandable now). Every now and then I follow up a few ideas, but I haven't found a good solution.
Kirsten
The common method for color options is to generate the required CSS code in PHP and get the defined colors from the database.
The generated CSS code is then attached to the style.css with wp_add_inline_style () and overwrites the standard colors. This implementation can also be found in Twenty Sixteen, for example.
In the future, color options with CSS variables will be easier to implement, because then only variables can be overwritten instead of dozens of CSS details individually. CSS variables are only supported by modern browsers, ie Internet Explorer unfortunately has no support for them.
Many Greetings,
Brian
Hello Brian,
Thanks for the answer!
"The generated CSS code is then attached to the style.css with wp_add_inline_style () and overwrites the standard colors."
I've already come across this approach and haven't pursued it any further because it doesn't do what I want. I don't want to overwrite something at the bottom, but I would like the colors to appear as variables * at the top * in the stylesheet. But there is currently no way there. At least not one that I think is workable.
"In the future, color options with CSS variables will be easier to implement, because then only variables can be overwritten instead of dozens of individual CSS information."
I am not entirely sure I understand what you mean.
You probably mean that the CSS specs will be expanded to include variables at some point. To what extent would that have an impact on the "CSS from Customizer / style.css" interface?
KIrsten
Yes, CSS can already map variables with var () today:
https://developer.mozilla.org/de/docs/Web/CSS/var
https://wiki.selfhtml.org/wiki/CSS/Variablen
CSS variables are not available in Internet Explorer, which is why they are still used very rarely.
Many Greetings,
Brian
CSS variables have the advantage that less custom CSS code has to be generated to overwrite the standard colors.
To the interface Customizer and style.css:
CSS is responsible for the styling, ie PHP or JavaScript is always required to get the settings from the database and to generate the CSS code from them.
Hello everybody,
I'm still quite new to the more ambitious use of WordPress, I really want to be able to handle it better in order to be able to offer a reasonably professional blog (which I'm still a long way from).
If you read about WordPress, news about Gutenberg is now ubiquitous. With WordPress 5.0, a “paradigm shift” is imminent, as you can hear. Before I deal more intensively with a number of other great plugins (Custom Post Types, Advanced Custom Fields and Elementor, for example), I ask myself whether it wouldn't make sense to invest more time in using Gutenberg instead.
At a recent MeetUp I just got: Yes, definitely test Gutenberg, but never on the live side. Now I'm too little a developer and too focused on day-to-day business to set up a test environment and work with Gutenberg for the sake of testing.
Now I would like to ask the knowledgeable group: How do you currently rate the risk of using the Gutenberg editor in your active blog? Is there a risk that with further updates of the plugin or the switch to 5.0 previous articles will be completely destroyed? To put it another way: What can Gutenberg's deployment currently cause in the worst case?
I can of course keep my hands off Gutenberg (and other plugins, about whose future I'm unsure) until 5.0 is available in the foreseeable future. But if it is useful / sensible to integrate the plugin into your way of working now, then I would be very interested.
Sorry if the questions / thoughts are naive.
Best regards!
David
Hello David,
Very good questions you are asking.
In principle, I would also advise against using Gutenberg on a live site. The new editor is already quite stable, but there are still bugs that can interfere with working and writing.
In addition, the ecosystem must first adapt for the new editor, which will happen even more in the coming months. Themes will add extra styling for Gutenberg, plugins will create blocks to be compatible with the editor.
At the moment I therefore see little advantage in using Gutenberg on a live site right now.
Many Greetings,
Brian
Thanks for the advice Brian! Have a nice evening!