Category: Computers & Technology - Page 11

This is the kind of thing that I find maddening about Gutenberg

First off, if you are the regular reader of this blog, you are painfully aware of how much I am waffling on rejecting or embracing Gutenberg (a.k.a. the WordPress Block Editor). There are things I genuinely do like about it, but I also have some fundamental disagreements with its approach (like the facts that it writes inline CSS directly into post content, or that its templates don’t support PHP code).

And then there are the weird little quirks that just make using it much more difficult than it needs to be. In general I have learned that this comes down to the incredible finickiness of JSON. Fine. But the fact that one character out of place in the theme.json file can break everything seems a bit ridiculous… or at least, a big step backwards for usability.

Fix your syntax. Sure. I wish JSON allowed trailing commas the way PHP — and even JavaScript! — does, but I can grok the fact that it doesn’t and learn to adapt. What I have a bit more trouble with is the problem that struck yesterday, only because it was so hard to pin down.

I’m working on a new, small block theme as a one-off for a unique project — a website that will feed menu board monitors in a pizza place. Seems like a perfect opportunity to practice and experiment a bit with what Gutenberg can do. (And, after over a decade of trying to find the “right” way to give restaurant staff a reliable but still easy-to-manage web interface for updating menu information, I actually think Gutenberg’s Block Patterns might be the optimal solution.)

So here’s the maddening thing. I was setting up my theme.json file like a good Block Theme developer, defining all of my colors, typography, etc. And then I started loading in some test content. All looked fine on the back end, in the Block Editor itself. But none of the styles were getting applied on the front end!

I googled the problem, of course, and found a WordPress forum thread about this very issue.

Huh. Sure enough, what’s described in the thread was exactly what was happening in my case. I had this line in my code (font names changed to protect the innocent):

"fontFamily": "'Helvetica Neue', 'Comic Sans', 'sans-serif",

Do you see the problem there? (No, it’s not the trailing comma… that actually belongs, in context.) It’s the stray apostrophe before sans-serif. Removing that fixed the problem.

Now, if this were just in straight CSS, I would have seen the problem immediately, because the syntax highlighting in BBEdit would’ve gone all wonky. But since this was inside a text string in JSON, it looked just fine, and I didn’t notice the apostrophe was there.

I get that the parser that converts the contents of theme.json into CSS would get thrown off by this. Honestly, I’m surprised it didn’t cause the whole page to bork with a PHP fatal error… I’m pretty sure earlier versions did throw a fatal error if there was any problem parsing the theme.json file. So this is… an improvement?

I also get that the generated CSS output would not work properly. What I don’t get is that it all looked correct in the Block Editor. Why was the Block Editor on the admin side able to “fix” this issue, but on the front end it didn’t? It doesn’t make sense!

Anyway, trying to unravel that mystery wasted about an hour late yesterday afternoon, when I was finally starting to get productive after having a near existential crisis over Gutenberg for most of the week.

These are hard times to be a WordPress developer. No, strike that. These are hard times to be a generalist web developer who happened to make the fateful decision 8 years ago to go all-in on WordPress.

My hot take on 303 Creative v. Elenis

This morning I’ve been preoccupied with 303 Creative v. Elenis, a case presently being heard by the Supreme Court. I have a lot of complicated thoughts on this case. Too many to sit comfortably with long enough to craft a well-structured blog post about, when I have actual work I need to be doing.

But since this case has potential implications for my “actual work,” it matters. I’ve been exploring the idea with some friends on Facebook, so for now I am going to just encapsulate my thoughts with a few lightly-edited excerpts of what I posted there.

First off, let me be clear that I’m on the opposite end of the political spectrum from Lorie Smith, the plaintiff in this case. But we do similar work, and I absolutely feel that as a freelance consultant, I should have a right to choose which projects I take on. I would have no problem building a website that was pro-same-sex-marriage. But I would absolutely choose not to work on a website that was anti-same-sex-marriage.

In broader terms, I would eagerly accept work that fights discrimination, while I would actively refuse to accept a project that promotes discrimination. But it’s impossible to just invert my political beliefs and say that’s where Ms. Smith stands. Because the work itself isn’t for or against discrimination. It’s the refusal to do the work that constitutes the discrimination. Still, should she be legally compelled to do work she personally disagrees with?

That case with the bakery a few years ago always made me feel uncomfortable, even though ultimately I sided with the gay couple who wanted the cake. I think I’ve hit on the key point: there is a significant difference between selling an off-the-shelf product in a public space, vs. accepting a job to produce new custom work to client specifications, or to do future work-for-hire off-site.

In baking there’s a “gray area” in work-for-hire, unlike web design, and it comes back to the generic sheet cake example. (The baker was willing to produce a generic cake for the couple.) There’s no equivalent to a “generic sheet cake” in web design, other than a service like Squarespace. I don’t think a service provider (e.g. Squarespace) that commodifies a website as a prebuilt, “off-the-shelf” product should be allowed to discriminate in who uses its service, as long as their activities are legal. That’s radically different from compelling a “creative” to produce new, custom work promoting ideas they don’t agree with.

