OK, fine, DO use JPEG for your logo… here’s why

I have complained many times (OK, only those two times here on the blog, but countless other times to anyone within earshot) about people using JPEG for logos. It is bad, bad, bad.

But it just keeps happening.

Finally, I have stopped caring. Yes, go ahead and use JPEG for your logo. Send me the gnarliest, artifactiest, lowest-quality JPEG of your logo that you can find. And make sure it’s tiny. Like, 200 pixels wide or less.

Why?

Because I bill by the hour. I’m happy to fix your logo for you, and I will do it, whether you ask me to or not, whether you notice the difference or not, if this is what you send me as part of your project. (I can neither confirm nor deny that I might also write a blog post ranting about JPEG logos while I’m on the clock.)

Egads, I’ve never looked at that emoji closely. Are those dollar sign eyes with raised eyebrows, or closed eyes with dollar sign nostrils??? (Once you see it, you can’t unsee it.)

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.

Elon’s Twitter finally does something right

I joined Twitter in 2009, and over the span of a decade amassed over 40,000 tweets (and just over 500 followers, most of whom I believe were real humans, as I actively culled the obvious bots during my Twitter heyday). But when, around 2015, the site became a platform for would-be fascist authoritarians, I began to lose interest. I pretty much left entirely in 2017, and after a brief re-emergence in 2019 (which only served to confirm that the place was a rage machine hellscape I was better off avoiding), I decided to delete my account entirely.

But for some reason, the Twitter of 2019 labeled my closed account as suspended — with their standard message about violating terms of use. Absolutely false. And while I was briefly outraged, I eventually saw it as a badge of honor. Twitter was an apocalyptic dumpster fire long before Elon Musk was forced to buy it, and I became almost proud to have people think I had been kicked out against my will.

Periodically over the past 3 1/2 years I’ve gone back and looked at my account page to see if it still said I had been suspended, which it did. Until now. I just checked it today, and at some point in the last month or two, since I last checked it, my account page has — finally? — been updated to the correct status:

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.

Solid Gold Countdown ’82

Last week my wife tipped me off to this amazing artifact on YouTube, the broadcast by Pittsburgh’s channel 11 of the special Solid Gold Countdown ’82, which is… just… well… I can’t even put it into words. We watched the whole thing.

There is so much to unpack here. If you didn’t live through 1982, this will feel like it’s from another planet. As for me, it feels like going home.

But, I just have to say… of everything in here, the little nugget that has stayed with me for days after watching it is the commercial for a local car dealership, offering the low low interest rate of…

11.9%