Tag Archives: Gutenberg

More Gutenberg madness (“This block has encountered an error and cannot be previewed”)

The WordPress Gutenberg project (a.k.a. the Block Editor) is supposed to make building WordPress sites faster and… well… once you get the hang of it, that often is the case. Recently I’ve actually marveled at how quickly it has allowed me to build out a site, now that my base theme is getting a bit more polished. And creating block patterns in WordPress 6 is super slick, after you learn a few of its quirks.

But then, the Block Editor will throw me a curveball that can derail things for days. For instance, there’s this:

I have a site using my custom theme that all of a sudden started throwing out this message after a recent update. It’s on the Separator block (a.k.a. a glorified <hr> tag). I took a look at the code, and there’s nothing overly complicated going on. The best clue I had to the problem was that it may have something to do with the .has-alpha-channel-opacity CSS class getting applied to the tag.

Then I noticed that in a child theme I’m building for another site, the error didn’t occur. I tried switching between the child theme and parent theme, and sure enough — with the parent theme, I get the error; with the child theme, I don’t. So… what is it?

Well… with almost any type of problem solving, it’s about trial and error, finding differences, ruling things out, and narrowing your search. But it was really hard to find anything between the parent theme and child theme that might cause this. Certainly there were no differences in how they treat Separator blocks.

I came back to that CSS class. Why is that there? Where Gutenberg is concerned, when in doubt, it’s always a good idea to have a look at the theme.json file. And, sure enough, that’s where the difference was. In my parent theme, I had this (note line 13):


But in the child theme, I had this:


Yes, for some reason, an empty array for the color.gradients setting allows the Block Editor to properly parse the Separator block, but a null value causes the error.

WHY???

I don’t know. I don’t really care. At least I was able to fix it. But this again makes me question the wisdom of the entire Gutenberg enterprise. I still don’t really buy the rationale that this JSON file is the way to go, although I am at least starting to understand why it was chosen. However I think this example illustrates some of the negatives of the approach.

Building a WordPress block theme is shortening my life expectancy

Throughout my (now quite long) career as a web developer, I have had many ups and downs. But I have never had as many stomach aches as I have in the last year, trying to wrap my brain around a steady stream of confusing, convoluted, counterintuitive and just downright inexplicable elements of building a theme from the ground up to work with Gutenberg, a.k.a. the WordPress Block Editor.

I’ve made some major progress over the course of the year, and my theme (in various stages of completion) is now powering multiple live client sites, with development ongoing for a few more. For the most part, now, I am finally at a stage where I feel like this is the right way to use WordPress going forward, rather than just reluctantly accepting that I have no choice in the matter.

But I still feel like Gutenberg does a lot of things the wrong way — most notably in its fundamental lack of separation between content and presentation. Yes, I am going to Old Man Yells At Cloud this. I know React is the new hotness and now everything needs to be done in ES6 (which I will forever call JavaScript), but the WordPress core team is throwing away some of the platform’s greatest strengths by abandoning this core component of how it (like pretty much any 2000s-era CMS) is built.

It may seem that I’m just an old curmudgeon who doesn’t want to learn React (I don’t), but it’s not just that. It’s that every aspect of this interface that has been designed to make it easier for average users to interact with — which, I think, it finally is, 5 years after it was unceremoniously forced on us — makes the process of developing for it harder, and more abstract.

There are two unrelated but connected problems with how things are going down here.

First, modern developers just love dependencies.

I get it. To an extent. Reusing tried-and-true code libraries instead of rolling your own all the time is smart. But that means you’re using code you probably haven’t looked at closely. You don’t really know how it works. It may have bugs, or it may have opaque features you don’t realize are there, or it may just have too much stuff bloating it, slowing down performance and making applications more brittle. Pile dozens of these dependencies together, and you’ve got a lumbering behemoth of code that no one in the world completely understands. And I truly do believe we are at a point where no one, at all, knows entirely how the current version of WordPress works. On top of that, any time you’ve got external dependencies, weird things can happen.

