Support » Plugin: Gutenberg » Less is less

  • First off, I must say that I’m not a hater. I really like the idea of improving WordPress but I think this is not the way to go.

    I still remember the time when I first tried Squarespace’s new (also current I guess) website / page builder interface. All I remember was that “wow!” effect. It was shiny, innovative and I really wanted to build a similar interface on WordPress as a WP developer. That being said I’m not a close minded person to innovation. But what I see with Gutenberg is something hasn’t been planned thorough. Squarespace example is a good one in this case, because their sidebar allows to build entire website “on-the-fly” and it has been around for several years already. Now apparently WP authors has decided to come up with a similar idea but unfortunately it ended up with another back-end editor, nothing more than a fancy looking TinyMCE IMO. Even though it looks like a WYSWYG content builder, it just works as a back-end builder. Therefore the final look will be different on the website because it’s using Gutenberg’s standard content size instead of theme’s front-end view.

    Probably in near future Gutenberg will be somehow integrated into Customizer and users will be able to build their website without seeing unnecessary WP dashboard menus. Honestly I’d prefer having that kind full upgrade instead of this half baked product. I don’t even want to go into details like advanced WP page builders and stuff yet even the basic elements like Gutenberg Columns doesn’t work properly (I tried to use it and quickly messed up the whole page with plus buttons and unnecessary column types). Also I found the idea of hiding post settings bar (Featured image etc.) by default wrong. I guess many theme developers will be dealing with customer questions like “I cannot add a thumbnail to my post, how can I do this?” and it won’t be the fault of customers definitely.

    Another huge problem is WP 5.0 and Gutenberg is almost here but still there is no proper guidance of Wiki for developers. For example I use custom metaboxes for Featured Image and Page Attributes, but I see that remove_meta_box function doesn’t work as before. I’m still trying to figure out how to remove default metaboxes and all I found on Google is workarounds or he said she said. I’m really not sure what’s the hurry releasing an unfinished product.

    This could have been a beautiful side project (WP alternative with a clean interface, without bloated WP dashboard menus). But messing with the main editor for a not-so-big upgrade seems to me a risky idea. Hope it ends up well without breaking many sites / themes.

    * Sorry about Squarespace example. But I’m sure Wix and several WP page builder plugins offer similar experience as well.

    • This topic was modified 3 months, 2 weeks ago by  Mert D.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    Therefore the final look will be different on the website because it’s using Gutenberg’s standard content size instead of theme’s front-end view.

    For the record, themes have had the ability to style the content editor space for many years now (since WordPress 3.0), and for some reason, very few take proper advantage of it.

    The current editor (in 4.9) loads the editor-style.css file when loading the editor frame. That stylesheet can, fairly easily, adjust the content of the TinyMCE editor to make it look *exactly* like what would normally appear on the front end view of the site.

    For some reason, a lot of themes never took advantage of this. Not sure why, it’s super easy for them to do.

    Same thing goes with the new Gutenberg editor. Themes can include an editor-specific stylesheet (or inline rules, their choice) and load exactly the styles needed to make what-you-see-in-the-editor to look exactly like what-you-see-on-the-front-end. This is theme specific, because let’s be honest, the theme stylesheet overrides all. The theme controls the look, and it has been able to control the look of the editor for many years.

    This is no different. Yes, themes will need to adapt and include an extra stylesheet, but it can be a significantly pared down one, and it will be a bit easier for them to do so because the new editor is much more obviously styled than the old one was. More or less. I expect many themes to take advantage of this in an update or two.

    Technically it’s correct but still doesn’t apply to all situations. Basically WordPress prints the entire content where the_content() function added. That being said, content will appear differently on a page with sidebar and without sidebar. And this is just a basic example. There are many other situations similar this one. Therefore changing editor style won’t suffice.

    I know this is Gutenberg’s infancy, it will become better in time and hopefully you folks are already planning more advanced solutions.

    Until then I guess the most important thing is backward compatibility and better documentation for developers. For now the only thing bothers me is it’s causing certain incompatibilities (such as meta boxes) and I’m afraid to get an answer such as “No, you cannot do it with Gutenberg” (I’ve just posted a question to support about removing core meta boxes). Although it’s planned to be in the core on v5.0, it’s already being advertised with v4.9.8 and soon customer questions about these issues will be piled up.

    Interesting that there is a way to style the content editor space to reflect the front end. It might have been better initially to introduce Gutenberg only on themes built to show it off to its best potential whereby the back end gave a better sense of the front end content width.

    Throwing Gutenberg into the wild to demonstrate on websites already built for different use cases, with a different structure, not matched to what Gutenberg was designed for, has patently become a hive of confusion for many as we can see from the number of 1 star reviews.

    Somebody has shot themselves in the foot here. A smaller initial scope for the Gutenberg project would have put focus on getting a few key things done right and encouraged better enthusiasm for it given time.

    And. many opportunities missed where Gutenberg falls between two stools (pleasing only part of the user base) namely promotion of features to keep developers, coders and pure copy writers happy and, on the other side providing a unifying foundation for page builders.

    For developers, an update to the text tab to preform as better canvas for HTML formatting. CodePen, Codeacademy provide the mechanism for this, large canvas area, colour coded syntax, dark mode, code hinting and completion and most importantly proper handling of indentation. A little more work on code mirror, recently introduced to WordPress could have achieved this.

    On the page builder side, develop a block system that supports page layout and structure. A thoroughly optional feature that affords section/row/columns, grid and flex, whatever you are having you self. A foundation with an API that page builders can integrate with to provide their own features and ultimately provide a mechanism whereby builders or themes can be changed seamlessly by the user, or where a developer can return the content to a single content area without hassle.

    I’ll add that where Gutenberg is meant to replace the TinyMCE editing experience it actually takes out the whole back end workspace. A bad move is it disrupts in a really bad way a lot of useful tools that some of use in a vary flexible manner that the current back affords. Gutenberg, or whatever replacement is used should only replace the content creation area. Current page builders only target this area and with good reason.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this review.