WordPress might not be showing your Custom Post Types and Custom Taxonomies on the Menus screen for a really stupid reason

I’m working on a new WordPress site that’s going to have both custom post types and custom taxonomies, and I want my custom taxonomies’ archive pages to be in the site’s navigation menu.

Seems like it should be easy, right? If you set show_in_nav_menus to true in register_post_type() or register_taxonomy(), you’re supposed to get access to add them to your menus.

But when I set that, they still didn’t appear on the Menus screen. What the…?

I found it exceptionally difficult to track down any information about this, although I did eventually find a tutorial on the very subject but… whoa, those are some old screenshots! The tutorial is a decade old.

Nonetheless, I proceeded to try to make it work, with extensive customizations to suit my needs. Strangely — and it should have been a clue to me — they wouldn’t appear if I gave the meta boxes the name of my custom taxonomy, but if I gave them an arbitrary name, it did work. But there were still some quirks, so I started digging around in the inspector to figure out what was what. Then I discovered something really odd.

They were already in the page. Only, they weren’t displaying. That’s because they all had a CSS class hide-if-js applied. So what’s that all about?

Well… it was really stupid. They were “unchecked” under Screen Options. You know, that little tab at the top right of every WordPress admin page.

My best guess here is that it’s because I had already been to the Menus page for this site before I started building the CPTs and taxonomies, so when I added them to the theme, my personal preferences for Screen Options on the Menus page had already been set, and therefore they defaulted to “unchecked.”

That seems kind of stupid. More specifically, it seems stupid that WordPress gives you the option to turn the items in the Add menu items list off. But it definitely should default any new items that suddenly appear, i.e. that are not already “on” or “off” in your preferences, to “on.” So you, like, know they exist.

Reflecting on my own experience with Brooks’s Law

An interesting take today from Gruber on a concept (Brooks’s Law) that you may not know by name, but may have witnessed in your life.

Personally, I have vivid firsthand experience with Brooks’s Law, from the 7 months I worked at Best Buy corporate in 2000. The BestBuy.com dev team was ludicrously large, and I honestly couldn’t figure out what 99% of them were doing there. Aside from a few project managers, a handful of content writers/editors, and 4 of us on the dev team — 2 front-end devs (including myself) and 2 back-end devs/database admins — I really feel like no one else needed to be there, and the fact that there were so many people made everything take way longer and cost way more than it needed to.

Microsoft contributed $150 million worth of software and consultant time to the project, including a relatively huge team working with some of the other devs at Best Buy who I never had any contact with, all for the process of customizing a 7-figure behemoth Content Management System (CMS) called Vignette StoryServer to suit our needs.

That project dragged on for months, including many months beyond when I left. In the meantime, I spent a weekend building a quick-and-dirty, database-less (since as a front-end dev I wasn’t allowed direct access to databases, because roles!) CMS to allow our writers to load their own content into pages instead of having to send Word docs to the other front-end dev and myself to key in as HTML (stupid!)… and my QDCMS worked so well, they were still using it almost a year after I quit!

Some thoughts on the unintuitiveness of the Mac’s Menu Bar

(This post is adapted from a rambling Twitter thread I just posted.)

I was just reading Nick Heer’s post on transparency in macOS Big Sur and it got me thinking about a related issue I recently dealt with. This is not a new and questionable UI design choice Apple foisted upon us in 2020. It’s a fundamental UI element that dates back to the original 1984 Macintosh.

The Menu Bar.

Although the Mac (and, technically, the Lisa before it) was a ripoff of the original experimental graphical user interface (GUI) developed at Xerox PARC, there is one thing about the Mac that is distinctly different from every other GUI that exists, be it any iteration of Windows, Linux GUIs like GNOME or KDE, the old Sun workstations, even the NeXT OS that Steve Jobs led the creation of after his original ouster from Apple, which formed the basis for Mac OS X and everything Apple has created in this century.

The Menu Bar.

Every other GUI puts a row of menus into the window for each app. On the Mac, the Menu Bar is affixed to the top of the screen, and changes context based on which app is in the foreground. There is a conceptual detachment between apps and their windows on the Mac that does not exist in any other modern operating system, and if you don’t fully grasp that concept, it makes the Mac considerably more confusing to use.

