30 November

The more I use Gutenberg (the WordPress Block Editor), the more I simultaneously like and dislike it

Where do even I begin with Gutenberg, a.k.a. the Block Editor? Well, I don’t really need to “begin” with it, because I’ve been posting about my various frustrations with it for over 5 years now. (This isn’t even the first Gutenberg-related post I’ve started with “Where do I begin…”)

It took me a long time, but I did finally embrace it. Sort of. I’ve suspended new development on my own pre-Gutenberg block-style theme, 34 Blocks, built around ACF Flexible Content, and for most of the year I’ve been working on its replacement, a Gutenberg-centered theme that I regrettably (for the difficulty of typing it) have named 34 Blocks².

It’s better than bad, it’s good

I will say it, without reservation: Gutenberg, which I will respectfully refer to henceforth as the Block Editor, has gotten a lot better. Taken on its own as a piece of software, I might even, now, describe it as… “good.”

But.

There are so, so many things I would have done differently if I were building it myself. Sure, I take a more “opinionated” (as they say) approach to coding and web design, but that opinion is informed not only by a quarter century of professional experience, but by constantly building to suit specific client needs. Before I started using WordPress full-time in 2014, I had been building my own custom CMSes from scratch, going back to late 2000, when I was using… ugh… ASP and Microsoft SQL Server 7. On Windows NT 4. (I get a sinking feeling in my stomach just remembering those technologies once existed.)

So, a) get off my lawn, and b) WordPress has always done things the wrong way, so why change that now? Like PHP itself, WordPress has long been a marvel of being a tool that just about anybody (relatively speaking) could use to “just get stuff done,” without a soul-crushing learning curve. But its architecture borders on madness. It should’ve used an MVC framework 15 years ago, just like it should be using something like Bootstrap now.

Jane, stop this crazy thing!

I’m really concerned about extending the Block Editor content model to full-site editing, and the Site Editor as it currently stands is (in my estimation) a disaster in every conceivable way. But I don’t want to dwell on that too much at the moment. (Mainly, much like Donald Trump, Elon Musk, or cryptocurrency, I want to pretend it doesn’t exist.)

So far I haven’t had much good to say, but believe it or not, I actually like using the Block Editor. When I play by its rules. If you use it to design your pages, great. It gives you way more flexibility than the old “classic” editor.

But you know who doesn’t use it to design pages? Designers. If, like me, you work with designers who deliver you Adobe Illustrator files, and your job is to turn those designs into actual functioning web pages, Good luck shoehorning their designs into the Block Editor. Sure, you can create custom blocks (if you bother to learn React, which, yuck), or you might be able to create a Block Pattern that does the job. But just about any way you go about it, it’s more work than before.

Which brings me to the starkest realization I’ve had about all of this. It happened about a month ago, when I had a rush project. I needed to put together a small site, just a couple of pages, but it needed to be a very precise design, with a lot of polish, and I needed to turn it around in a week. The client didn’t really need the ability to edit content — if they have changes, they’ll come to me anyway.

So I built it by hand.

Oh, I didn’t write every line of code by hand. I used Bootstrap to get my structure started, and I also relied extensively on AOS for some slick animations. I built myself a super-rudimentary PHP framework that is kind of an MVC-lite. (There’s no database, but I did put some content into PHP arrays to allow for loops instead of repeating a ton of identical HTML code.)

The end result looks as close as possible to the designer’s Illustrator file (with my additional adaptations to make the site fluid and responsive), it’s super slick, and the client loved it. And it would have taken me at least 3-4 times as long to do with WordPress and the Block Editor, with inferior results.

I’m aware of the irony… so don’t bother pointing that out

This all brings me back to a question I frequently, and increasingly, ask myself: Who is WordPress for? The core team clearly still thinks it’s for bloggers. Do they still exist? For the past decade, I’ve thought of it as an extremely versatile, open-ended CMS (or CMS-ish at least), suitable for building just about any kind of website and giving my clients easy access to edit their content without messing up the layout.

But I’ve also come to realize over the years that a lot of my clients either a) don’t need or b) don’t want to edit their own content. Or even if they think they do, in practice they edit things so rarely that they need my help to remind them how things work whenever they do actually make a change.

That’s not always the case; I have some very engaged clients who are using their sites constantly, and for them, WordPress has been the perfect tool. Very few of them, yet, are using the Block Editor though, so we’ll see if that remains true.

My business is still very much dependent upon WordPress. Not only do I use it to create most of my clients’ sites, but I have a growing side business building and maintaining multiple WordPress plugins. I want WordPress to be great, and I want it to continue to grow. I want to continue recommending it for my clients.

