What are your thoughts on "Project Gutenberg"

general
1

I’m curious what thoughts people are having on the new Gutenberg editor.

For my part, I’ve been aware of it but, honestly, I haven’t paid a ton of attention to it. I’ve mostly been of the mindset that it’s something pretty cool that’s up-and coming and the editing experience is going to change quite a bit.

I’ve installed the beta and played around a little, but I’ve not done anything in depth and it’s been a couple of months now. I’m at a new gig and am doing zero WordPress work in my day job, but I am about to embark on a rebuild of my own site and my wife site.

Over the weekend I saw this tweet from the ACF account:
WP ACF Plugin on Twitter: “An eye opening response to Matt Mullenweg, WordPress and Gutenberg :flushed:! @gschoppe talks content, metaboxes, compat… https://t.co/s9b42zNey5”

The link is to an article by a guy named Greg Schoppe. It’s definitely worth a read if you haven’t yet.

After reading this I looked around and came across a handful more articles, including a couple more by Greg Schoppe, and truth told what I’m reading makes me kind of glad I’m not working with WordPress so much these days. I’m not going to link to all of them, but I’ll link this one from Jeff Chandler at WP Tavern: Why Gutenberg? and this one from Josh Pollock, of Caldera Forms: Five Ways I’d Like To Be Proven Wrong About Gutenberg

I don’t have the deep WordPress knowledge to know if some of these articles are overly alarmist, but it seems like the new editor is going to break a lot of existing sites. Some of the things that concern and irritate me are:

  1. Lack of user testing / user profiling (as cited in the tavern article)
  2. Lack of a clearly defined problem the project is supposed to solve
  3. Rush to market because “it’s what Matt wants” (again, tavern article)
  4. Last, but not least, the thought that tons of existing sites may be broken & will have to be upgraded

Truth told, this whole Gutenberg thing makes me kind of glad that I’m not working with WordPress at my day job and I’m on the fence as to whether or not I want to use it for my personal projects moving forward.

I’d love to hear some thoughts and insights from the Roots community. Particularly how you see Gutenberg impacting you, your clients, existing work and future work.

5 Likes
2

Greg Schoppe’s post is really good. This quote from Matt is scary:

Developers and agencies will be able to create interactive templates that clients can easily update without breaking things or dealing with custom post types: Imagine a custom “employee” block that you can add to an About page that includes a picture, name, and bio. They’ll be able to replace most meta boxes, and they’ll get a chance to update old code or clients to work in this new paradigm.

It seems like we’ve got people who don’t have any recent experience creating websites that are building the tools that others use to make websites.

This whole Gutenberg thing makes me want to get far, far away from WordPress. :expressionless:

2 Likes
3

I, and most of the Roots team, have a pretty low opinion of Matt and are pretty skeptical of most things he says. His blog post about Gutenberg was hilarious talking about printing press and making it sound so grandiose.

I don’t really know much about Gutenberg itself except that the technical implementation seems pretty terrible. It’s serialized into post_content and a lot of people including Roots member @austin criticized this choice.

4

This wouldn’t be the first time something got pushed through too quickly because Matt wanted it

While I think we all agree that any more modern editor than TinyMCE would be better, unfortunately this isn’t really it.

Exactly right.

I think most developers are actually on board with breaking changes in order to improve the code and the experience. Unfortunately Gutenberg is doing it in all the wrong ways.

I really enjoyed Greg Schoppe’s post, it nailed all the issues.

Oh, and no one’s even mentioned Gutenberg going from 0.9.0 to 1.0.0 and being all ¯_(ツ)_/¯ about it

5

Some thoughts:
There is always this layout paradigm (at least for me) which gives trouble in CMS, also in WordPress:

  • Two or more columns on page that don’t look strange in visual editor either.
  • Masonry-style customizable layout - and not just posts that are listed that way.

Some of these may be solved by using floats and cluttering the markup in the editor with extra divs/sections.

Worse than Gutenberg IMHO would be using some PageBuilder: They aren’t standardized, there is too much customization that goes around the theme.

Shortcodes can also be quite unintuitive because most plugins providing them don’t give visual feedback or a preview.
So Gutenberg would consolidate the basic page builder issue, shortcodes, floats, extra HTML elements and classes and widgets to standardized visual blocks.

