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.

Bootstrap 5 Carousel: position captions outside (i.e. below) the images

(If you want to get right to the point, a full code example is provided at the bottom of this post.)

I’m not a Bootstrap expert. During most of its evolution, I’ve mostly ignored it in favor of rolling my own… everything. I finally really embraced Bootstrap when I had a rush project in October 2022 that was way too precisely designed to work with WordPress, especially Gutenberg. (And the client didn’t need editing capabilities.) So I decided to hand-code it, but to use Bootstrap to… uh… bootstrap my HTML/CSS layouts.

I think Bootstrap 5 is excellent. I wish Gutenberg was built on top of it instead of the idiosyncratic house of cards it’s actually built on, but whatever.

As it happens, I’m actually now using Bootstrap 5 with Gutenberg for some custom blocks, specifically a Carousel block. One of the options I want to provide in my block is the ability to show the carousel’s captions and controls outside of the image, but apparently, at least with Bootstrap 5, that’s not an option.

I decided to Google for a quick solution before creating my own and I came across… this. I’m sure it gets the job done, but it seems severely over-engineered, so here I’m presenting my own comparatively simple, CSS-only solution.

Basically there are two things you need to do: 1) move the absolute-positioned caption text below the image, and 2) add padding to the bottom of the container, so the caption has somewhere to go instead of just overlapping the content below it.

Let’s start with the second item first:

.carousel { padding-bottom: 4rem; }

There may be some trial and error here, as you need to make sure you’re accommodating captions of varying length. I will admit this is not fully thought out here, and unlike the rest of what is about to follow, it may be a deal breaker under certain circumstances. But let’s assume your captions are a fairly consistent length, and you can determine how much padding you need.

Getting the caption pushed below the images is easy…

.carousel-caption { top: 100%; }

…except, oops, vertical overflow is hidden. Let’s fix that:

.carousel-inner { overflow: visible; }

Of course, if you have your transition effect set to slide (which is the default), that now spews stuff all over the page in an ugly way. But we can fix that by hiding overflow on the outer carousel element instead:

.carousel { overflow: hidden; }

You might, at this point, wonder why I didn’t just set overflow-y: visible on .carousel-inner which seems perfectly reasonable, and which, of course, I tried. But for reasons I couldn’t be bothered with investigating, that ended up causing .carousel-inner to just show a vertical scrollbar and not display the caption unless you scrolled it. Ugh. No matter, the above takes care of it.

That’s pretty much it, as far as the captions go. But if you’re using the controls (previous/next arrows) or indicators (dots/lines for the number of slides and current selection), you’ll notice there’s some weirdness to their placement, so let’s fix that too. The indicators just get shoved to the bottom of the container, so your bottom padding can accommodate that. But if you want to move them back up onto the image, you just need to offset that extra padding, like this:

.carousel-indicators { bottom: 4rem; }

Make that value the same as the bottom padding you added to .carousel itself.

As for the controls, since you’ve made the overall container taller, they’re now a bit too low rather than being vertically centered on the image. Guess what… setting their bottom value to match the extra bottom padding fixes their placement too!

.carousel-control-next, .carousel-control-prev { bottom: 4rem; }

So, putting it all together as concisely as possible, here’s what we have:

.carousel { overflow: hidden; padding-bottom: 4rem; }
.carousel-caption { top: 100%; }
.carousel-inner { overflow: visible; }
.carousel-control-next, .carousel-control-prev, .carousel-indicators { bottom: 4rem; }

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.

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.