But I am also realizing more and more that there are definitely some clients for whom WordPress isn’t the best choice. I no longer see it as “suitable for building just about any kind of website.” In cases where either the client doesn’t want/need editing capabilities, or where the designer delivers a highly unique design that isn’t well-suited to the Block Editor, it’s time to consider alternatives. For me, that probably means, ironically, going back to custom-built CMSes, or at least custom-built templates without a CMS. For some clients, that might mean Squarespace or Shopify, even if that then means I’m not the right developer for them.

Update, in the cold light of the following morning: After writing this, I went back and skimmed through some of my previous posts, then read a few other people’s posts I had linked to but had not given a close read initially. That’s when I came across coderjerk’s The Complicated Futility of WordPress (again), and it spoke to me like nothing I have read in ages. Yes! This is me! Yes, I am not alone! Even as I have spent most of my work time this year wrapping my brain around the Block Editor and trying to create my own Block Theme, I’ve also been harboring secret thoughts that maybe this is the end of the WordPress road for me, and have been looking for alternatives. I never get very far though before I abandon the idea of learning a new toolset and retreat back to WordPress. But WordPress is making me learn a new toolset anyway, and it’s one that, deep down, I know doesn’t make a lot of sense. Coderjerk concludes the post with a note about Laravel-based Twill, and I am genuinely intrigued. It looks like it may be “The One.” But I’ve thought that before. Still, I intend to give it some serious consideration.

Debugging WordPress and PHP 8.1: a chicken-and-egg conundrum

If you’re a WordPress developer, trying to debug code on a server that’s running PHP 8.1, you may have noticed an absurd number of deprecation notices overwhelming your efforts to get anything done.

After trying in vain to resolve the issue by updating the value for error_reporting in my server’s php.ini file, I discovered why that doesn’t work, courtesy of a StackExchange answer.

WordPress sets its own value for error_reporting when you turn on WP_DEBUG, ignoring the php.ini value. It kind of has to do this. (Well, not “kind of.”) That’s the only way for WordPress to display more — or less — error output than what’s configured at the server level.

The problem is, when you turn on WP_DEBUG, WordPress shows you everything. Normally that would be desirable, but PHP 8.1 has introduced an unusually large number of deprecation notices in anticipation of PHP 9 imposing strict rules on things that have been generously allowed in earlier PHP versions.

OK, so we know what’s going on. But since a lot of the deprecated code is in WordPress core, or in third-party plugins, there’s not really anything a developer like me can do about fixing these issues. (Sure, I could fix it and submit a pull request, but I’m not currently a WordPress core developer and I am not sure I want to take that on, even in an extremely peripheral way.)

So… uh… how do I just make it stop? That is definitely easier said than done, and the reason is the sequential nature of how code is loaded and executed. “Everything everywhere all at once” is not how it works. WordPress loads one file, that loads another file, that loads several other files, each containing a mix of procedural and object-oriented code, and functions. The way WordPress lets you hook into that flow and insert modifications is… well.. hooks.

Hooks are great, but a) the hook you want has to exist, and b) your code that uses the hook needs to be loaded before WordPress processes the hook. Oh, and of course, c) hooks themselves are functions, so you can’t use them until those functions have been defined.

Hence our problem. The code that tells WordPress to show you all the stuff — errors, warnings, deprecation notices — happens pretty early in the sequence. Specifically (as of WordPress 6.1.1) it is in line 460 of wp-includes/load.php in a function called wp_debug_mode(). By that point, yes, the add_action() and add_filter() functions have been defined. But, WordPress hasn’t actually loaded any plugins yet (even “must-use” plugins in the mu-plugins folder). So if you write a plugin to modify the error_reporting value, it might work, but only on deprecation notices that are generated after your plugin has been loaded, and the ones we’re concerned with are all in WordPress core and get triggered before plugin loading starts.

Realizing this, I thought I might solve the problem by putting my filter into the wp-config.php file, a.k.a. the only “early” file you’re allowed to edit. But nope, can’t do that: the add_filter() function doesn’t exist until wp-includes/plugin.php gets loaded at line 49 of wp-settings.php, which itself gets loaded at the very end of wp-config.php.

Since wp_debug_mode() runs at line 80 of wp-settings.php, that means the only way to do what we’re trying to accomplish is to get it to fire off somewhere within those 31 lines of code inside wp-settings.php. Those lines consist of calls to a handful of low-level functions. I checked the source code of each of them for any hooks — not that it would be correct to use the hooks in any of those functions for this purpose, if they existed — but merely to see if it would even be possible.

There is only one hook in the entire lot, and it’s inside wp_debug_mode() itself. It’s called enable_wp_debug_mode_checks. I wrote my own filter function that leverages that hook to modify error_reporting, and it would work, except for the fact that there’s nowhere to put it. I can’t write any custom code in a plugin or theme to call that filter, because it wouldn’t be loaded yet by the time the filter is applied in wp_debug_mode(). And I can’t put it in wp-config.php because, as noted above, the add_filter() function isn’t even defined yet at that point.

So… there are only two place you can put this code to get it to work: either in wp-settings.php just before line 80, or by just editing the wp_debug_mode() function itself in wp-includes/load.php. And you very much are not supposed to do either of these things, because your changes will get overwritten the next time a WordPress core update runs.

But… what else are you going to do? Well… after going through all of the emotions on my wide spectrum from frustration to rage, I read the comments at the top of wp_debug_mode() that start with a pretty unambiguous statement:

This filter runs before it can be used by plugins. It is designed for non-web runtimes.

OK then.

Also inside the comment is a code example, mirrored in the next reply on the same StackExchange post I linked above. I initially ignored it because I instinctively ignore any PHP code example that includes $GLOBALS… but in this case, it’s apparently the official answer on the matter. Boo.

The code I ended up putting into wp-config.php looks a bit different though:

if (WP_DEBUG) {
  $GLOBALS[‘wp_filter’] = [
    ‘enable_wp_debug_mode_checks’ => [
      10 => [[
        ‘accepted_args’ => 0,
        ‘function’ => function() {
          error_reporting(E_ALL & ~E_DEPRECATED);
          ini_set(‘display_errors’, ‘on’);
          return false;
        },
      ]],
    ],
  ];
}

I’m not sure why the StackExchange poster put the error_reporting() call outside the conditional. I also found I needed to specifically set ini_set('display_errors', 'on'); because returning false from this function causes the rest of wp_debug_mode() not to execute — which we want, but we need to make sure to replicate any of the rest of its functionality that we do need. I probably should add the bit that doesn’t output errors on REST/AJAX calls, but I’ll worry about that when it becomes an issue. I don’t use either of those very often. (Of course the WP admin itself uses AJAX all the time.)

A few reasons why you should keep your old domain name indefinitely, even if you’ve changed your business name and never plan to go back

What follows is a slight reworking of an email I just sent to a client. I think it’s broadly useful enough that it deserves to be shared publicly.

Here’s the scenario: The client’s family business operated for many years under her father’s name, but when he retired and she took over, she changed the name. In the several years since, she has built a strong reputation for the new identity, and she was wondering if it was finally time to let the old domain name lapse.

Short answer: No!

Here’s the longer answer, which also addresses the natural follow-up question: Why?

First, “google” your old domain name. Just go to Google, type the old domain name in the search bar, and see what comes up. You may be surprised how many websites out there still have links to URLs with your old domain.

Assuming you kept the old domain configured as an alias when you built your new website, if you keep the domain, those old links will still work, and redirect to the current site. If you were to let the domain lapse, those links would stop working. (Whether or not anyone is actually clicking those links is another matter, of course. If you have Google Analytics or other site stats, check your referrers for some insight on that.)

The same goes for email. Some people may still have old business cards, or for other reasons might still try sending email to those old addresses. If you have them configured to forward (which, again, you should have done when you initially made the switch), then you’ll still get those messages.

Another thing to keep in mind: if you let the old domain lapse, someone else will be able to register it, and could put it to nefarious use — phishing, scams, or just generally sleazy content. I have seen it happen. Even the best case scenario — no one registering it — will result in it loading a “this domain is available” placeholder page with the domain registrar, which may give people the impression you’ve gone out of business.

Given the relatively low annual cost of a domain registration, my recommendation is that you should keep your old domains registered for as long as you’re in business.

ST:TNG Treadmill Review #4: A Matter of Honor

A Matter of Honor
Season 2 Episode 8
Original airdate: February 4, 1989

Netflix Synopsis

When the Federation promotes an officer exchange program, Riker decides to accept an assignment aboard a Klingon warship.

My Brief Review

This episode definitely is one of the most memorable from the entire Next Generation run. Who could forget Riker sitting at a table full of Klingon “delicacies” like gagh before departing for his assignment to the Pagh? Or the proud Benzite Ensign Mendon offering Captain Pickard his unsolicited advice to improve efficiency? But for me the highlight is when Riker tricks the Klingon captain — for his own good — and has him beamed to the Enterprise bridge. A great episode.