Second, Gutenberg is evolving so quickly that the documentation hasn’t kept up.

Gutenberg’s documentation is occasionally out-of-date, always incomplete, and it’s only getting worse.

I know writing documentation is tedious, and the web has never had good documentation. When I was in college in the mid-’90s and I wanted to learn HTML, I went to the campus computing department and asked them how I could go about learning HTML. They, seriously, just told me to download BBEdit. Which I did. And which didn’t help me learn HTML at all. (Although it is still the text editor I write all my code in, 29 years later.) So how did I learn HTML? View source. Because back then, you could do that.

I don’t expect to be able to just “view source” and learn how Gutenberg works. But since WordPress is open source software, and I have the files right here on my computer, I do think that when the documentation fails me, I should be able to poke around in the source code and find what I’m looking for.

Let’s get specific. As it happens, in my theme I’m addressing one of my earlier complaints above by using ACF Blocks. It’s been a rough road, but I’m starting to make really good progress. The only problem is, my styles aren’t getting applied. My CSS for the block isn’t loading in the Block Editor, and the Block Editor styles I’ve configured my block to support (colors, spacing, typography) via its block.json file are not showing up on the front end.

Well, what do I do about that?

Focusing on the front end first, I know that Gutenberg’s styles get applied courtesy of pithy CSS class names like .has-primary-background-color as well as HTML style attributes using CSS variables, like var(--wp--preset--spacing--80).

But if I look at the block attributes in the Block Editor’s comment tag, or the JSON or PHP array of style properties for the block, I see the same is formatted as such: var:preset|spacing|80

The quarter century of development experience in my old fart brain tells me that there must be a function or method, somewhere, that converts var:preset|spacing|80 into var(--wp--preset--spacing--80), and that I would be better off trying to find that function than writing my own.

Uhhh… OK. So how do I go about that?

ACF’s documentation for this feature is abysmal, which is kind of understandable, since the whole thing is a moving target that is changing rapidly (not to mention the organizational challenges that happen when the company that bought you out gets bought out itself), and the core WordPress documentation isn’t much better. So I’m left resorting to a scavenger hunt through the WordPress code. But it’s layer upon layer of 5-line functions referencing each other through a series of add_filter() callbacks.

As usual with my Gutenberg rants, I don’t have any solid conclusions to end on here. This whole post was mostly an exercise in working out that knot that was gnawing at my insides. At least I’ve done that. But I’m no closer to solving my problem. That’s probably because the real problem isn’t what I think it is. And it’s not going away.

All I know is, building a block theme — at least, for me, right now — takes way longer than building a classic theme. And I think that’s because my approach, one developer just cranking away, is not the model anyone in the core WordPress development community cares about, or possibly even comprehends existing. These days I’m not extremely confident about its continued viability myself.

Post script: I think I actually managed to find it, by using BBEdit’s multi-file search on this string: '|'

The method is: WP_Theme_JSON::get_property_value()

Of course, that doesn’t get called directly. It’s called in WP_Theme_JSON::compute_style_properties() which is in turn called by WP_Theme_JSON::get_block_classes() which itself is in turn called by WP_Theme_JSON::get_stylesheet() and then we’re getting too far afield, because that’s used to turn the theme.json file into inline CSS.

So I am guessing at this point that I probably should not use any of these methods. (Actually, I can’t because they’re all protected.) It really seems like this should be happening automatically, and either ACF Blocks are missing some key functionality, or I’m missing something about how ACF Blocks work (which I would blame on the lack of documentation).

Update (April 11, 2023): After I wrote this blog post, I also started a thread on the ACF forum, and there I was finally given an answer. Yes, there is a WordPress function for getting block wrapper attributes. It is even, um, named exactly what it should be. But as the fellow ACF user who responded with that enlightening bit of information even noted, it is incredibly difficult to find. The WordPress documentation does, to its credit, include most if not all (I mean, how would I actually know?) functions and methods, but the search tool is a joke.

