Artifacts of an error

A little over a week ago I did something really stupid. Today I took the final step in making amends for that error, which was ultimately the consequence of a questionable decision I made many years ago, to create an ad hoc WordPress multisite setup. That lowercase “m” is significant, and I hinted at it in the post I linked to above.

This was not a proper WordPress Multisite setup. I think that feature probably already existed at the time, although it may not have. This was my own concoction, created by adding a PHP switch to the wp-config.php file, telling it to use a different database and uploads directory depending on the domain name in the HTTP request. It allowed me to manage a number of my own and Sara’s websites with a single WordPress installation, but it was dangerous.

None of the sites “knew” about each other. That wasn’t really a problem, except when it came to managing themes and plugins. I always had to be careful to remember that just because my site wasn’t using a particular theme or plugin, didn’t mean one of Sara’s sites wasn’t… or even one of my own other sites in the setup.

I forgot about that little detail when I did my stupid thing a couple weeks ago. I deleted all of the themes my blog wasn’t using, forgetting that Sara was using many of them. In a panic to quickly restore the themes, I made matters worse by accidentally restoring the entire server from a 6-day-old backup, erasing all of the work Sara and I had done on our respective sites over the preceding week.

My “final step” in making amends was to at least remove my own sites from that setup, so it is now just running Sara’s sites. If you’re reading this, it means you’re seeing my blog in its new home. (Coincidentally, this is also facilitating my gradual transition away from Digital Ocean in favor of Linode for my hosting needs.) I also moved my John Coltrane and Adelia Haight McCormick sites, which were part of the same cockamamie arrangement.

One last thing that I didn’t think I’d be able to recover: I wrote two fairly substantial blog posts in that week, and I was pretty sure those were gone forever. But last night I discovered that the Feedly app on my iPhone still had them cached! I quickly snapped a series of screenshots so they wouldn’t be lost forever.

I had originally intended to retype them here, back dating them to their original post dates, to make it seem like they’d never been lost. But somehow it seems more fitting to just post those phone screenshots instead.

One of the posts hinged on a composite Mac screenshot I had taken from Safari, demonstrating its absurd Experimental Features menu, and that’s an image I still had on my Mac, so I’m including it below as well.

Enjoy.

Also worth noting here… this is my first post on this blog using the Block Editor, a.k.a. Gutenberg. I’ve finally accepted its inevitability. I’ll probably update the site to a new theme in 2023 as well… this one is a custom hack of Twenty Eleven, for cryin’ out loud!

Why are major WordPress plugins not bothering to fix their numerous PHP 8.1 deprecation notices?

I’m an early adopter for a lot of things, but new versions of PHP are generally not one of them. PHP 8.1 wasn’t really on my radar until I set up a new server running Ubuntu Linux 22.04, where PHP 8.1 is the default version.

Yeah, I’m a commercial WordPress plugin developer too, but my business is small. It’s easy to understand me not being 100% on top of this.

What I do not understand is how huge WordPress plugins like Jetpack, WooCommerce and Wordfence can get away with not being on top of it.

The general response these developers are giving when questioned on this is, “they’re only deprecation notices, everything should still be working.” Which is true.

But.

Are you a developer? Do you ever need to turn debugging on? Have you seen what happens when you have multiple plugins active, each of which generates 5-10 PHP deprecation notices on every page when debugging is turned on?

Aside from making the site, and especially the WordPress backend, borderline-to-entirely unusable (which, honestly, is a bigger problem than what I’m about to say), it also makes normal debugging impossible. It’s hard to find real issues when you have to wade through more than a screen’s worth of irrelevant deprecation notices. And the sheer volume of the notices breaks page layouts to a point where it’s impossible even to know what is or isn’t broken.

