Tag Archives: JSON

Surely you can’t be serious: Does Gutenberg REALLY do this???

I’m building a pair of new WordPress sites for a client, using a base block theme I created. My plan going in was to create two child themes, one for each site. But after I finished the first site, I realized that the differences between the two were entirely cosmetic, so I thought I would use the new global style variations feature to just create one child theme for both sites to use, letting the sites have their own separate theme.json files via the styles folder in the child theme. (Let’s call them site1.json and site2.json.)

The problem is, I have a few site-specific code customizations beyond what can be handled in the theme.json file. And, more importantly, I want to hardcode which style variation each site uses. No need to muck around with the Site Editor (a.k.a. “Full Site Editing”). I do not want the client to have any access to that feature whatsoever.

So, I figured… OK, I’ll create a constant based on the domain, to tell me which site we’re on. I can use that for all of my “old school” PHP-based site-specific stuff. Now I just need to find the function WordPress uses to tell which style variation the site is configured to use.

Except… uh… I really can’t seem to do that. I googled it. I used the dreadful search tool in the WordPress Developer Reference. I checked a few of the tutorial sites. Nothing.

I even poked around the WordPress source code. Still nothing.

Finally, I rationalized… well, it has to be storing that setting in the database, so I’ll just temporarily turn on the Site Editor, set my style variation, and then search the wp_options table of the database to see where it turned up, and then maybe I can reverse engineer from that.

Nope.

There’s nothing in the wp_options table.

Oh no, I thought. They aren’t putting this into the wp_posts table, are they?

Yes, and no.

Yes they are, but no, it’s not what I thought. It’s much, much worse. They’re copying the entire contents of the style variation’s JSON file into the table.

Ugh. I mean, I kind of get why they’re doing that… because you can make additional customizations directly in the Site Editor, and that “post” (eye roll emoji — yes I have the stupid built-in WordPress emoji functionality disabled via my No Nonsense plugin) is where those changes get stored. But, uh, wouldn’t it also make sense to store the name of the base style variation itself, in case the user wants to reset it? Maybe they do — somewhere — but I’m once again too demoralized by the seeming absurdity of this whole enterprise to try to track it down.

The big problem is, this means I can’t just hardcode a way for the two sites to load a style variation’s JSON instead of the base theme.json file. And since that file is &#%^!#ing JSON instead of PHP, I can’t put conditional logic directly in it.

I’m leaving this post here, with the situation unresolved at the moment, but my next avenue will be to see if I can find a place where I can shunt WordPress over to using my variation JSON files.

Yes, I am Doing It Wrong™. But if you ask me, the entire thing is doing it wrong.

And don’t call me Shirley.

Update: OK, like, ten seconds after I published this, I decided that the correct course of action is simply to, alas, scrap my idea of using global style variations, and go back to building two separate child themes, even though it will mean a lot of redundancy. Global style variations are a good idea, but they’re just not implemented in a way that is practical for me to use. (Which makes me wonder if the way they’re implemented is really practical for anyone to use, but once again I am clearly not the core team’s target audience.) Thank goodness I hadn’t yet emptied the trash on my Mac.

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.

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.

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.