Quick CSS fix for WordPress Block Editor (Gutenberg) link hover color issue

The WordPress Block Editor (a.k.a. Gutenberg) makes it easy to set the text, background, and link colors on any block. But links can and often do have more than one color. And there’s no option here for setting the hover color. So what do you do in what, I think, may be a common situation, where you’re setting a background color on a block and making the link text white, but your theme’s link hover color is either the background color you’re switching to, or something way too close to it?

I’ve come up with a very tidy bit of CSS code that will make your link hover state match the custom link color — granted, you lose the UX of a unique color on hover state, but you gain necessary legibility and accessibility, which I guarantee is more important.

This may not work in every situation, but it’s so simple that it’s worth investigating as an option. With this code, any time you have a block that sets both a custom background color and a custom link color, it will ensure that the hover/focus state matches the custom link color:

main .has-background-color.has-link-color a:focus,
main .has-background-color.has-link-color a:hover
{ color: inherit; }

Update (April 4, 2023): Yeah, don’t do this. You can specify these colors in theme.json. I’m not sure if this is a recent addition, the documentation was previously lacking, or I just didn’t find it, but anyway… do this instead.

This is the kind of thing that I find maddening about Gutenberg

First off, if you are the regular reader of this blog, you are painfully aware of how much I am waffling on rejecting or embracing Gutenberg (a.k.a. the WordPress Block Editor). There are things I genuinely do like about it, but I also have some fundamental disagreements with its approach (like the facts that it writes inline CSS directly into post content, or that its templates don’t support PHP code).

And then there are the weird little quirks that just make using it much more difficult than it needs to be. In general I have learned that this comes down to the incredible finickiness of JSON. Fine. But the fact that one character out of place in the theme.json file can break everything seems a bit ridiculous… or at least, a big step backwards for usability.

Fix your syntax. Sure. I wish JSON allowed trailing commas the way PHP — and even JavaScript! — does, but I can grok the fact that it doesn’t and learn to adapt. What I have a bit more trouble with is the problem that struck yesterday, only because it was so hard to pin down.

I’m working on a new, small block theme as a one-off for a unique project — a website that will feed menu board monitors in a pizza place. Seems like a perfect opportunity to practice and experiment a bit with what Gutenberg can do. (And, after over a decade of trying to find the “right” way to give restaurant staff a reliable but still easy-to-manage web interface for updating menu information, I actually think Gutenberg’s Block Patterns might be the optimal solution.)

So here’s the maddening thing. I was setting up my theme.json file like a good Block Theme developer, defining all of my colors, typography, etc. And then I started loading in some test content. All looked fine on the back end, in the Block Editor itself. But none of the styles were getting applied on the front end!

I googled the problem, of course, and found a WordPress forum thread about this very issue.

Huh. Sure enough, what’s described in the thread was exactly what was happening in my case. I had this line in my code (font names changed to protect the innocent):

"fontFamily": "'Helvetica Neue', 'Comic Sans', 'sans-serif",

Do you see the problem there? (No, it’s not the trailing comma… that actually belongs, in context.) It’s the stray apostrophe before sans-serif. Removing that fixed the problem.

Now, if this were just in straight CSS, I would have seen the problem immediately, because the syntax highlighting in BBEdit would’ve gone all wonky. But since this was inside a text string in JSON, it looked just fine, and I didn’t notice the apostrophe was there.

I get that the parser that converts the contents of theme.json into CSS would get thrown off by this. Honestly, I’m surprised it didn’t cause the whole page to bork with a PHP fatal error… I’m pretty sure earlier versions did throw a fatal error if there was any problem parsing the theme.json file. So this is… an improvement?

I also get that the generated CSS output would not work properly. What I don’t get is that it all looked correct in the Block Editor. Why was the Block Editor on the admin side able to “fix” this issue, but on the front end it didn’t? It doesn’t make sense!

