Support » Plugin: Gutenberg » Flawed, but always getting better, and full of potential

  • UPDATED 2019-10-10; Original review posted in comments below.

    Before I can write a review on Gutenberg, it should be made clear what exactly Gutenberg is. To put it simply, it is 2 things depending on the context:
    – the block-based editor used in WordPress
    – a long-term project that extends beyond the editor and into all parts of content creation and site building in WordPress (and even outside of WP: https://drupalgutenberg.org/)

    The block editor was merged into WordPress core in the 5.0 release. However, the plugin still exists for testing future updates to the editor and other parts of the Gutenberg project, e.g. replacing widgets with blocks, building page templates, revamping or replacing the Customizer, and so on.

    If that doesn’t explain it well enough for you, I recommend checking out the following resources to get a more thorough understanding of what it is:
    https://wordpress.org/gutenberg/handbook/
    https://wordpress.org/gutenberg/handbook/contributors/outreach/

    This is a review of the current version of the block editor provided by the plugin, as well as any other features added by the plugin.

    The editor

    I think the editor is a definite improvement over the classic editor overall. Thanks to the block-based design, it’s more WYSIWYG (with a compatible theme, anyway), and the controls are more contextual. There are a lot of nice things like the lack of annoying automatic paragraph insertion, publishing/updating without reloading the page, and the “Edit as HTML” option that lets you edit a single block as HTML, rather than having to edit the whole document at once.

    I use the Gutenberg editor for all my posts, as it provides a much nicer experience than the classic editor or any page builder I have used.

    Up until recently, I’ve been using Divi Builder as my primary page builder for any thing that isn’t a post. However, I’ve started using the block editor to build some pages, and I think that it has become a much better page builder than it was at the start of 2019. It still has a long way to go before I would recommend it to other people as THE way to do page building, though. The lack of things like responsive controls and less-than-ideal theme style integration are some of the main limiting factors of the editor right now, along with the lack of page template building (which is planned but still in the early stages of development).

    There are definitely some flaws with the editor as it is right now. The biggest issue with the editor right now is accessibility. A lot of controls lack visible, textual labels, and various controls are difficult to access with a keyboard. This makes the editor difficult to use for people with disabilities, and in many cases it reduces general usability for everyone. Unfortunately, accessibility was not taken into account enough during the early development of the editor, and various aspects of the UI/UX suffered because of this:

    • The block inspector is not semantically placed next to or clearly associated visually with the selected block, so you have to use keyboard shortcuts or excessive tab presses to reach it with a keyboard.
    • The sibling block inserter is attached at the top of a block (rather than the bottom like you would expect), resulting in a confusing tab order and overlapping UI elements when the block toolbar contains a lot of controls.
    • Most of the controls in the top bar have no visible text labels, which can cause confusion for new users who don’t know what all the buttons do.

    This post gives some more info on the lack of accessibility in the Gutenberg editor:
    https://make.wordpress.org/accessibility/2018/10/29/report-on-the-accessibility-status-of-gutenberg/

    It should be noted that it has been almost a year since that article was written, and the editor is in a much better state now. Every update brings more improvements. However, I do think that a lot of the issues should have been resolved before the initial WordPress 5.0 release, not after.

    Another issue with the editor is ironically its lack of WYSWIYG-ness. By default, theme styles have no effect on how things look in the editor. Themes have to opt-in to style the editor. This isn’t really that big of a problem on its own, but in most cases, theme styles have to be tweaked to work in the editor. This is due to various technical restrictions which are hard to work around, especially since WordPress is still supporting Internet Explorer 11. The long-term ideal goal is to import the front-end styles from a theme directly into the editor, but it will probably be a while before this goal is reached, unfortunately. Like the rest of the editor, this has been and is continuing to be improved with each update, though.

    Interacting with blocks nested within other blocks can be a bit tricky right now, due to various UI/UX issues that have yet to be resolved (though the devs are working on them). Recent updates have greatly reduced this problem, though.

    Another change I would like to see is that the Quote block be updated to use nested blocks for their content. Of course, one of the reasons this hasn’t happened yet is due to the aforementioned nested block UI issues.

    Something else that I hope will be improved is the UI for using reusable blocks as templates. Sometimes you just want to use reusable blocks as templates, rather than inserting a block that is tied to a global instance. You can technically use Reusable blocks like that, but the UX for doing so could definitely be improved.
    https://github.com/WordPress/gutenberg/issues/8403

    Widgets to blocks

    Updating the Widgets page to use blocks instead is one of the big upcoming parts of the Gutenberg project. The block-ified Widgets screen is currently hidden behind an “experimental features” flag and will not be included in WP 5.3. Because of this, I don’t really have much to say about this, since the new Widgets page is clearly still very WIP. I only hope that the final result will be at least as accessible as the current version of the page, but hopefully more accessible. Additionally, I hope that in the long term, block areas are edited individually, and not all on a single page.

    Project potential

    I’m definitely looking forward to the future possibilities opened up by Gutenberg. Some of these are still pretty far in the future, but they’re definitely things that make the whole project worth pursuing:

    – Thanks to the modularity of Gutenberg, the editor and block APIs can be used outside of WordPress. Drupal Gutenberg is a good example of this.
    – Similarly, existing page builder plugins could adapt to use blocks, allowing for a single, powerful, and flexible way to create modules that would work with any page builder. In the long run, some page builders could even become simply extensions or reskins of the core editor.
    – One of the long-term goals of Gutenberg is building entire page templates. Imagine being able to build your entire website (headers, footers, sidebars, page templates, etc.) using the block editor. I’m looking forward to the day that becomes possible.

    Final thoughts

    I highly recommend providing any feedback or bug reports you have to the GitHub project; I have learned a lot about the project by simply browsing through the issues and pull requests and reading all the discussion that has been going on there. I’ve even been able to help the development by creating some pull requests and providing feedback on others. You can also join the WordPress Slack if you want to get more of a look into Gutenberg or general WordPress development.
    https://github.com/WordPress/gutenberg/issues
    https://make.wordpress.org/chat/

    Aside from the aforementioned issues, I am thankful for the Gutenberg project, and I am looking forward to all that it will bring to WordPress. Despite its current issues, I really do think that this project is very important to the future of WordPress. I just hope it can continue to get past its growing pains and poor decisions of the past.

    • This topic was modified 1 year, 3 months ago by  Zebulan Stanphill.
    • This topic was modified 1 year, 2 months ago by  Zebulan Stanphill. Reason: Completely re-did review, since a lot has changed since I first wrote it
    • This topic was modified 1 year, 2 months ago by  Zebulan Stanphill. Reason: minor date typo fix
    • This topic was modified 1 year, 2 months ago by  Zebulan Stanphill. Reason: title change
    • This topic was modified 1 year, 2 months ago by  Jan Dembowski. Reason: Removed links
    • This topic was modified 1 year ago by  Zebulan Stanphill. Reason: Re-did the review again since various changes and events have made it out-of-date
    • This topic was modified 11 months, 2 weeks ago by  Zebulan Stanphill. Reason: Updated due to recent improvements and accessibility concerns
    • This topic was modified 10 months, 2 weeks ago by  Zebulan Stanphill. Reason: Updated to revise outdated info and adjust due to WP 5.0 release
    • This topic was modified 8 months ago by  Zebulan Stanphill. Reason: Redid review to be more organized and removed outdated or incorrect info
    • This topic was modified 8 months ago by  Zebulan Stanphill.
    • This topic was modified 1 week ago by  Zebulan Stanphill. Reason: Updated review to better reflect the current version of the plugin
Viewing 9 replies - 1 through 9 (of 9 total)
  • What you are suggesting is ideally what I am hopping Gutenberg will be, when fully cooked. I see a lot of reaction that doesn’t actually dig in and analyse where the pain points might be. And painful it maybe but in the long run well worth it.

    Some of the use cases where I had some concerns in terms of the UI I have already got solutions for with simple CSS hacks and these I may not even have to use as either they will be addressed by Gutenberg itself or the vendors of the plugin I use.

    On the page builder front, I use Divi, and while it really does a great job and I can’t knock it, the fact that it runs on its own proprietary short codes for structure means that changing themes can be an issue, exactly as you outlined. In a way this is a legacy problem generated by WordPress itself, in that where it became stale, page builder vendors stood into the breach with a better solution for end users.

    Where I see this being resolved, again just like you suggested, is if WordPress provides for the basic box model structure (section, rows, columns, modules/blocks) and then provide an extensive api for the page builders to hook into.

    We will have to wait how things pan out. I spent the last number of hours testing the latest release of Gutenberg and with some new block plugins. Some I really like, even without the full functionality that I get the current conventional ones. Another one though just didn’t work at all, probably because it needs an update.

    Ideally, due to this environment of mismatches and lack of compatibility, it might be better for Gutenberg to be in core, not on by default, but to be triggered into action by themes that are compatible with it. Ultimately I do see the logic though of putting a gun to peoples heads to get them moving on it, so at some stage we would need to be warned that the old classic editor was going.

    It seems to me that most commenters on here understand the long term benefits, but that is the problem, it’s not going to fulfill that grand vision until a long time from now when its tried and true, finished and polished.

    That’s like forcing everyone to get autonomous electric vehicles right now when they’re not really going to be ready and polished for wide-spread use for another 10 years (long term).

    Don’t implement the short term disjointed prototype based on what it will be in the long term.

    @kittyridge

    I get what you mean, but I think Gutenberg can be put into core before being completely finished, while also not being a disjointed prototype, due to it consisting of multiple components. The first component (the block editor in the context of editing the content of a post or page and the edit-and-publish experience) can be implemented before the others, as long as it is itself polished enough for production. Gutenberg does not have to replace everything before it gets merged into core. Right now, I think the idea is to simply replace the current editor.

    What the Gutenberg project needs to accomplish in WordPress 5.0, in my opinion, is to replace the Classic Editor without losing any useful functionality, while also maintaining a good amount of backwards compatibility to ease the transition into the new content-editing experience.

    If I am remembering correctly (correct me if I am wrong), it is planned that if an incompatibility is detected between Gutenberg and a plugin while loading a post, the Classic Editor will be loaded instead. This should help with some of the more extreme incompatibility cases.

    Additionally, opening an old post in Gutenberg puts everything in a Classic block, which has been made to essentially be an embedded instance of the TinyMCE editor box. This means that people who use plugins that add buttons to the TinyMCE editor will still be able to use them in Gutenberg if they do not convert the Classic block to standard Gutenberg blocks. This should make transitioning into the new editor a lot easier. Interesting to note, the Classic block is not technically an actual block. It does not have any corresponding HTML comments to represent where the block starts and ends. The way it works is that any content in post_content that is not inside a block is treated like legacy content (which in most cases it probably is).

    And then there is the metabox support. I think this is the part that needs the most improvements. Ideally, the majority of metaboxes should work perfectly in the Gutenberg editor. As it is, a lot work decently, but there are still some bugs and quirks here and there. I am glad the development team has managed to improve how they handle metaboxes over time (thankfully they are not using <iframe>s anymore), and I hope they will be able to continue improving it as they near release.

    And then there is the Classic Editor plugin, which should solve pretty much every remaining compatibility issue, albeit with the need to go and install a plugin, which could be a hassle if it has to be done on a lot of websites. Ideally, this should rarely be necessary, and I hope a download link to this plugin is provided on the welcome screen of 5.0 for quick access.

    Besides compatibility, there is also the task of making the editor feel intuitive and an improvement over the current one. Of course, there are currently several UI bugs that exist, but assuming those get fixed, there is still improvements that can be made to the UX and UI, such as making drag-and-drop easier to discover and use. I am optimistic that these issues will be resolved before the 5.0 release, though I could be wrong. (I hope not!)

    Assuming that this first phase of Gutenberg is polished enough for the 5.0 release, then I think developing Gutenberg in stages will help the project a lot. Having the initial post-content-editing part of Gutenberg in core will dramatically help the design and development team to figure out what people want to be added or improved. (Of course, the project still needs to be good enough to be considered decent by everyone before it is merged.)

    The phased development of the project will also allow plugin and theme developers to easily start taking advantage of blocks and the other initial features of Gutenberg right now, making it easier to adapt when the later features of the Gutenberg project are implemented. Of course, the Gutenberg APIs regarding the initial features should be relatively stable upon merge proposal, and right now they are currently still be revised in key parts, so Gutenberg definitely should not be released until that has been resolved.

    @irishetcher

    I am not entirely sure whether Gutenberg should be enabled by default or not in WordPress 5.0. Depending on how well Gutenberg handles compatibility, there may be hardly any problems, and so having it enabled by default would be just fine. Additionally, a lot of plugins and themes are working to add Gutenberg support, so that should help a lot with the transition as well.

    I think a lot of this depends on just when WordPress 5.0 is released. Would June be too early? What about December? How polished will Gutenberg be by then? How much support will it have from plugins and themes? How many people will be affected by potential compatibility issues?

    If you use one of the popular page builder plugins, I think you probably have nothing to worry about. Divi has announced that they will be ensuring Gutenberg compatibility, and I expect that for the first Gutenberg-compatible release, they will likely just load the Classic Editor screen when editing with Divi, making the admin editing experience the same as it is now, and the Divi Visual Builder will be completely unaffected. (They may also add a button to the Gutenberg editor to switch to the Divi editor… AKA the Classic Editor with the Divi Builder on it.)

    Beaver Builder is already adding basic Gutenberg support in the form of a Beaver Builder block that is essentially just a link to open the Beaver Builder Page Builder, so it is hardly affected at all as well.

    SiteOrigin is making their page builder into a block, meaning you will be able to use the SiteOrigin page builder within the Gutenberg editor, which is certainly an interesting initial approach.

    Avada has announced that they are working to support Gutenberg, and I expect that they will do it in the same way that I expect Divi to do it… just load the Classic Editor screen to make it work the way it does now.

    Elementor is planning to support Gutenberg in some way as well, and I expect that they will initially do it much like Beaver Builder, and will likewise be hardly affected by the first phase of Gutenberg.

    The Visual Composer team has also announced that they will support Gutenberg, and you will be able to use Gutenberg blocks within Visual Composer, so that is neat.

    If you are not using one of the page builder plugins and are instead just using the Classic Editor, then I think the biggest problem you may have is with metaboxes. Again, this is where plugin/theme support and polish before launch are vital. A combination of good metabox support in Gutenberg, plugin and theme compatibility, and the option of the Classic Editor plugin should, I think, be sufficient to handle most cases.

    Overall, I am quite optimistic for the Gutenberg project, though I think the timing of the 5.0 launch and the state of the project and plugin/theme support leading up to it are important and should not be overlooked.

    Elementor and Divi both offer developer APIs.

    https://www.elegantthemes.com/documentation/developers/
    https://elementor.com/introducing-elementor-developer-api/

    @lukefiretoss

    Yeah, those are pretty neat (and should definitely make using and extending those builders a lot easier), though those APIs did not exist until just recently, and the two APIs are of course separate and incompatible with each other, meaning if you develop for one your work cannot easily be carried over to another. Ideally, I am hoping that the Gutenberg project will result in a common API that is shared across all page building in WordPress, with plugin-specific APIs on top of it that exist for things specific to a particular builder plugin, like how options are visually presented in the UI of a particular builder interface, or support for features exclusive to a particular builder… a common API built off of Gutenberg could also mean plugins that add blocks that work in all builders, but also have good integration with the interfaces and unique features of multiple different page builder plugins which do not have an equivalent in the core editor and APIs.

    This is exactly how I believe things should pan out. First Gutenberg, in its current guise, gets all its crease ironed out and is rolled out in WP 5. Initially any compatibilities with page builders will be minimal, enough so that things don’t break. After this the next thing that needs to happen is that a proper box model structure is provided under the black system, catering for sections, rows and columns and with the fore mentioned api, allowing page builders to hook into a standard for page layouts. At this stage the page builders need to get on board or else become irrelevant.

    This incremental approach suggests to me that the more sensible approach to introducing Gutenberg is to have it as default when WordPress detects themes and plugins that are compatible, otherwise default to the classic editor. No need for a separate Classic Editor plugin and settings to let the user control when Gutenberg should or shouldn’t be active.

    For new installs a TwentyEighteen Gutenberg theme would be a entry point for new users of WordPress. I will add that there needs to be ultimately some form of front end visual builder aspect to Gutenberg, even if it only has rudimentary features out of the box. While I like and and dislike the current UI for Gutenberg (I like the way it has nice flow if you are doing quick posts, adding content in a linear fashion. I don’t like that it doesn’t function well for other use cases such as data entry), Gutenberg still presents the disconnect for novice users of editing content in one manner that doesn’t relate to how it will look on the front end. Going straight to a visual builder may be a better experience to get new users on the WordPress train. They can always then chose whichever page builder they want, once they become comfortable with working with the basic components.

    I have re-done the review, since a lot has changed in the past 3 and 1/2 months.

    Here is the original review:

    A lot of people do not understand Gutenberg, it seems. Perhaps that is partially the fault of the WordPress team for not being very clear on their plans from the very start? Perhaps it is also because Gutenberg is not really an easy thing to explain.

    Most people expect all the features of the popular page builder plugins to be present in the version of Gutenberg that ships in WordPress 5.0. However, that is not the point of Gutenberg. Gutenberg is intended to provide a strong core that will, in the long run, be capable of everything the page builder plugins can do and more, while also solving many problems with building websites using WordPress.

    What do I mean? Well, consider this.

    There are a lot of page builder plugins. They all have different APIs and backend code, with modules/widgets/whatever-they-call-them that work only in their builder, and nowhere else. The page builder plugins have become a bit bloated, in some aspects. They not only provide a page building framework on the backend, but also a UI for using it, and many modules that can be used in it, but nowhere else. Want to switch from one page builder to another? Get ready to have to rebuild your content and deal with the loss of all the custom modules that the previous builder had.

    It sure would be nice if there was a common API that all page builder plugins could use, so that pages could use any page builder graphical interface, but they would all share the same backend core APIs, and the modules would not be tied to a single builder anymore.

    Gutenberg solves that problem. You may not like the Gutenberg UI, but you do not have to like it to benefit from the potential unification of page building that it could bring. Page builders would now be more compatible, and a lot of stuff that is currently bundled into a single page builder plugin could be spun off into something independent of any single builder, because it would be using the common APIs provided by Gutenberg.

    But that’s not all Gutenberg will help with. Remember widgets? Those are pretty nice, but sadly, they have becomes pretty unused lately since they are usually only usable in specific widget areas created by your theme. You can not use them anywhere you want on your posts or pages, which greatly limits their usefulness. Some page builders like Beaver Builder and Elementor allow using WordPress widgets in their page builders, which is nice, but it would be even nicer if using them outside of widget areas was supported in core. Additionally, it would sure be nice if the WordPress widgets and the modules from any given page builder plugin used the same APIs and were not built with two completely separate systems.

    And then there are shortcodes. Those work almost anywhere, but they are not a very visual way of adding content to something. And neither are widgets, though they are slightly better as they do have a UI, while shortcodes have none. And speaking of which, why are shortcodes and widgets separate? It would be nice if there was a single sort of… “block” or something that could be used anywhere and superseded both of them. Gutenberg solves this problem. Blocks in the Gutenberg editor provide a visual editing experience that is a lot nicer than manually editing the text of a shortcode, and far more flexible and WYSIWYG than a widget.

    And then there are metaboxes. Some metaboxes involve things that are part of the main post/page content. These metaboxes will be replaced by Gutenberg blocks as well. Other metaboxes involve stuff outside of the main post/page content, and some of these will be replaced by things like the custom sidebar APIs that are being implemented into Gutenberg right now, while others will also be replaced with blocks.

    But wait, if something is affecting content outside of the main post/page area (think author bio at the bottom of a post, the comments section, or the post title header of a page), then how can blocks solve this problem?

    Well, as it turns out, Gutenberg will be able to edit areas outside of post content in the future. Not at the 5.0 launch, but it is on the roadmap. Gutenberg will eventually make it possible to edit not just the content of posts, but the content of your footers, your sidebars, the layouts of the post title, featured image, post content, and comments section on your website, and in the process make it possible to build a website without using manually-created PHP template files, and reduce the need for specific themes (or make them almost entirely convenient packages of premade layouts that could have been made using the Customizer and Gutenberg editor).

    Gutenberg will provide a strong core builder system that will soon greatly enhance the WordPress website building experience, bring modular content blocks to the editor that are independent of any builder (like widgets did for sidebars, but with the ability to be used anywhere), and obsolete some page builders while turning others into extensions and alternative user interfaces for the core editor that all share the same common core APIs and prevent designers and developers from becoming stuck with any particular page builder plugin.

    Will Gutenberg immediately do all of this at launch in WordPress 5.0? No, it will not. Gutenberg is being developed in phases, and the version in WordPress 5.0 will only be the result of the first phase. But in the long run, Gutenberg will change a lot about WordPress editing, and I am looking forward to that future.

    If you can not use Gutenberg yet for whatever it is you do, then that is fine. You can still use the Classic Editor via the Classic Editor plugin, and you can still use your page builder of choice as well. In fact, Gutenberg does not mean the death of page builder plugins. If anything, I think Gutenberg will be able to make them more powerful.

    Like I said before, in the long run they may adapt by becoming front ends for Gutenberg that look the same as they did before, but use a core set of APIs that allows you to easily edit the page in whatever builder you choose. Others may take an approach that is basically the same as most do right now and make their code pretty much completely separate from the core editor, providing their own edit screens for the WordPress admin that simulate what they look like right now with the Classic Editor. Still others may integrate (at least initially) with Gutenberg by creating blocks for the Gutenberg editor that are basically embedded instances of their builder. (That is what SiteOrigin is doing.) There are a lot of opportunities for integration and improvement.

    As for compatibility, I am really not that concerned. WordPress 5.0 will load the Classic Editor if it detects a plugin incompatibility, and the Classic Editor plugin will be available to force usage of that editor when necessary. Additionally, Gutenberg has been continually improving its compatibility with metaboxes, and many plugins have been working to add support for Gutenberg. The Gutenberg editor even provides a Classic block that is basically an embedded version of the TinyMCE editor box in the Classic Editor, in order to ease the transition for older content into Gutenberg.

    One more note I would like to make is that a lot of people think Gutenberg should provide every formatting option possible by default. But in my opinion, WordPress is supposed to provide a strong core that can easily be extended with whatever features you want. Gutenberg will allow that. Yes, you can not color text inline in a Paragraph block. (Well actually you can using the “Edit as HTML” option.) But you can just use a plugin that adds that option to the block. And perhaps if the plugin is installed by a large number of people, the WordPress team will decide it must be a greatly wanted feature and add it to core. But Gutenberg should not be judged by how many options it has by default. It should be judged by the core interface, the ability to extend it, and whether it provides good default features or not.

    Since I have been pretty positive throughout this review, I think I’ll end with my concerns. I do not know when Gutenberg will be merged into core. I am not even sure the developers know just yet. Stating a hard deadline would probably not be a good idea, or at least not yet. Gutenberg still needs some polish, and it needs more user testing to determine which areas of the UI and UX need improving.

    There has been some backlash against the idea of putting a notification in WordPress in the next minor update for users to try out the Gutenberg editor, but I feel like that will be necessary sooner or later in order to get a good sense of what still needs to be improved before the merge proposal. I would not want Gutenberg to be released too early and with too little user testing.

    If I had to guess, Gutenberg will not be ready for a merge proposal until at least late May, and I would not be surprised if it happened in June. Development of Gutenberg has been rapid, and improvements have been a lot faster than you might think, but I am not sure it is fast enough to be ready until at least a month from now. The milestones on the GitHub page show several things that need to be completed before a merge proposal is considered, and it seems like they are sticking to that. They do not seem to be in too much of a rush to get the editor into core. I just hope there is enough user testing that happens between now and when the merge proposal happens. Of course, the WordPress 5.0 beta will bring tons more testers, but it would be nice if the majority of UI and UX issues are resolved before then.

    Speaking of user testing and feedback, I recommend posting issues on the GitHub page for Gutenberg concerning the issues you are experiencing (whether technical bugs, conceptual concerns, or things you do not like about the graphical interface), as well as checking out and commenting on the existing issues. The best way to have a say in what is going on is to go there and say something.

    https://github.com/WordPress/gutenberg/issues

    Finally, I would like to make a note about the star rating I chose. If I were to rate this based purely on what the plugin does right now and this very moment, I would give it 3 stars. But I can not act like this is all that Gutenberg will ever be or all that is currently planned to be. The Gutenberg project as a whole is a lot bigger than what this plugin does right now, and I will not be able to rate later versions of Gutenberg after it gets merged, so I am rating it right now with the understanding that this is a beta plugin for the first phase of a huge long-term project that I think will revolutionize how people build websites with WordPress. And as the first step of something as big as this, I think this is really well done. The biggest issues it has are user interface and user experience problems that require a lot of user testing to fully resolve, and the odd bug here and there that is being worked on and is to be expected from a beta plugin. The core concepts, plans, and extensibility of the project are great, in my opinion.

    Well, that is what I think of Gutenberg. I hope my review was helpful and insightful for you.

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    Thanks for the update but please do not put links in reviews. This is a review, not a blog post. 😉

    @jdembowski Thanks for the tip! 🙂

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Flawed, but always getting better, and full of potential’ is closed to new replies.