I actually blame PHP for this. I don’t know what they were thinking with some of these changes that are triggering all of the deprecation notices. I know “real” programming languages aren’t as loosely typed and lenient with sloppy coding as PHP is, but… well, it’s kind of too late to put that genie back in the bottle. I haven’t bothered to investigate exactly what the rationale is for no longer allowing null input to string handling functions. What I do know is that there’s a ton of code out there, written by competent, experienced developers, that is now triggering these warnings, because until now it was always fine to equate null and an empty string.

Anyway, principled arguments aside, I have a more practical frustration to deal with right now… I’m finding it hard to do my work, because other people haven’t done theirs.

Dolby Atmos through MacBook Pro speakers: DO NOT WANT

What are your thoughts on Dolby Atmos?

More specifically: what are your thoughts on Apple Music automatically playing songs in Dolby Atmos through laptop speakers?

My MacBook Pro has pretty great speakers (for built-in laptop speakers). I’m sitting here listening to Talking Heads’ Fear of Music, and I could tell immediately that there was some kind of surround effect going on. It was very disorienting — it created a physical sensation in my ears and almost started to give me a headache. Then I realized I could turn it off and instantly everything went back to normal.

I’m not entirely sure what kind of dark magic Dolby is employing with this (I’m sure it has something to do with reversing the polarity of the stereo channels or something nerdy like that), but I don’t understand why it’s being foisted upon us. It reminds me of the trend about a decade ago of every movie being made in 3-D, and even 3-D TVs that no one wanted. Eventually they caught on to the “no one wanted” part and now it’s not much of a thing. I hope Dolby Atmos on streaming services follows in short order!

Related: Why Your Atmos Mix Will Sound Different On Apple Music

You’re never too experienced to make a boneheaded mistake, especially when the action that initiates it looks extremely benign

A big scary warning message

That warning bar doesn’t exist. But if it did, I maybe wouldn’t have made the stupid mistake I made on Sunday morning.

The big mistake was actually the result of my hasty efforts to patch up a much smaller mistake. As it goes.

I had mistakenly deleted a bunch of WordPress themes on a multisite (but not Multisite; the difference is worth discussing in more detail at a later time) installation that Sara and I use for all of our blogs — including this one.

I didn’t want Sara to see that her themes had been trashed, so I quickly logged into my Digital Ocean account and attempted to restore a copy of the latest backup of the server. My intention was to spin up a new copy of the server, from the most recent backup, go in there to grab the theme files I had accidentally deleted, copy them into the live server, then destroy that temporary copy of the server.

Here are the options I was presented with:

Given that menu, what would you do? Never mind the fact that I’ve been a Digital Ocean client for over a decade and have dealt with this exact menu numerous times before. I should have known better. But I was in a hurry and not thinking clearly.

Did you select Restore Droplet? Congratulations. Just like me, you have now destroyed the live server.

Maybe all of this wouldn’t have been so bad, but the weekly backups on this particular server take place on Monday nights. Which means we were working from a 6-day-old backup. And wouldn’t you know it, both Sara and I (but especially Sara) had been unusually active on our blogs this past week.

So yeah, I clicked Restore Droplet, which immediately, without any additional warning or confirmation, completely and permanently wiped out the live version of the server and replaced it with the contents of that 6-day-old backup. A week’s worth of blog posts and site edits, vaporized with absolutely no possibility of recovery.

What was the correct action? As I already knew, it was to select Convert to snapshot, then navigate in the side menu to Snapshots and from there, create a new “Droplet” (Digital Ocean’s term for a virtual private server) from the snapshot. As I said, I’ve done this exact process many times over the past several years, when a client accidentally deleted something and I needed to help them recover it.

Ugh.

Anyway… if this blog happens to have any keen observers, you/they may have noticed that the two most recent blog posts had disappeared. No, this was not intentional. And they are gone forever. Fun.

Update: According to Digital Ocean support, the Restore Droplet option does present an additional warning before continuing, but (in my opinion) it is not nearly aggressive enough to make you stop what you’re doing if you’re being hasty like I was.

Making Bootstrap work with the WordPress Block Editor

