Tag Archives: Gutenberg

Gutenberg: How is this better?

Every time I run into another weird, seemingly illogical quirk of the process of building a WordPress theme with Block Editor (a.k.a. “Gutenberg”) support, I ask myself the same question: How is this better?

As time goes by, the answer is starting to come into focus. Unfortunately, it’s not entirely satisfying.

Here’s what I’ve learned so far.

How is this better than what came before?

Well… what came before? You can’t ask the former without first answering the latter.

Over the years, WordPress has become many, many different things to different people. So you can’t expect the Block Editor/Gutenberg to be universally better (or worse) than what it’s replacing, because it’s replacing so many different things.

Is it better than the various “page builder” plugins out there? I’m looking at you, Elementor, Divi, Beaver Builder, and WPBakery, among others.

Honestly, I loathe every last one of these page builder plugins. Partly that’s because before I worked primarily with WordPress, I rolled my own CMSes for years, dating back to the pre-.NET Microsoft era of ASP talking to a SQL Server 7.0 database. Then I moved to MySQL and PHP, first building a completely custom system before any MVC frameworks existed, followed by several years of development on a fairly robust custom CMS based on the CakePHP framework. I was very proud of that work, but by 2014 it was clear WordPress (which I had used for my own blog and occasional client projects since 2006) was picking up enough steam as a general-purpose CMS that my own couldn’t keep up, and I took the WP plunge.

Almost immediately, I wholeheartedly embraced Advanced Custom Fields as my solution to extend WordPress. And, in particular, I used its Flexible Content fields to create my own Block Editor-style interface, years before Gutenberg existed.

It’s way better than page builders.

But it’s also not entirely “the WordPress way.” It’s way more “the way” than Elementor and its ilk, but still… it led to a situation where all page content on my sites is stored in the wp_postmeta table, which is not ideal, for many reasons.

What’s good about the Block Editor?

I absolutely, 100% prefer the Block Editor/Gutenberg over the popular page builder plugins. It’s a much cleaner, faster, more intuitive user experience, and it renders front-end pages quickly. It’s built in which is a benefit in and of itself. But honestly, it only feels built in because WordPress is changing itself to be more like Gutenberg, rather than Gutenberg being built to feel like the WordPress we know and love.

Aesthetically, I like the Block Editor. For usability… well, where do I begin? I’m an old fart who still expects all of the available options to be visible on-screen, not just “discoverable” if I happen to hover my mouse in the right spot. And I’m a lot more savvy to this new type of interface than most of my clients, so I struggle to understand how the WordPress core team thinks this is an optimal approach. (OK, so maybe this paragraph belongs in the “bad” section below.)

But that leads me to the best thing about the Block Editor, which is not inherently great. It is what it is. I don’t mean that as the empty cliché we hear a thousand times in every business meeting or reality show interview. I mean it literally: The Block Editor is WordPress now. There’s no going back. So while that may mean some growing pains and struggles, it also does mean that it will (probably) continue to get better over time, and unless it is an absolute failure, WordPress will continue to grow, which means it will always continue to receive support.

What’s bad about the Block Editor?

This is another one that really depends on your perspective: where you’re coming from, what you’re used to, what role you play in the creation of a website.

If you’re a content editor who is a capable system user but not a developer/UI designer, and you’re used to the “vanilla,” TinyMCE-based WordPress classic editor, there’s a very high probability that you will be confused, overwhelmed, and/or frustrated by the Block Editor, because the concept of “blocks” does not reveal itself in the most optimal way as you are discovering it. (I’m not sure what the most optimal way is, but I’m confident this isn’t it.) I will say, however, that the glitchy, wonky, invasive behavior of earlier iterations of Gutenberg has almost entirely been smoothed out.

On the other hand, if you’re that same content editor, but you’ve been forced in the past to work with Elementor, Divi, Beaver Builder, WPBakery, or something similar (and, if you have, I’m almost certain you hate it, based on anecdotal observations), then I think there’s a good chance you will love the Block Editor, at least if you’re given the opportunity to experience it in its pure form, not something that’s been bastardized the way those aforementioned plugins destroyed the classic editor.