But ultimately this whole case just reeks of ulterior motive by the political right wing. Any reasonable person in my position, when asked to take on a project they disagree with (or just don’t care to do, or are too booked up to take on) should just offer to refer the potential client to someone else and leave it at that. This lawsuit is not about individual freedom of speech… it’s a salvo in a culture war. I suspect it could even play a role in future cases concerning content moderation on social media sites.

Don’t use JPEG for logos, example #24,315

A client just sent me a logo to add to their website. I let out a little whimper when I looked at the file and noticed that, as is so often the case when someone sends me a logo, it’s a JPEG.

Don’t use JPEG for logos!

Without naming names (or, hopefully, showing enough of the logo to give away the identity), here’s a close-up detail of the actual JPEG I was sent, which does a really good job of illustrating the issues. I zoomed way in on the file in Affinity Photo (my preferred alternative to the 800-pound gorilla of design software), and captured a screenshot which I am sharing here as a PNG — the correct format for logos, because it doesn’t introduce these “compression artifacts“:

Just in case the problems are not readily apparent to your eye, here’s a version where I’ve cranked up the contrast to accentuate the inconsistency of the colors in the image:

And for comparison, here’s what the same level of detail would look like if the image were delivered in PNG format instead of JPEG:

Of course, these days we can do even better than PNG. If a logo is a vector-based design (which it really should be), we can use SVG to get a perfectly sharp rendering of the logo at any size. Here’s what that would look like, zoomed in the same amount:

To be clear: the logo is not for my client’s organization itself. If that were the case I would have pushed back. It’s the logo of a partner organization that was provided to my client to add to the site, so there’s probably little that could be done. (OK, that’s not true; I could — and did — do what I often do in this situation. I went out and found a PNG version of the logo myself.)

The fog of… blockchain?

You may not necessarily agree with his politics or his opinions (although, to be honest, I usually do), but Paul Krugman rarely gets the facts — or his interpretation of their implications — wrong. And this is a pretty good takedown of the entire principle of cryptocurrency and blockchain.

A lot of the more technical criticism of blockchain has been — justifiably — its environmental cost. But something that rarely gets mentioned does at least get that much from him here: “Why go to the trouble and expense of maintaining a ledger in many places, and basically carrying that ledger around every time a transaction takes place?”

Simply put, crypto doesn’t scale. That has been so blindingly obvious to me from the beginning that I couldn’t understand why the supposedly tech-genius “bros” championing this stuff didn’t see it. Another quote, from a very different context, seems fitting here: “It is difficult to get a man to understand something when his salary depends on his not understanding it.”

Actually, now that I think about it… I wonder if I’ve had Upton Sinclair wrong all these years. Maybe he wasn’t talking about labor when he wrote that, but management.

Musings on my future with WordPress

Regular readers of this blog, if such exist, may have noticed that one of the three (!) posts I published yesterday has gone missing. I unpublished it this morning, as I further contemplate the future of WordPress, and whether or not I want to be a part of it.

First off, I need to make it clear that I will be a part of it, because ICS Calendar Pro has become a substantial part of my business, and I only see that growing. The question for me, however, is whether or not the rest of my business will continue to revolve around WordPress the way it has since 2014.

I’ve been building websites for much longer than that. By 2014 I had already been writing HTML for 20 years, and building websites professionally for 18. My decision to go all-in on WordPress in 2014, and abandon the CakePHP-based custom CMS I had been painstakingly crafting for the previous 6 years, hinged on my realization that WordPress was evolving quickly into a powerful, general-purpose CMS.

But therein lies the problem. I am part of a very large community of serious, professional web developers who embraced WordPress (the open source project) as a general-purpose, if decidedly idiosyncratic, Content Management System (CMS). And we’re the ones who collectively turned it into the dominant platform that it is today. But I don’t think Automattic, or much of the WordPress core team, sees it that way. They’ve never lost the original vision of it as a simple blogging platform, even though the web world has largely moved beyond blogging (at least the open source, self-hosted kind).

Automattic (the company owned by WordPress creator Matt Mullenweg) isn’t competing with Drupal or Joomla. They’re competing with Squarespace, Wix and Medium. And as such, their focus is on how to make WordPress.com (their commercial, hosted version of WordPress) into a stronger challenger to those platforms. The open source WordPress project that I and my fellow developers have grown to love is just an afterthought to that mission. Or at least, so it seems, with the aggressive pushing of Gutenberg (a.k.a. the Block Editor) since 2018, and even more alarmingly, full-site editing (a.k.a. Site Editor) this year.

Gutenberg is one thing. I started off hating it, not because it was a bad idea, but because it was a poorly executed one — or more specifically, that it was forced on the WordPress community before it was mature enough to replace the classic editor. But I absolutely believed in the idea of block editing in general. I had already been working extensively on my own custom theme that was built around ACF Flexible Content. Many others turned to “page builder” plugins/themes like Divi, Beaver Builder, WP Bakery, or Elementor.