tl;dr: You need to load Bootstrap’s CSS in the 'wp_enqueue_scripts' hook with a priority lower than 10.

Where do I begin with this one? First, some foundational details: I’m old school. I’ve been a professional web developer/designer since 1996. I’ve embraced new technologies as they come along, but I tend to bristle at things that are either a) not an open standard or b) need to be compiled.

I refused to use Flash. In the end I was proved right, as open web technologies supplanted it. Flash is dead, and the open web is not. I still refuse to use CSS preprocessors for a similar reason. They’re a non-standard workaround to limitations in the current standard. They fragment the landscape instead of pushing the standard forward. And as CSS variables have gained wide browser support, preprocessors are beginning to look as pointless as Flash.

Now the thing I hate is npm — or any similar tech that requires me to run shell scripts and compile anything. I’ve long since embraced server-side scripting, using open source libraries like jQuery, and even using a pre-built CMS (or CMS-ish system) like WordPress. (Yes, for many years I rolled my own CMSes.) The bottom line for me is, if it’s code I can download simply and treat as a “black box,” fine. But if it’s something I need to get my hands dirty in, I shouldn’t need anything to work with it but a text editor.

All of that to say, I am having a bit of a time with where things are going these days with Gutenberg, a.k.a. the WordPress Block Editor. And I haven’t exactly been quiet about it here.

This week I needed to extend the Block Editor by creating a carousel/slideshow block. Yep, I’ve rolled my own with these for many years as well, but this time around I decided I wanted to work with something pre-built, so I settled on the one in Bootstrap. I don’t really need all of Bootstrap (although I suspect over time I will need more of it), but customizing it requires using npm, so I decided to go ahead and include the entire pre-compiled package in my theme.

That’s when the problems began.

Oh, the carousel works great! But I spent a bunch of time yesterday trying to figure out why the custom background color and fonts defined in my theme.json file were being ignored… especially since they’re right there in the inline CSS inside the <head> of every page.

Don’t even get me started on inline CSS, or the way so many people in the industry seem to worship PageSpeed Insights. Once again we’re skating to where the puck is, instead of where it’s going, and to stretch the analogy to the limit, we’re melting all of the ice in front of it too. This is not the way to move web development forward intelligently.

Ah-hem.

Eventually I worked out what’s happening. WordPress, historically, was designed to allow you to define dependencies, so you could load CSS and JavaScript in a logical manner. Gutenberg/Block Editor throws all of this out the window with this inline CSS. Certain “critical” inline CSS for the Block Editor gets loaded immediately regardless of the dependencies you put into wp_enqueue_style(). The result being, styles defined (indirectly, in a way more convoluted way than vanilla CSS) in my theme.json file were appearing before the Bootstrap CSS file was loaded. And since I’m using the compiled Bootstrap instead of a custom npm build, there’s a bunch of “general” CSS it’s throwing in, including color and font definitions on the <body> tag that override Gutenberg’s earlier inline CSS.

Fortunately, someone else had the same problem and figured out a solution. But since, in 2022, spammers overrun any forum thread that’s left open too long, the thread was already locked and I couldn’t express my appreciation to the poster who shared it. So I’m writing this blog post instead.

The trick is to load any third-party CSS that you might need to override using a separate function called on the 'wp_enqueue_scripts' hook, with a low priority number (less than 10, since that’s the magic default).

Here’s a generalized version of the code I’m using:

function my_enqueue_scripts_early() {

    $ver = '1.0.0'; // Your theme version; could also be a class property, constant, global variable, etc.

    wp_enqueue_style('bootstrap-style', get_theme_file_uri('vendors/bootstrap/bootstrap.min.css'), array(), $ver);
    wp_enqueue_script('bootstrap', get_theme_file_uri('vendors/bootstrap/bootstrap.bundle.min.js'), array('jquery'), $ver);

}
add_action('wp_enqueue_scripts', 'my_enqueue_scripts_early', 8);