But me? I’m a developer. Although I obviously spend a fair bit of time using the editor to test my work and also to assist in initial content loading on new sites, I mainly work behind the scenes, in code. And this is where I struggle mightily to understand just what the hell were they thinking??? with some of the decisions that went into how the Block Editor functions at a code level.

What’s it like to code for the Block Editor?

There are two main ways in which building Block Themes and/or coding for the Block Editor differ greatly from the “classic” way WordPress has functioned up to this point.

First, at a more surface level — in fact, it’s a level you can even stumble upon in the Block Editor itself if you click the right (wrong?) button — there’s the block markup, and how it gets stored in the database.

There is something that is absolute genius about this. In fact, conceptually it’s probably the biggest Eureka! moment of the entire Gutenberg project. All of the meta data about each block is just HTML comments. That means that all of the actual content of a page/post built with the Block Editor is stored where it should be in the database: in the post_content field of the wp_posts table.

This is much better than the way Advanced Custom Fields works. It’s fewer database queries, so it’s faster, and it’s where the content “belongs” so it’s automatically handled correctly by plugins — anything from Relevanssi for custom site search tools, to Yoast SEO for search engine optimization. (OK, those are both search-related, but in very different ways.) And the use of HTML comments for the meta data means it’s even backwards compatible: if the content gets loaded in a theme that doesn’t support the Block Editor, it may not look exactly right, but your content will at least still be on the page, in its entirety.

The problem is, the code itself is kind of a mess. I like the idea of using HTML comments to store the block meta data, and I like the use of JSON as the format for the properties.

But it often ends up being a lot of code, which is messy if you ever need to look “under the hood.”

And it’s fairly brittle, so if you edit any of it directly, you’re probably going to break it, and at this point the Block Editor only has middling success at recovering “broken” blocks.

And the documentation so far is woefully lacking. I know only too well how hard it is to make the time to write proper documentation, but when you’re forcing a change this radical on a user base this large, you need to prioritize it.

And worst of all, all of that JSON code is really only to get the editor to “remember” the settings for the block when you go to edit it. Most of the details also have to be repeated in the class attribute for the container HTML element in order to actually render anything stylistically in the page. (Once again, I don’t really know the optimal solution, but this isn’t it.)

And. And. And. And. And. (Sorry, wrong software, but since it’s timely I thought I’d throw it in there to amuse myself when I re-read this post in a few years.)

OK, all of that was only the first way the Block Editor differs greatly from the classic WordPress developer experience. The other way is the template structures that go into a theme.

I’m pretty flexible about how code files should be organized, as long as they are organized. Each project is unique, and as long as it has a consistent internal structure, it doesn’t have to be the same as every other one. I know this attitude is somewhat heretical in certain circles, and honestly the fact that WordPress has heretofore been just as flexible has created a lot of headaches for people trying to understand how themes, plugins and the WordPress core interact. It can also make it exceedingly difficult to jump into a custom theme someone else built and figure out where the hell everything is.

I get it. And I appreciate the core team’s efforts to impose a new, consistent structure that reinvents the way WordPress themes are built, and that aligns with how the Block Editor works.

I also get that it was not just an arbitrary decision to build the Block Editor on React. The Block Editor needs to be dynamic in a way the classic editor is not, so a purely PHP-based interface would not work. Not even something using the already-present jQuery would do the trick.

But building the Block Editor on React requires developers to know or learn React. I’m all for people learning new skills and adapting with the times (even though I haven’t bothered to learn React yet), but it’s a tall order to force an entire development ecosystem to radically shift gears.

That’s not even my biggest criticism though. What really bothers me about the new Block Theme template structure is the move away from PHP in areas where server-side scripting clearly offers some major benefits, with only the most nebulous justifications for the change. It usually comes down to “PHP is too intimidating to users,” but I find that really hard to accept, because PHP is much easier to learn, especially to a “dabbler” level, than React, and it’s way more forgiving than JSON.

So far my work on a new Block Theme hasn’t even touched React (partly thanks to my good old friend, Advanced Custom Fields). I’m coming around to the theme.json file, the more I work with it. I still want to be able to use PHP to dynamically set site properties, but I’m learning, little by little, how to accomplish my goals without it. (Or, perhaps, I’m changing those goals to suit the new platform.) I’m also slowly coming to understand that theme.json is mostly just for generating the inline CSS Gutenberg outputs in the <head> (and some ancillary functionality in the editor itself), and not a comprehensive spot for all manner of site parameters.

What I really do not understand, and may never accept, however, is the decision to make the files in the templates folder plain HTML files instead of PHP. In fact, my struggles with this very issue are what prompted this entire rant.

How do I use translation functions on hardcoded text in the templates, without PHP?

How do I selectively display post meta data — like author, publish date, and taxonomies — for posts in the search results template, but not for pages, without PHP?

I don’t have answers to these questions. Yet. But they beg the larger question of why the templates aren’t written in PHP in the first place. Is it a performance thing? That might be justifiable. But the whole “ease of use” argument makes no sense. A person isn’t going to be creating a theme in the first place if they don’t know some PHP.

No, I think it probably all comes down to being a decision that’s part of the development roadmap for Full Site Editing. So the decision is more about what the core team wants than what I want. Fair enough.

Who is this really for?

This is another grand question. Who is the Block Editor really for? Who is WordPress really for? I had never really asked that question, rhetorically or literally, until the Gutenberg project.

WordPress started out as blogging software. But it has since become much more than that. It famously powers somewhere around 40% of the web. Are 40% of websites blogs? In terms of sheer number of sites, maybe. In terms of amount of traffic, definitely not.

WordPress powers everything from the most obscure blog no one but its owner reads (don’t look at me) to massively popular sites that have thousands of simultaneous users. And it’s not just blogs. WordPress may not have been designed to be a general-purpose CMS, nor, in many ways, is it ideally suited to that purpose, but historically it has had the right mix of flexibility, extensibility, ease of use, and low barriers of entry, that it has come to be used for just about any purpose one might imagine a website serving.

But who is it really for?

I’m reminded of the story (recounted by John Gruber on a recent episode of The Talk Show) that Steve Jobs apparently pushed for the creation of the iPhone because he wanted a way to check his email on the toilet. The iPhone is, in the most generous sense, for everyone. But in a particular way that was critical to its actually coming into existence, it was for Steve Jobs and his bathroom correspondence habits.

So again, who is WordPress really for? Who’s making the decisions that ultimately determine what goes into it, that define what it is? That of course would be the core team, and probably more than anyone, the leader of the core team, Matt Mullenweg. I don’t know much about Matt, other than that he spearheaded the initial WordPress project (at least once it was forked from b2), that he now runs the semi-eponymous Automattic, and that we most likely have very different senses of humor. (Consider this: I’ve written a plugin that partly exists to remove humor/”folksiness” baked into WordPress that I am pretty sure is attributable to Matt.)

Matt still leads the core team, and has final say on certain decisions about its direction. Ultimately, if he thinks something matters for WordPress, it makes it in. And he clearly believes WordPress is still primarily, if not entirely, for blogging.

Again, maybe in terms of number of sites, “most” WordPress sites are straight-up personal blogs. But in terms of an active ecosystem, a development community of people who are able to make a living building WordPress sites, who comprise a thriving professional industry, in my experience, at least, blogging is peripheral or absent entirely from most professional applications of WordPress. It’s a general-purpose CMS, first and foremost, even if that’s not what it was originally intended to be. And, sadly, even if that’s still not what its core development team prioritizes.

I don’t know. I’m just me. A solo, somewhat iconoclastic developer who likes to do things their own way. I’ll probably never embrace putting spaces inside the parentheses in my PHP code, and I definitely won’t use if: endif; constructs.

I have strong opinions, but I’m not an idealist.

I just want PHP in my damn templates. Is that too much to ask?

Ironic side note: This site is one of the few cases where I have built a WordPress site that absolutely is a blog, full stop. And it’s not using Gutenberg, because I set up the Classic Editor plugin on it ages ago. But as I write and edit this post, I’m actually finding myself wishing I had the site running Gutenberg instead of switching between the back end and the front end. Of course, that’s because I always write my posts in plain HTML rather than the visual editor. I said I’m an old fart.

Trials and tribulations with WordPress Block Themes and Full Site Editing

Where do I begin? For years I have resisted and rejected everything stemming from the Gutenberg project. I felt it was the wrong direction for WordPress. I felt the WordPress core team doesn’t understand how people who make a living building WordPress sites really use it. I felt they were digging in their heels on the idea of WordPress as a blogging platform, as if that were as relevant today as it was 15 years ago, and that they were in absolute denial over the fact that the most dedicated users of WordPress are actually professional website designers and developers who use it not as a blogging platform, but as a general-purpose CMS.