Anyway, trying to unravel that mystery wasted about an hour late yesterday afternoon, when I was finally starting to get productive after having a near existential crisis over Gutenberg for most of the week.

These are hard times to be a WordPress developer. No, strike that. These are hard times to be a generalist web developer who happened to make the fateful decision 8 years ago to go all-in on WordPress.

Musings on my future with WordPress

Regular readers of this blog, if such exist, may have noticed that one of the three (!) posts I published yesterday has gone missing. I unpublished it this morning, as I further contemplate the future of WordPress, and whether or not I want to be a part of it.

First off, I need to make it clear that I will be a part of it, because ICS Calendar Pro has become a substantial part of my business, and I only see that growing. The question for me, however, is whether or not the rest of my business will continue to revolve around WordPress the way it has since 2014.

I’ve been building websites for much longer than that. By 2014 I had already been writing HTML for 20 years, and building websites professionally for 18. My decision to go all-in on WordPress in 2014, and abandon the CakePHP-based custom CMS I had been painstakingly crafting for the previous 6 years, hinged on my realization that WordPress was evolving quickly into a powerful, general-purpose CMS.

But therein lies the problem. I am part of a very large community of serious, professional web developers who embraced WordPress (the open source project) as a general-purpose, if decidedly idiosyncratic, Content Management System (CMS). And we’re the ones who collectively turned it into the dominant platform that it is today. But I don’t think Automattic, or much of the WordPress core team, sees it that way. They’ve never lost the original vision of it as a simple blogging platform, even though the web world has largely moved beyond blogging (at least the open source, self-hosted kind).

Automattic (the company owned by WordPress creator Matt Mullenweg) isn’t competing with Drupal or Joomla. They’re competing with Squarespace, Wix and Medium. And as such, their focus is on how to make WordPress.com (their commercial, hosted version of WordPress) into a stronger challenger to those platforms. The open source WordPress project that I and my fellow developers have grown to love is just an afterthought to that mission. Or at least, so it seems, with the aggressive pushing of Gutenberg (a.k.a. the Block Editor) since 2018, and even more alarmingly, full-site editing (a.k.a. Site Editor) this year.

Gutenberg is one thing. I started off hating it, not because it was a bad idea, but because it was a poorly executed one — or more specifically, that it was forced on the WordPress community before it was mature enough to replace the classic editor. But I absolutely believed in the idea of block editing in general. I had already been working extensively on my own custom theme that was built around ACF Flexible Content. Many others turned to “page builder” plugins/themes like Divi, Beaver Builder, WP Bakery, or Elementor.

I despise those page builders because they introduced their own, often convoluted interfaces that look and feel nothing like WordPress, and most frustratingly, are not easier for end users. The only people they’re easier for are “no code” website builders, and maybe I’m an old man yelling at clouds, but I feel like you shouldn’t be charging people money to build websites for them if you don’t know how to write code. Less curmudgeonly: These page builders require just as much work to learn as writing code does, but if you learn to code, you walk away with a much more valuable skill.

But I digress. For the sake of adding block editing flexibility to the content management aspects of using WordPress, I have no problem with Gutenberg as it stands in 2022. In fact, I’m using it to write these words. It is much nicer than the old classic editor — at least, now it is; not so much when it debuted in 2018 — and more importantly, it’s the WordPress way as opposed to page builders. Even if it’s only “the WordPress way” because WordPress has changed to be like it, rather than it fitting what WordPress was before.

I still have a major problem, in principle, with the entire concept of the Site Editor though. And the blog post I cited earlier this year feels more relevant to me than ever. I still don’t think it’s really for anybody. Except Automattic.

It’s not that the Site Editor is going to put people like me out of work. It’s that, if this is the direction things are going, it makes absolutely no sense for people like us to continue to use WordPress as our platform of choice.

