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; }

Which bass does Geddy Lee use for each song on Moving Pictures?

I have a reason, which will be revealed on my YouTube channel next week, for considering which type of bass Geddy Lee plays on each track of Rush’s 1981 masterpiece album Moving Pictures. There seems to be much debate out there in the world over which basses he used especially on Permanent Waves (1980), Moving Pictures, and Signals (1982), because he was known to play a Rickenbacker 4001 almost exclusively on their late ’70s prog albums, but he briefly worked a Fender Jazz Bass into the mix before going all-in on Wal basses in the mid-’80s (with an occasional Steinberger thrown in for peak ’80s futurism). From the mid-’90s on, Geddy has almost exclusively gone back to the Fender Jazz Bass.

So Moving Pictures really is kind of a pivot point, both for the band stylistically and for Geddy in terms of his bass gear. It is (I think?) well known that he used both the Rick and the Jazz on Moving Pictures, but which one does he use on which song, and how can you tell?

Well, “how can you tell?” comes down to ear and familiarity with the sonic characteristics of the different instruments. The Rickenbacker tends to have very deep, round low end and a ringing high end, with a bit of a scoop in the middle, whereas the Jazz Bass has a lot more midrange growl. That’s oversimplifying it, but once you know the sound, it’s not too hard to tell. So, let’s investigate, track by track.

“Tom Sawyer”
This one is kind of tough, actually. I feel like I could make a good argument for either, but I think my impression of the whole thing is too muddled because I’ve heard so many subsequent live versions of this song — Rickenbacker on Exit Stage Left and then Jazz on the 2000s live albums, plus the 5 times I saw them live — and Geddy kind of has “his sound” regardless of which instrument he’s playing, that I just can’t tell. Fortunately I do not just need to use my ears. The band produced music videos for several songs on the album from the recording sessions at Le Studio, and we can easily see in the video that Geddy is playing a Rickenbacker.

“Red Barchetta”
This one, I am fairly certain, is a Rickenbacker, even though Geddy has the mids cranked up. It’s really that first note he hits at the beginning of the guitar solo around 3:20 that is the giveaway to me. There’s no Le Studio video for this one, and on Exit Stage Left he’s playing a Rick, but he plays a Rick on pretty much all of that, so no help there. Not that we really need it.

“YYZ”
It’s kind of hard to nail down the bass tone here because there’s a bunch of chorus on it, but I am fairly confident it’s a Jazz Bass. It has that Jazz Bass growl (as opposed to, y’know, that Rickenbacker growl). Once again you kind of have to focus on the bass during the guitar solo, because when Geddy and Alex are playing together in unison their sounds blend too much. I just think I am hearing the gnarl of a Jazz Bass bridge pickup here. My introduction to this song was the A Show of Hands video from the late ’80s, and there, of course, he’s playing a Wal.)

“Limelight”
OK, in listening to this one I absolutely thought it was the Rickenbacker, but hey there’s another music video from the recording of the album, and Geddy is playing a Jazz Bass. Of course the video also cuts to some fake “live” footage that shows Geddy playing a Rick, but that’s from the A Farewell to Kings era, carefully edited to make it (sort of) look like they’re playing “Limelight.” So I think it’s safe to say we definitely have a Jazz here.

“The Camera Eye”
This one is definitely a Rickenbacker. Probably the easiest one to tell on the entire album. I think the verse that starts at 7:30 is where it’s easiest to tell. No question on this one. I was lucky enough to see the band on the Time Machine tour, where they played this album in its entirety, and of course at that point Geddy played it on a Jazz Bass. (Side note: No disrespect to Geddy, but you can tell he is really reaching for some of those high notes, 30 years later. Reaching, but generally hitting them!)

“Witch Hunt”
This song really doesn’t sound like any other in the band’s entire catalog. And the bass on it is unquestionably a Fender Jazz Bass. I think once again the thing that distinguishes it for me is the midrange. The Rickenbacker has a scoop in the midrange but the Jazz Bass seems to be pumping out consistently at all frequencies. (But if your eyes can handle it, you can check out Geddy playing it on a Steinberger on the Grace Under Pressure tour a few years later.)

“Vital Signs”
This one also definitely sounds like the Jazz Bass to me. I think around 1:20 is where it is very easy to pick out the bass tone. Fortunately this is another one with a Le Studio music video, so we can confirm it.