Of course, my feelings on the matter are utterly irrelevant, because I am not an active member of the core team development community. The people who actually build WordPress are the ones who decide what it is. I am the one who is incorrect, even if I believe the decisions they are making are the wrong ones for the health of the platform.

Then again, I’m a pragmatist, not an idealist. As much as I disliked details about the implementation of Gutenberg, I certainly did not disagree with the idea of a block-based approach to web design. I’ve been calling it “Modular Design” and I’ve been a proponent of it since well before the Gutenberg project existed. And as flawed as I felt Gutenberg’s implementation was, even in its early beta form it was way better than the shit sandwich that is every other “page builder” type plugin. (Elementor, WP Bakery, Divi, Beaver Builder, etc.)

An unsolvable problem is that there is no way for a visual web page design interface to both be simple to use and extremely flexible for all possible design ideas. HTML/CSS offers nearly unlimited possibilities for the appearance of every element on a web page. But taking full advantage of that flexibility still relies on being able to write code.

Every visual tool that exists for web page design must balance design flexibility against interface usability. The more a tool offers flexible design options, the more overwhelmingly complicated the designer interface will be. An interface has to be “opinionated” (in the common parlance) in order to be usable. It has to limit the options presented to the user, and have certain decisions baked in.

Page builders are a disaster in this regard. Without exception they have leaned towards maximum flexibility, resulting in cumbersome, overwhelming interfaces that are often harder to learn than writing code. I have been lamenting for years that so many people are so desperately fearful of learning to code, for fear that they’ll “mess something up,” not realizing that a) the GUI tools they use are harder to understand than code is, and b) they’re even more fragile if you “mess something up.” Unlike with writing code, if you colossally hose up your design in a page builder, you almost certainly can’t just Command-Z your way back to how it was.

Now, where was I?

Ah yes, Gutenberg, the Block Editor, Block Themes and now the emerging Full Site Editing in WordPress 5.9 and beyond. At last, WordPress has a full visual editor for everything!

Uh… no.

For the past several years I have been building WordPress sites using my own custom-built base theme, which has relied extensively on Advanced Custom Fields, and in particular its Flexible Content fields. But some elements of this theme are getting a bit long in the tooth and need to be rewritten (especially the CSS for the header and footer), and I have been wanting to ditch the Flexible Content fields and embrace the Block Editor for page content.

So, why not go all the way and create a brand new Block Theme that fully embraces Full Site Editing? I know it’s technically still in “beta,” but it debuted in the WordPress core in 5.9, so it must be fairly close to “ready for prime time,” right?

Uh… no. (Again.)

It really doesn’t help that you can hardly find any discussion of Full Site Editing that doesn’t breathlessly proclaim its unequivocal greatness. FSE gaslighting is everywhere.

Full Site Editing is an intriguing idea, and there are parts of its interface that look quite nice and appealing. But it is so, so far from being complete that it is a) egregious that they’re calling it “beta” and b) absolutely inexcusable that it is not only rolling out in core, with an “Edit site” link showing up in the admin bar for any site admin to fuck with (and I use that blunt term because it’s the only way I can convey how reckless an addition I think it is at this point), but that it shuts off the Customizer by default unless your theme or plugins specifically enable it.

To say I am feeling let down by FSE is an understatement. But, fine. I don’t need it. Just tell me how I should build my block theme in the meantime, because, you know, I’m actually building sites right now and not just tinkering around while I wait for the core team to finish.

Good luck with that.

I have now been working for the better part of two weeks on building my new theme, and I have been constantly struggling with so, so many aspects of this. It’s not just an evolution of WordPress, it’s really a completely different system that is taking over what used to be WordPress, using entirely different tools. And the documentation I’ve found so far has been scattershot and utterly lacking. (Carolina Nymark’s excellent Full Site Editing website notwithstanding… that’s the only thing that has helped me get this off the ground at all.)

My biggest problem is that the things that I need and feel are important in a theme seem so far removed from the things the core team has focused its attention on. There’s so much seemingly unnecessary convolution in parts of the system that I never even use (author archives? really?), and so little of it aligns with any aspects of how I usually go about designing and building a site.

