How did I not know about ClassicPress before now?

ClassicPressI’ve been using WordPress for 15 years, and have made it my go-to platform for all new websites I’ve built since 2014. So how is it that it took me three years to discover that ClassicPress exists, especially since its whole raison d’être is to keep the pre-Gutenberg dream of WordPress alive?

On one hand, being a solo developer — even before the pandemic — has always kept me a bit out-of-the-loop, especially since I don’t attend conferences. But I suspect the fact that I knew nothing of this also speaks negatively to the project’s future.

Is it gaining enough traction to continue to exist? Is it really a viable option to use on new professional projects in 2021?

Has the Gutenberg ship sailed? Well, yes, it has. But my issues with the current and future state of WordPress go beyond Gutenberg, to the nature of Automattic’s role in steering the ship, the greater vision of what WordPress is and should become, and… well… Matt Mullenweg’s personality. I feel like the future of WordPress is increasingly diverging from what I hoped to get out of it as a platform, and it’s clear that I’m not alone. That’s why ClassicPress exists.

There are a lot of things to like about ClassicPress, right out of the gate, besides the most obvious element, which is the absence of anything Gutenberg. It does away with a lot of the cutesy crap that’s rolled into WordPress by default, not least of which being the annoying proliferation of the word “howdy” and the beyond-pointless-to-actively-detrimental* plugin Hello Dolly.

As I look to my own future with WordPress and/or ClassicPress, I am primarily thinking about two things: 1) how/if I will continue to use it as the platform of choice for client projects, and 2) what the future will be for the plugins I have contributed to the WordPress community, and more specifically, my commercial plugin, ICS Calendar Pro.

I’ve been struggling with these matters for almost four years now, ever since Gutenberg emerged on the scene and went through its early phases of absolutely sucking, to its too-soon release as the default WordPress editor, to its current state as a mostly good but highly quirky and weirdly limited page building tool.

The timing was not great for me, as I had just recently gone “all-in” on 34 Blocks, my own block-based starter theme that I have been using to create all of my client sites since 2017. It started from a series of one-off client themes beginning around 2015 and is built around Advanced Custom Fields and its “Flexible Content” fields. It’s all much more in line with what “WordPress” has always meant to me. But as WordPress becomes Gutenberg, my vision of what this tool is and the reality of what it has become are increasingly at odds.

In those four years I’ve been bouncing around between several different ideas:

  • Suck it up and finally embrace Gutenberg development, learning a bunch of new stuff like React, in which I am not only wholly disinterested but with which I philosophically disagree?
  • Cling for dear life to Classic Editor and pray the gods of Automattic keep it on life support?
  • Switch to an entirely new platform, whether that might be another open source or commercial CMS, or a complete SaaS approach like Squarespace?
  • Get out of the web development business entirely?

So far, I’ve mostly stuck with “cling for dear life to Classic Editor” although I have been tempted a great many times to “get out entirely.” My enthusiasm for this field hasn’t been helped by things like the caustic toxicity of social media, the rise of absolutely godawful and not-at-all-intuitive-regardless-of-their-claims-to-such interface concepts (see: Google’s Material Design), and technical snafus like Digital Ocean’s entire subnet getting spam blacklisted and them doing absolutely zero to rectify the situation.

I’ve been taking baby steps towards making sure I’m not caught out when/if they pull the plug on Classic Editor. My 34 Blocks theme is to the point where it works adequately in the Gutenberg environment, and I’m even moving it towards a potential future where I would scrap my ACF Flexible Content blocks altogether, in favor of Gutenberg blocks.

But I’ve also made sure ICS Calendar is backward-compatible with WordPress 4.9, so it works with ClassicPress. And I’m still looking at other tools, now and again, in case I need to switch directions entirely.

It’s happened before. After the first half of my career consisted largely of building “bespoke” CMSes for corporate overlords, I went out on my own. From 2008 to 2014 I sunk thousands of hours into the development of a feature-rich, completely custom-built CMS based on the CakePHP framework, which I used to create about 10 client sites per year throughout that period.

But the writing was on the wall for that project when I found it impractical to upgrade the CakePHP core past version 1.3, which was incompatible with PHP 7. (CakePHP is currently up to version 4.1 and now requires a minimum of PHP 7.2, for an indication of just how doomed my old CMS project was.) By 2014 I gave up on it and switched to WordPress. Has the time come to move on again? If so, I feel like in some ways, switching to ClassicPress would be a step backwards, or at best a lateral move, and would not set me up well for the future.

Where does that leave me? I don’t know. There are options. But embracing Gutenberg and the future of WordPress is not at the top of the list. If anything, it’s never been lower.

* Why is Hello Dolly detrimental? The justification for its inclusion in the default WordPress build is that it is a demo for new developers to learn how to build a WordPress plugin. The problem is, it’s a terrible, no good, entirely wrong example of a plugin. It’s ancient and doesn’t conform to any modern WordPress coding standards, and it’s so rudimentary that there’s no useful structure to build on for people who want to create an actually useful plugin. So why is it still included? I don’t buy the “demo” argument. It’s still there because Matt wants it to be, and that in a nutshell is my problem with Automattic running the show. (I mean look, he even “cleverly” misspelled the company name so his own fucking name is embedded in it. That annoys me every damn time I see it… almost as much as “howdy.”)

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!