Memorable Moment

I mentioned several above, but definitely the most memorable moment for me is Riker sitting in the Klingon mess hall, doing his best to fit in, learning that Klingons actually have a sense of humor. And of course, eating more gagh.

Crew Rando

Ensign Mendon, of course. With an honorable mention for (briefly) acting Captain William Riker of the Klingon Warship Pagh.

Distance Rating: 5K

IMDb score: 8.1/10

Top 5 Albums of 2011: The Nominees

Here’s a follow-up to my recent post introducing (in cover art form) the albums under consideration for my upcoming “Top 5 Albums of 2011” post.

I realized after I wrote that post that although I’ve purchased about 25 new albums this year, I haven’t really listened to most of them very much. This is mostly because I’ve spent a large part of the year working on and listening to my own music, and much of the rest of it listening to 5by5‘s tech podcasts.

In the wake of the “contenders” post, I created an iTunes playlist that consists just of those 25 albums and have committed myself to listening only to the music on these albums. I’m listening to it mostly on shuffle, which of course shines more light on the merits of individual songs than on albums as a cohesive statement, but I figured this was the fairest way to ensure that I actually hear all of the artists.

After a few days of listening, I’ve come to the conclusion that I’ve definitely been neglecting these albums. There’s some great music out this year, and I’ve liked almost every song that’s come up in the rotation.

But, of course, I favor some albums over others, and so here are the albums I am most strongly considering for the top 5:

Adele — 21
I am really sick of hearing “Someone Like You” everywhere. Much like “Losing My Religion” 20 years ago, it’s a song I never really cared for anyway, but its annoying ubiquitousness pushes me almost to the point of disregarding the artist entirely. Other than that, and a couple of weak songs in the middle, though, I think 21 is a truly outstanding piece of work, with great singing and inventive re-imagining of soul sounds from the ’60s and ’70s.

Foo Fighters — Wasting Light
As with most Foo Fighters albums, this is an easy one to like, if you like hard rock. In many ways I think Foo Fighters are the last remaining standard bearers for classic rock. And “Rope” is probably my favorite song of the year.

Foster the People — Torches
I really don’t want to like this album as much as I do. There’s something about Foster the People that reminds me in a weird way of Owl City, in that it feels like something I should (and, in the past, would have) just dismiss outright. And yet every time one of these infectious songs comes on, it just sucks me in.

Halloween, Alaska — All Night the Calls Came In
I pretty much love anything Minneapolis-based jazz drummer Dave King is involved with, but Halloween, Alaska sounds nothing like his other work, and that’s turned out to be a good thing! Relatively straightforward art pop, with a slight Canterbury prog rock twist.

Joshua Wentz — Look/Look
This is the only truly “indie” (as in, unsigned) album I’m considering this year, and probably is the only one I’ve ever considered. As much as I respect DIY music (and engage in it extensively myself), and as much as I hate the RIAA and the dinosaur major labels behind it, it’s hard to let go of the old hangup of not taking it as seriously as music released by a “real” record company. But I make an exception to that hear. I know Josh and have been following his musical endeavors for a few years now, and this album is as good as anything any major label has released this year, and far better than most.

M83 — Hurry Up, We’re Dreaming.
I became enthralled with M83 with Saturdays = Youth a couple of years ago. This follow-up is a sprawling, atmospheric double album. I can’t avoid the analogy of Fleetwood Mac’s pair of late ’70s albums, Rumours and Tusk. As in that case, I don’t really think this is better than the album that preceded it, but it’s a fascinating journey nonetheless.

Mayer Hawthorne — How Do You Do
Mayer Hawthorne could be counted among a large number of white artists in recent years who have resurrected ’60s soul music. One could cite the long history of white musicians appropriating black artists’ styles and reaping commercial benefits that the original artists never attained, and I guess I just did. But that doesn’t change the fact that this is great music, and I’m glad the style is making a comeback, regardless of who’s performing it. Plus… I had no idea Snoop Dogg could sing!

Steven Wilson — Grace for Drowning
I’ve been a huge fan of Steven Wilson’s prog rock band Porcupine Tree for over a decade. The past few Porcupine Tree albums have been great but are starting to feel a bit too familiar. Taking a break from the band was apparently just what Wilson needed to reinvigorate his seemingly limitless creativity. Enlisting the help of a number of prog rock legends and comparatively unknown but highly talented jazz musicians, he’s created his most ambitious and varied work to date.