I found myself falling into a trap of creating a bunch of Advanced Custom Fields option pages, until I finally realized that I was not accomplishing my goal of embracing the Block Theme philosophy, and I was not really getting anywhere. Eventually I realized that some of it is my own bad habits, and I needed to take a step back.

Rather than building a colossal theme with tons of configuration tools (most of which will probably only ever be used by me), I need to use the knowledge I’ve gained over the past several years of working with clients on my existing theme.

Speaking of my existing theme, it consists of five main components, most of which rely heavily on ACF:

  1. Flexible Content fields for block-style page editing
  2. Options pages with site-wide configuration
  3. Special-purpose/reusable content blocks (banners, modal overlays)
  4. Customizer settings
  5. A “tweaks” plugin for site-specific design, functionality, CPTs, etc.

Reinventing my tools in a new block theme, I’m finally recognizing that I need to differentiate the aspects of the theme my clients actually use from the aspects that are really only for me in configuring the site. The clients only really touch #1 and #3 from that list. #2 and #4 are tools I created with an idealized view that clients would be able to customize their own sites, but over time it has become apparent that I’m the only person who ever uses them. And #5 really underscores the fallacies and flaws in this approach: it’s a catch-all of CSS that’s too complex for the Customizer, along with functionality that truly does belong in a plugin, but a lot of it should more properly be in a child theme, except I couldn’t use a child theme because I depend so much on files in the acf-json folder that won’t get loaded if there’s a child theme.

Moving away from ACF as a content editing tool (though I won’t do away with it entirely — it’s great for things like an options page where clients can plug in their phone number, hours of operation, etc., plus I plan to use it to create custom blocks without having to learn React) will eliminate some of the issues that came with building so much of the theme around it.

And, more importantly, recognizing that I was using a lot of ACF for settings that only I ever touch, I realized I do not need to make those settings, like color palettes, fonts, etc., editable in the admin interface. And as it happens, those are exactly the kinds of settings that go into the theme.json file of a block theme.

It’s taken me nearly two weeks of tinkering, following dead end paths, mulling things over, staring into space, waking up in the middle of the night, and moments of nearly jumping out of my skin with stress, to finally realize what maybe should have been obvious: that I just need to create a parent theme with my general configuration, and child themes with each client’s unique colors, fonts, etc., and put all of the stuff that only I ever touch into the code instead of the admin interface.

It can be hard to see the forest for the trees sometimes, and I’ve definitely been struggling against that over these past two weeks. But it doesn’t change the fact that FSE is not ready. What it does do though is answer the question, Who is Full Site Editing for? It is not for me, and probably never will be. But that doesn’t matter for my work, after all.

The Obligatory WordPress “Gutenberg” Editor Hot Take

Of course you knew I’d have to make a Steve Guttenberg joke to start this off. But maybe there’s something to it. (Side note: I just realized his last name has two “t”s, unlike Johannes, the inventor of movable type.)

I’ve been a professional web developer since before the term existed (1996, to be specific). I’ve been using WordPress for my blog since 2006, for occasional work projects since 2008, and as my primary web development platform since 2014. Working solo and being an introvert disinclined to participate in conferences, my contribution to the WordPress community has come mainly in the form of submitting a handful of plugins to the Plugin Directory. And, of course, writing a ton of blog posts here on various obscure problems I’ve encountered along the way.

I say all of this solely to establish whatever credibility I may or may not need in offering my half-baked assessment of what is, at the time of this writing, a half-baked WordPress plugin… but one that is destined — in short order, and for reasons that are up for much debate — to become the fundamental user experience of writing in WordPress.

If you’re unfamiliar with Gutenberg, here’s the plugin project in GitHub, and here’s a recent blog post by Automattic founder and WordPress development lead Matt Mullenweg defending the rationale for the project, and here are a bunch of other reviews of the project, both pro and con, that I’ve read over the past three days.

So far documentation is (understandably) scarce, but I’ve poked around a bit to learn what I can and see how I might be able to customize it to meet my needs as a web developer building custom themes for clients.

I have a few things about Gutenberg that I’d like to explore with this post:

  1. My initial reaction to the Gutenberg interface itself
  2. Thoughts on how this will affect the work I do
  3. Opinions and speculation on the motivation behind the project