So there you have it. To put it another way, here’s how I break down the album:

Rickenbacker 4001: “Tom Sawyer,” “Red Barchetta,” “The Camera Eye.”
Fender Jazz Bass: “YYZ”, “Limelight,” “Witch Hunt,” “Vital Signs.”

Not everything needs to be secure

Just saving this for future reference. I got on the “all HTTPS all the time” bandwagon without questioning it, because enough of the sites I create do collect user data that needs to be secure. But some — like this blog, for instance — do not.

But here’s an angle on it that I hadn’t considered:

If Google succeeds, it will make a lot of the web’s history inaccessible. People put stuff on the web precisely so it would be preserved over time. That’s why it’s important that no one has the power to change what the web is.

Dave Winer

Google of course is always trying to change what the web is, just as Facebook does. I really got into a lather over AMP because it was immediately clear to me as a web developer how it is bad for the open web. Forcing everything to HTTPS is not quite as obviously “wrong,” but when you investigate it… yeah, it is.

This site uses HTTPS because… well, why not? I use Let’s Encrypt, so it’s free and easy. And I configured the server to automatically redirect HTTP traffic, so old links still work. But people shouldn’t be expected to understand what I understand about the web in order to use it… and not just as passive consumers, but as active contributors.

That’s the real power of the web, and what we lose when we let companies like Google or Facebook change the nature of what the web is.

I’d like to end with another quote from Winer:

The web is not safe. That is correct. We don’t want every place to be safe. So people can be wild and experiment and try out new ideas. It’s why the web has been the proving ground for so much incredible stuff over its history.

Lots of things aren’t safe. Crossing the street. Bike riding in Manhattan. Falling in love. We do them anyway. You can’t be safe all the time. Life itself isn’t safe.

Occam’s Razor as it applies to DevOps

A client emailed me today about an unusual problem. The “Create an Account” link on their website was not pointing to a page of their site, but instead to an IP address. An IP address that, when I ran a whois on it, turned out to be owned by China Telecom.

That was disconcerting. I’m not passing any judgment on anyone in particular in any country in particular, but the fact is, a hugely disproportionate number of online attacks against U.S. sites come from a small number of foreign countries, China being one of them. So, I was alarmed.

My first guess, since I’ve seen WordPress sites get hacked… a few times (much less often since I started using Wordfence as standard practice on every site I build), was that hackers had somehow hijacked this link and were trying to route my client’s users over to their systems in some kind of spoofing/phishing/whatever attack.

Only, the link didn’t actually do anything. There’s no web server listening on that IP address. Hmm.

Next up I looked at the HTML source, since I wasn’t quite sure if the code in question was being generated by their theme (which I built) or by a plugin like WooCommerce, so I wanted to see the CSS classes on the wrapper. Sure enough, it was in code I had built.

When in doubt, always blame your own code first.

But the fact that it was my code wasn’t what really caught my attention. It was the fact that the URL in the HTML wasn’t the IP address at all. It was just a string of 8 digits.

Suddenly it was clear to me that this was not a hack attempt, and China Telecom (or anyone using its services) had precisely zero to do with whatever was going on. This was a peculiar code problem, and it was at least indirectly my fault.

That 8-digit number… it looked very familiar. I knew that, due to some of the peculiarities of this client’s site, the ID values in their wp_posts table are on that order of magnitude. Bingo. This wasn’t a URL at all. It was a WordPress post ID, being incorrectly inserted here because Advanced Custom Fields was outputting the raw ID value instead of using it to look up the corresponding post URL.

Why was that happening? Well, that was ultimately my fault too, having to do with some logic that was designed to tell ACF where to load my custom field groups. When the site was built, I had that code running (technically) too early, then ACF released an update that started throwing up admin notices if you did that, so I rewrote it to run later… only I didn’t realize that my change was causing my code to get applied to a hook after it had already run, so… it wasn’t working. It was a very isolated set of circumstances, so it went unnoticed for months. As far as I know, the only user-facing issue it created was this weird integer URL on the “Create an Account” link on a page few people ever visit.

The simplest explanation is the most likely.

Even if the details are anything but simple. Was someone in China trying to hack my client’s site to phish for their customers’ data, or did I just write some flawed code? Hmm.