I despise those page builders because they introduced their own, often convoluted interfaces that look and feel nothing like WordPress, and most frustratingly, are not easier for end users. The only people they’re easier for are “no code” website builders, and maybe I’m an old man yelling at clouds, but I feel like you shouldn’t be charging people money to build websites for them if you don’t know how to write code. Less curmudgeonly: These page builders require just as much work to learn as writing code does, but if you learn to code, you walk away with a much more valuable skill.

But I digress. For the sake of adding block editing flexibility to the content management aspects of using WordPress, I have no problem with Gutenberg as it stands in 2022. In fact, I’m using it to write these words. It is much nicer than the old classic editor — at least, now it is; not so much when it debuted in 2018 — and more importantly, it’s the WordPress way as opposed to page builders. Even if it’s only “the WordPress way” because WordPress has changed to be like it, rather than it fitting what WordPress was before.

I still have a major problem, in principle, with the entire concept of the Site Editor though. And the blog post I cited earlier this year feels more relevant to me than ever. I still don’t think it’s really for anybody. Except Automattic.

It’s not that the Site Editor is going to put people like me out of work. It’s that, if this is the direction things are going, it makes absolutely no sense for people like us to continue to use WordPress as our platform of choice.

Taking this thought a step further (and following the links), we get to the heart of the matter for me, which is perfectly summed up in a post called The Complicated Futility of WordPress. Specifically (emphasis mine):

The thought of client side marketing interns ‘play(ing) around with site-wide designs’ should make the blood of any professional run cold. Sites that have been painstakingly, designed and built, reviewed and refined to the last detail every step of the way with stakeholders on the client side, optimising UX, legibility, performance and upholding the client’s brand can now be squelched in an instant by someone 3 months into their job who prefers yellow.

No doubt we could work up a system to prevent this, we can restrict access and force use of the classic editor etc, but that’s where the ‘complicated futility’ comes in. It’s one thing to find a way to cherry pick aspects of the software to serve your purpose, it’s another thing entirely to try to build in complete opposition to it.
—coderjerk

For me, it’s been a difficult year of loss, with the death of my mother in September (and several months of decline preceding that), and some distance from my work. It’s also been a year when I have struggled constantly, through my efforts at building a new Block Editor-friendly theme to replace my trusty old ACF-based one, to find some sense in a lot of the decisions that have been made about how Gutenberg works and the direction WordPress is going. My low motivation, easy distraction, and generally slow progress on the theme, I am just now realizing, has been due to the amount of cognitive dissonance I was feeling, as I realized that everything about my approach to building websites as a professional developer, everything I am looking for in the tools I use to do my job, seems, as coderjerk put it, to be in complete opposition to what WordPress is becoming.

As a freelancer, I keep fairly diligent records of my time spent working on client projects. I have to. It’s how I make money. But I am not as rigorous in tracking how I use my personal time. I wish I had logged the time I’ve spent over the course of 2022 experimenting with, and then abandoning, various potential WordPress replacements. It usually only takes me an hour or two to realize that, as much as I am resisting learning the seemingly nonsensical framework (if you can call it that) for building custom blocks, block patterns, block themes, and everything else in the “new way” of WordPress, it is still probably superior to whatever platform I’m testing out that day. So I’ve dismissed ClassicPress as a backwards-looking dead-end. I’ve tried and cast aside more random niche CMSes than I can recall. (But, to prove this isn’t just empty talk, a few of them are e107, Craft, and Concrete, and I’ve even contemplated Drupal, of all things, as well as resurrecting my old CakePHP-based system.)

None of that has gone anywhere, because it was immediately apparent to me that none of them felt right. Not built on the right foundation, not polished enough, not enough momentum behind them. Well, nothing has as much momentum as WordPress. But now I’ve begun to wonder, is it momentum… or inertia?

Today’s discovery feels different. Since I agreed with so much of coderjerk’s post, I took the final suggestion of Twill to heart. I don’t have experience with Laravel, but I know that back when I was in CakePHP world, it was a big competitor. An employee of mine — in the short sliver of time when I had employees — built a custom site for a client using Laravel and he loved it. Twill is built on Laravel, so it seems fitting for me that the next chapter of my career might revolve around a return to MVC frameworks, in their much more modern, mature form. And while this gives me a lot of new stuff to learn — I’ve avoided doing much with systems that rely on Composer and managing dependencies — it all feels like the right stuff to have to learn in 2022, vs. what I’d have to learn to be a Gutenberg ace.

I’ve spent a few hours this afternoon getting the lay of the land with Twill. And while it has thrown me a few surprising challenges even in the basic setup, it’s also giving me a giddy feeling of just having fun geeking out on learning new systems… those moments of delight when I finally get how something works and I see the genius behind it. I’ve spent a lot of time trying to understand the structures underlying Gutenberg, and the only feeling that ever gives me is… “What… why???”

I plan to spend most of tomorrow continuing to tinker with my little Twill test setup. I may still end up scrapping it, and I know I will probably never completely leave the immense gravitational pull of WordPress. But I’m feeling more excited about web technology than I have in years, and more optimistic about my future in this business.