Getting to know Gutenberg

Some of the reviews I linked to above are critical of Gutenberg, in ways I don’t think are entirely fair. Mainly because, yes, this is beta software. In fact, at this point I’d say even calling it beta is generous. This feels more like alpha testing, given how much of the development is still incomplete, and how much things are changing. I just downloaded version 0.9 yesterday and version 1.0 is already out, with a number of significant changes, including some that broke work I was doing on custom CSS styling for Gutenberg output just this morning.

The point is, there are plenty of things to criticize about how Gutenberg works at this point. But it’s important to consider whether or not those are things that are intended to be the way they are, or if they’re just incomplete features or unaddressed bugs. Here are a few of my favorite examples:

First, a screenshot from the special “Demo” page included with the plugin to help users familiarize themselves with how Gutenberg works.

Um… OK. Which “really wide” button would that be now?

One of the demo blocks is an image, and its caption suggests you try out a feature that — as far as I can tell — doesn’t yet exist. This should be your first sign that criticism of the tool may be, at this point, a bit premature.

Gutenberg is full of fun surprises, like things randomly breaking with no real explanation. Welcome to beta software!

Oh this poor, suffering block. Also “previewed” is an understatement. When this error appears, it also means you can’t edit the block in question. Hit Refresh and hope for the best!

But I think the real coup de grâce is the lack of polish on some fringe elements, such as how the text block you’re editing might randomly bounce around the page if there’s a floated image preceding it, as the editing tools surrounding the block you’re typing in appear and disappear. Or this… the beloved triple scrollbar!

Which one does what? Just scroll and see!

I’ve also discovered a fun bug that randomly inserts question marks when you switch italics on/off with keyboard shortcuts. But you don’t see them in Gutenberg, only in Preview mode. And then if you try to delete them in Gutenberg, it just starts randomly eating your text. That’s forced me to go into raw Text mode a few times in this very post to clean up Gutenberg’s mess. (Yes, my secret is out… I’m using Gutenberg to write this post!)

Many other reviewers have noted some of the drawbacks of Gutenberg’s features. It’s still not true WYSIWYG. It seems to want to be direct in-page editing, so why isn’t it that? Many elements are still dependent upon your theme for proper styling (like the margins below captions on this post — but I will probably have fixed that in my CSS before you are reading this). A lot of the blocks don’t really offer many styling options, which seems a bit self-defeating.

And, of course, it seems at this point that it will completely break the old “metabox” concept of the editing screen, and thousands of plugins and themes as a result. I really don’t know how the core team intends to resolve that issue, although sidebar metaboxes seem to be handled under the Document tab in the Settings sidebar. A lot of popular plugins (Yoast SEO, anyone?) that rely on more horizontal width will need to be drastically rethought to work in that context, though.

This leads into my next topic: how will Gutenberg affect the work I do as a web developer?

So… how will Gutenberg affect the work I do as a web developer?

My initial gut reaction to the news of Gutenberg was that it seemed to be eliminating the reason I exist in the WordPress ecosystem. As a developer specializing mostly in custom theme development for clients, it looked like Gutenberg was going to destroy my business. And as an occasional contributor of free plugins to the WordPress community, it looked like Gutenberg was going to create a lot of unnecessary (and unpaid) work for me, rebuilding my plugins to function in this new paradigm.

The latter may well be true, but the former won’t. Gutenberg does nothing at all to eliminate the need for theme developers — it just changes how we do a few things. And, importantly, the ability to create custom block types opens up new opportunities for developers of both themes and plugins to invent new ways of both displaying and working with content in a WordPress site.

The two big questions I’m left with, which are not yet answered, are:

  1. Is this really an improvement over the existing TinyMCE editor, for developers and clients who are using WordPress not as a blog platform but as a general-purpose CMS?
  2. Is it worth adapting to this new way of doing things? Or is this effectively Automattic showing me the door?

Pondering these questions takes me to my final topic…

Why this? Why now? Why at all?

I suppose there’s a “Who moved my cheese?” element to this. After all, I’ve spent the past two years honing my concept of modular design and the first eight months of 2017 perfecting a reusable core theme that relies heavily on Advanced Custom Fields (specifically, Flexible Content blocks) and the WordPress Customize API to achieve many of the same things Gutenberg does. My theme offers considerably more flexibility and formatting options than Gutenberg does, though I will readily acknowledge that Gutenberg seems easier to use than my heavily customized ACF Flexible Content blocks are.

The point is, I am already deeply immersed and heavily invested in a particular set of tools that are intended to achieve many of the same aims as Gutenberg, and that, in some ways, do a better job of that.

But wait, what really are the aims of Gutenberg? Who asked for this? Who is it benefitting?

While Matt Mullenweg talks big about how it will benefit practically everyone in the WordPress ecosystem — developers and agencies, plugin developers, theme developers, core developers, web hosts, and (last, but… not least?) users — it seems clear to me and to a lot of other critics of the project that the primary beneficiary is Automattic itself.

I find it curious that this project is named after the inventor of movable type, since one of the earliest WordPress competitors is called… Movable Type. This project is transparently an effort at fighting back against the likes of Wix, Weebly, Squarespace and Medium, each of which has in its own way been eating away at the potential market for WordPress.

But, you know, I cringe a bit at talking about “markets” when we’re discussing open source software. And that’s the crux of the problem. WordPress has, for many years, existed as a Jeckyll-and-Hyde duo of WordPress.org — the open source project underlying self-hosted WordPress sites and the huge developer and designer community of which I am a part — and WordPress.com — the commercial, hosted, software-as-a-service (SaaS) platform owned by Automattic.

That list of SaaS platforms I mentioned above — Wix, Weebly, Squarespace and Medium — represents competition to both sides of the WordPress dichotomy, but in significantly different ways.

To the open source WordPress.org community, they’re — mostly — competition in that they represent the “low end”. Small businesses and organizations that have limited budgets or a determined DIY ethic are inclined to use them, until they realize how quickly they are hamstrung by the limitations of the tools they offer. Then those businesses and organizations hire designers and developers like me to take their websites to the next level, and we use WordPress as a way to build exactly what they need, because its open architecture and self-hosting mean there’s no limit to our ability to customize WordPress to do exactly what we need. They are also a more ominous existential threat to our businesses, because they’re constantly improving, and eventually they won’t be so limited in ways that work to our advantage. So to that end, we need WordPress to evolve. But Gutenberg seems in some ways to be WordPress skating to where the puck is, rather than leapfrogging the competition, to mix metaphors.

But to WordPress.com, those SaaS platforms are much more direct competition, because they are offering exactly the same thing that WordPress.com offers: a hosted platform with limited customization capabilities. I have steered a number of clients away from Wix or Squarespace over the years, but I have steered just as many away from WordPress.com, and for the exact same reasons.

Medium is another story. In that it’s literally about stories. Automattic is definitely feeling the heat from Medium, but this is a world apart from the scenarios I described in the two preceding paragraphs. Medium is challenging WordPress.com specifically as a blogging platform.

It’s true that WordPress started as blogging software. But over the years it has become so much more than that. I have built over 100 websites on WordPress since switching to the platform full-time in 2014, but every single one of them has used WordPress as a CMS, not as a blog. Hardly any of those sites even have blogs. A key feature of one of the plugins I created, in fact, is to hide the Posts and Comments items in the WP admin interface, since hardly any of my clients use them.

Anecdotal evidence is not data. I wouldn’t suggest that my business use case for WordPress as a CMS necessarily means it should no longer be thought of primarily as blogging software. But I am hardly alone, and I’d be willing to bet that a large majority of my fellow developers who have made a substantial part of their career in client services, using WordPress as the underlying technology, would agree with me. Because… wait for it… blogs don’t make money. OK, a few do. But there aren’t enough profitable blogs to warrant an entire industry of paid designers and developers to build them.

This has been the most jarring aspect of the whole Gutenberg debate for me… the realization that Matt Mullenweg still thinks of WordPress primarily, if not exclusively, as blog software. And it seems that his singular passion is really what’s driving Gutenberg, above all else.

I do think Gutenberg, when it has a few more layers of refinements and polish, will be a superior content editing experience to what the current implementation of TinyMCE offers. But it is a huge change, and I don’t think it jibes with the way most WordPress.org sites use the platform. That’s not to say they can’t or won’t adapt. But it also says nothing about why they should.