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.

Fun with recycled IP addresses

OK, well that title kind of gives away the end of the story, but it’s still a good one.

So…

Earlier this week I launched a new site for a client. As part of the usual process, I submitted their sitemap.xml file to Google Search Console and Bing Webmaster Tools. Usually that’s all it takes for a new site to get indexed within 1-3 days.

But it seemed to be taking longer than usual for this client, and I decided to investigate the situation.

I should note that we did a private “soft launch” of the site about a week prior to the official launch. During that time I had a robots “noindex” directive turned on so it wouldn’t start showing up in search engines prematurely.

I went into Google Search Console to request a re-crawl. And that’s when I noticed this…

Excluded due to 'noindex'

Well, that’s… weird. Not so much that it had read a “noindex” directive when it, unfortunately, had crawled the URL just a day before we launched — although it was a bit weird that it had crawled it at all — but that the Referring page was a totally different site that should have had no business linking to us, yet.

So then I did what anyone (?) would naturally do, I visited that URL. And much to my surprise, it redirected to our site. What??

Next I used mxtoolbox to do a DNS lookup, and suddenly it all made sense.

We’re hosting the site at Linode. And as it happens, the DNS entry for the referring site is set to the same IP address as our site. This is a virtual private server, so we’re the only people now using this IP address.

But there are a finite number of possible IP addresses, especially IPv4 addresses (about 4 billion). So they naturally get reused. This particular site was for a limited-use product that was only relevant in 2015, so it’s not too surprising that the owners of the domain took down their Linode server and relinquished the IP address. It’s unfortunate though that they didn’t think to remove the DNS entry from their zone file.

At this point, we could (a) contact them and ask them to update their DNS, but that could be convoluted and time-consuming, for no real benefit to us, (b) set up a rewrite in our server that shunts traffic that’s trying to access their product site back over to their main site, which would take less time but also wouldn’t really benefit us in any way, or (c) leave it as-is, and let the few randos who are still looking for a product that was last relevant during the Obama administration wonder why they’re instead seeing our site.

I’m going with (c).

I’m also going with submitting re-crawl requests to both Google and Bing so we can get in the priority queue, and hopefully by this time tomorrow the site will be showing up in search results.

Crypto chump change

I know artists who are exploring crypto as a new way to earn money from their work — something that is notoriously hard given the soulless priorities of our economy — but I can’t see it as anything other than a get-rich-quick scheme… or a pyramid scheme… some kind of a scheme (with all the negative connotations that word carries in the US). You might get rich — some people obviously have — but you probably won’t, and ultimately crypto is not going to solve any of our problems… but it’s already created some novel ones.

I’ve been following Molly White’s blog for a while now. I really like her approach and insights. While I personally have less than zero interest in getting into crypto, I’m somewhat fixated on it right now — how it’s changing, how its myriad flaws are gradually being revealed, and how people are misunderstanding what it really is, how it works, and how it’s impacting society and the planet. (But yes I will admit that any time I see someone is into it, my immediate assumption is they’re either an Ayn Rand acolyte or a chump.)

Speaking of Molly White, she also contributed to (and hosts) this group-annotated version of Kevin Roose’s ridiculously pro-crypto “explainer” article recently published by the New York Times. Essential reading on the topic. (The annotations that is, not the original article.)

“It doesn’t suck.”

Is it possible to be excited about a text editor? Well… yes. When it’s good enough to be an essential tool for decades.

Back in 1994 when I was a junior in college and the web was emerging, I wanted to learn how to build web pages. The somewhat helpful person in the Gustavus computer store (why did I go there? I guess because I wasn’t taking any CS classes so I didn’t know any of the faculty) told me to download BBEdit, so I did. That didn’t help me to learn HTML, but it became the program I used to write it as I did learn.

I’ve dabbled with other apps over the years — including PageSpinner in 1996, at the recommendation of my boss at my first professional “webmaster” job*, and HomeSite in the brief period when I mainly worked on Windows 2000 — but guess which program is open on my Mac right now; which program I was busy writing code in moments before I read this Daring Fireball article.

* Yes, that really was my title. I gave up on PageSpinner and switched back to BBEdit shortly thereafter, because although I liked PageSpinner’s color coding (before BBEdit supported it, or at least before I figured out that it did), it bugged me endlessly that it used proportional fonts.