On the other hand, CMS users and WordPress devs seem to be opposed to WYSIWYG / live edit features as being too complicated and/or having bad experience with them. - Hence the “boring” admin menu post type list paradigm is heavily used and praised in WordPress.
Maybe this is also the reason for the opposition that Gutenberg faces - as being too WYSIWYG / live, albeit in the admin area.

6

I think ACF will do well in this shakeup. For me, I think it’ll be years before Gutenberg is something to consider. Bummer re: Matt’s priorities.

7

I know, right?

Also, the “democratization of publishing” concept was one of the things that drew me to WordPress in the first place and lots of users will probably appreciate the “custom employee block” scenario that Matt describes, but site owners come in all shapes and sizes. A business that just paid an agency 25K for their new WordPress site is probably going to care more about enforcing a cohesive content strategy & information architecture than they will about empowering a content creator to plop an “employee bock” on the “about us page”.

The last paragraph of Greg Schoppe’s article was a fantastic rebuttal of the Gutenberg analogy -

The real innovation of Gutenberg’s press was good planning for the future (a durable alloy that would hold up under abuse) and a flexible data structure (type cases, leading, etc) that could handle unforeseen use cases. Gutenberg’s press didn’t try to imitate full-plate presses, and it didn’t try to be back compatible for existing woodblocks. It was revolutionary because it rebuilt the press from the ground up, with future-safe techniques… and yet here we are, staring down the barrel of HTML comments as an ad-hoc datastructure and an editor that still relies on content-editable wrapped in a hacky API, in 2017.

I totally agree, Gutenberg also seems like the wrong breaking change. I mean, Matt Mullenweg says

Core developers will be able to work in modern technologies and not worry about 15 years of backwards compatibility.

It was that one that made me almost spit coffee all over my iPad. I mean core is still PHP right? Still needs backwards compatibility back to PHP 5.2, right? Modern technologies as long as you’re not a PHP developer?

As for the modern technologies, the issue with React’s license still remains unaddressed. There’s an open GitHub issue addressing this, here, and according to MM there’s going to be “more to announce” about this issue, but seriously? With development moving at the pace it’s moving what’s going to happen other than an announcement telling the community “React it is!”.

I guess this is entirely off topic, but what else is out there, for the small to mid-size site market? I’ve been dipping my toes into Drupal 8 at my new job but it seems like overkill for the smaller sites that WordPress really excels at.

I’m going to look at Craft for my wifes site, and maybe for my personal blog. Maybe I’ll move my coding blog to a static site generator or flat file CMS.

I dunno, hopefully I’ll look back on this post in 6-8 months and be like “man, remember that time I was freaking out for nothing?”.

1 Like
8

A standardised Page Builder sounds fantastic but the way this is being forced through seems really ham fisted.

For as long as I’ve been using ACF+WP I’ve wished the ACF dude just made his own CMS so we could do away with WP entirely.

9

I’ve been using Beaver Builder in recent projects to give my designers the (seemingly infinite) flexibility they need without having to go through a whole round of development every time they want to put an image on the left instead of the right.

A standardized “page builder” is appealing, especially if it could mean standardized libraries of “blocks” we could include. The Bootstrap grid, buttons, and cards would cover about 95% of what I need to lay out in a given day, but if I have to build all my blocks on every project myself that’s less appealing.

I hope for the best, because I think it’s clear that TinyMCE isn’t cutting it.

10

New post from Greg Schoppe on how he would handle Gutenberg :+1:

https://gschoppe.com/wordpress/the-gutenberg-that-could-have-been/

4 Likes
11

I’ve been playing with Grav CMS lately, there’s a lot to like about it (over WP). Haven’t used it in production yet, but I’m seriously considering it for smallish company websites / blogs.

1 Like
12

I’ve been thinking about this, and the impression that Matt is forcing this idea through without proper planning.

The more I think about it, the more I see TinyMCE and WP’s default editor experience as a liability. If you look at this thread, and this forum, we’ve all found our own ways around the inadequacies of the editor by employing other tools. That doesn’t look good for Core.

On top of that, I think we conflate different tools here because we’ve used so many of them to solve this problem for so long: ACF (and Custom Field Suite, and Carbon Fields) aren’t layout tools; they’re custom field tools. We’ve all come to use them as layout tools, incuring heavy development costs to build all the templates when we do, but while ACF is great for adding structured data, like a price or a size for a product, it’s the wrong tool for adding a strap mid-page; that’s a page builder’s job.