Taking this thought a step further (and following the links), we get to the heart of the matter for me, which is perfectly summed up in a post called The Complicated Futility of WordPress. Specifically (emphasis mine):

The thought of client side marketing interns ‘play(ing) around with site-wide designs’ should make the blood of any professional run cold. Sites that have been painstakingly, designed and built, reviewed and refined to the last detail every step of the way with stakeholders on the client side, optimising UX, legibility, performance and upholding the client’s brand can now be squelched in an instant by someone 3 months into their job who prefers yellow.

No doubt we could work up a system to prevent this, we can restrict access and force use of the classic editor etc, but that’s where the ‘complicated futility’ comes in. It’s one thing to find a way to cherry pick aspects of the software to serve your purpose, it’s another thing entirely to try to build in complete opposition to it.

—coderjerk

For me, it’s been a difficult year of loss, with the death of my mother in September (and several months of decline preceding that), and some distance from my work. It’s also been a year when I have struggled constantly, through my efforts at building a new Block Editor-friendly theme to replace my trusty old ACF-based one, to find some sense in a lot of the decisions that have been made about how Gutenberg works and the direction WordPress is going. My low motivation, easy distraction, and generally slow progress on the theme, I am just now realizing, has been due to the amount of cognitive dissonance I was feeling, as I realized that everything about my approach to building websites as a professional developer, everything I am looking for in the tools I use to do my job, seems, as coderjerk put it, to be in complete opposition to what WordPress is becoming.

As a freelancer, I keep fairly diligent records of my time spent working on client projects. I have to. It’s how I make money. But I am not as rigorous in tracking how I use my personal time. I wish I had logged the time I’ve spent over the course of 2022 experimenting with, and then abandoning, various potential WordPress replacements. It usually only takes me an hour or two to realize that, as much as I am resisting learning the seemingly nonsensical framework (if you can call it that) for building custom blocks, block patterns, block themes, and everything else in the “new way” of WordPress, it is still probably superior to whatever platform I’m testing out that day. So I’ve dismissed ClassicPress as a backwards-looking dead-end. I’ve tried and cast aside more random niche CMSes than I can recall. (But, to prove this isn’t just empty talk, a few of them are e107, Craft, and Concrete, and I’ve even contemplated Drupal, of all things, as well as resurrecting my old CakePHP-based system.)

None of that has gone anywhere, because it was immediately apparent to me that none of them felt right. Not built on the right foundation, not polished enough, not enough momentum behind them. Well, nothing has as much momentum as WordPress. But now I’ve begun to wonder, is it momentum… or inertia?

Today’s discovery feels different. Since I agreed with so much of coderjerk’s post, I took the final suggestion of Twill to heart. I don’t have experience with Laravel, but I know that back when I was in CakePHP world, it was a big competitor. An employee of mine — in the short sliver of time when I had employees — built a custom site for a client using Laravel and he loved it. Twill is built on Laravel, so it seems fitting for me that the next chapter of my career might revolve around a return to MVC frameworks, in their much more modern, mature form. And while this gives me a lot of new stuff to learn — I’ve avoided doing much with systems that rely on Composer and managing dependencies — it all feels like the right stuff to have to learn in 2022, vs. what I’d have to learn to be a Gutenberg ace.

I’ve spent a few hours this afternoon getting the lay of the land with Twill. And while it has thrown me a few surprising challenges even in the basic setup, it’s also giving me a giddy feeling of just having fun geeking out on learning new systems… those moments of delight when I finally get how something works and I see the genius behind it. I’ve spent a lot of time trying to understand the structures underlying Gutenberg, and the only feeling that ever gives me is… “What… why???”

I plan to spend most of tomorrow continuing to tinker with my little Twill test setup. I may still end up scrapping it, and I know I will probably never completely leave the immense gravitational pull of WordPress. But I’m feeling more excited about web technology than I have in years, and more optimistic about my future in this business.