I was reminded of this recently when I had to provide a bit of “tech support” for my parents. My parents are in their 70s. But they’ve had Macs since I first convinced them to buy a candy-colored original iMac over 20 years ago. They’ve only had Macs, although now they do most of their “computer” activities on their iPhones or iPad. But they still use the Mac for banking, printing documents, and a few other tasks that are still a bit obscure to them on the iPad.

And even though they’ve been using Macs for over a quarter of their lives, they still don’t “get” the Menu Bar.

We were on a FaceTime call and they asked me to help them figure out a problem they were having with their Mac. They were describing a weird problem they were having with Safari, and I just could not understand what the issue was. They were describing a sidebar with all of their email in it, and that they couldn’t make it go away.

Since we were doing FaceTime on their iPad, I eventually asked them to turn the iPad so I could see their Mac screen.

I know that their email is through Gmail (because I set it up), so I was expecting to see the Gmail web interface. But what I was actually seeing was the Mac Mail app’s interface. What? How did they manage to get Safari to display that? Then I realized what the problem was.

The Menu Bar.

They had Safari open, as the foreground app, but they didn’t have any Safari windows open. They also had the Mail app open; in fact, it was the only window open on their desktop. But because Safari was the foreground app, the Menu Bar, was saying “Safari” and had the Safari menus.

Why wouldn’t they have just clicked on the Mail window which would make it the foreground app? Seems obvious, but they are nervous novices, and they’re reluctant to click anything, ever, if they’re not sure what will happen. (I know they are not alone in this.)

I told them how to quit Safari, and then how to quit Mail, and they thanked me for fixing their problem. (Did I really though?) But it left me frustrated with the Mac.

Damn it, the Menu Bar is confusing. As loyal as I am to the Mac, putting menus within an app — making it so that the window is the app — is a lot more intuitive and logical than the way the Mac does it. How can an app be open if all of its windows are closed? It doesn’t make sense. Once you conceptually understand foreground and background apps, and have some technical understanding of how the computer works, it’s easy enough to take it all for granted. But at the surface level — which is all the average non-technical user grasps — it makes no damn sense to have the Menu Bar detached from the app it affects.

If there weren’t a thousand other reasons I prefer the Mac, I would be inclined to say that this detail alone makes Windows a superior OS. But it’s not.

Get Gmail to scale inline images to fit the browser window (in Chrome and Safari)

If you use Gmail on the web as your main email platform, and your work often involves people sending you emails with large high-resolution images (which ideally would be attachments, but are often embedded inline in the message), you know this problem. The images are frigging huge in the browser window, and the viewing panel ends up with a horizontal scrollbar, with paragraph text trailing off the screen. Having to scroll horizontally to read emails is really awkward and irritating! Why doesn’t Gmail at least offer an option to auto-scale inline images to fit the width of the window?

I discovered there’s a Chrome extension to fix this. If you’re a Chrome user, just download it and you’re done.

But I don’t use Chrome, I use Safari. And there doesn’t appear to be an equivalent Safari extension. I did, however, continue down the trail to the CSS file in the GitHub project for that Chrome extension. The CSS is quite simple:

[data-message-id] > div:nth-child(2) img:not([role=button]):not([role=menu]):not([width]) {
max-width: 100%;
width: auto !important;
height: auto !important;
}

That’s all it takes to get Gmail to shrink inline images in an email to fit the window. But how do you get Safari to apply that CSS? This is not so hard, either.

First, save the above CSS code into a file, maybe called gmail.css so you’ll remember what it’s for, and save it somewhere that makes sense to you, such as your Documents folder.

Next, open the Safari preferences, and click on the Advanced tab.

Click on the Style sheet dropdown and navigate to the gmail.css file you saved. That’s it! If you have a Gmail message containing a huge image open in Safari while you’re doing this, you should immediately notice the image pop down to a reasonable size. Huzzah!

CSS text-transform can’t do “sentence case” but there’s a really simple alternative

Need to capitalize just the first letter of a text string? CSS text-transform has capitalize but that capitalizes every word.

Fortunately, you can use the ::first-letter pseudo element! In my case, I wanted all of the links in my navigation to definitely start with a capital letter, so I went with this:

#primary_navigation a::first-letter {
  text-transform: uppercase;
}

Slick!