But the page builders available are even less standard than the custom field tools, as we’ve touched on higher in this thread.

So Core is in a bind here: to get modern layout tools, you have to buy a page builder, or spend heavy development time on supporting complex custom fields layouts.

And so I get where they’re coming from.

Yes, their implementation may be problematic but I understand the reasoning, and even the urgency, behind it.

2 Likes
13

Grav looks nice. How do you deploy it?

Since using Roots I’ve immediately lost interest in any CMS that recommends FTP as a method to deploy.

14

I played around with Grav over lunch today, that’s definitely pretty nice. Delicious Brains recently did a review of Grav as well as a review of Craft, if anyone is interested.

I’m sure you’d be able to use a deployment tool, like Dploybot, or script something on your own. It’s funny man, I was going to mention that one could conceivably just fork Trellis and use it to deploy Grav, and it looks like someone already has. - GitHub - afonsoduarte/ansible-grav: A collection of ansible playbooks for a LE(M)P stack for Grav

Your mileage may vary, I came across that whilst googling “deploy grav ansible”. :slight_smile:

2 Likes
15

I know WordPress has never adhered to semver, but that really bothered me.

1 Like
16

If you’re looking at flat-file CMSs, Grav is an absolute joy to work with.

17

I’ve been looking at Gatsby for future projects. It uses GraphQL to pull in data, so your “source” content can come from pretty much anywhere. It wouldn’t be too hard to use or build a backend that would fire a webhool on “publish” and trigger a rebuild of a Gatsby site automatically.

2 Likes
18

I’ve had a look at Gutenberg and I didn’t like the approach in the architecture myself (although the editor app is very nice). The article that ACF and the OP linked to is very good.

I’ve been using ACF (PRO) for a few years. It’s the #1 plugin I install before anything else. I integrate things like the options page and custom fields to affect pieces of information that a client can input into the backend to customise and display information on the frontend.

ACF has supported “flexible content” for a while, and I’ve experimented with it in the past only a small amount. However just recently I did a lot of research into plugins like Divi Builder, Visual Composer and Gutenberg and was really disappointed with them all.

The commercial plugins (Divi Builder and Visual Composer) performed poorly regarding their questionable practices regarding usage of unreadable shortcodes in the post_content field and poor CSS implementation (custom themes have to write lots of CSS with !important and nested #id selectors to overwrite the plugins’ CSS) and Gutenberg doesn’t have a great approach by embedding HTML comments and code in the post_content*.

I’ve been recently experimenting with creating an extensible approach to defining page layouts using ACF’s flexible content field with pre-defined re-usable layout blocks, e.g. text, image, carousel, etc. You can see the current progress of my experimentation, along with an idea of where I want to take it: https://github.com/lvl99/acf-page-builder

The whole point of my experiment is to create a drop-in page builder layout system that works off ACF’s ecosystem of custom fields and inputs. At the moment it relies on ACF’s backend UI to input and customise the layout, but the idea is to abstract some kind of REST API that a frontend client editor app could be built around. I’m hoping that it means that multiple frontend editor apps could be made, depending on features and people’s personal preferences.

I’m really interested in getting other people’s input regarding this small project, as I think it could be a great alternative to something like Gutenberg, changing nothing with how post_content is entered.

(*) Personally I see post_content as a basic textual representation of the post content – think like the plain text/MarkDown version. If a page requires a custom layout, then that custom layout information should be stored in the post’s meta data, and when the_content is rendered that it would serve the post’s content rendered via the page builder. This means there would still be an accessible plain-text version of the page when rendering RSS feeds and/or AJAX/API stuff, or any type of non-presentational situation would occur.

19

I’ve been experimenting with Grav too.

It’s really nice, but quite young and there are still some rough edges.

There is no way (at present) that it could replace WP for anything other than simple brochure or blog type sites.

Having said that, I am hooked on the simplicity of working with flat files in the filesystem so will be watching closely. Give it another year and it could be a serious contender.

In the meantime, I can’t help but think that Greg Schoppe’s proposed roadmap would be the perfect answer to Gutenberg.

A fork of WP that includes all the Roots posse on the core team would be the best of all possible worlds.

4 Likes
20

Cross posting: