2025-05-28 05:59:00
After I learn of changes in Cloudflare’s priorities, this site’s deployment process goes backward down memory lane.
This site has lived on Cloudflare Pages (CFP) for most of the last four years, having been initially on Cloudflare Workers (CFW) as a “Workers site” after stays on several other web hosts. I’d gained the distinct impression that CFP was the path on which Cloudflare intended to stay where hosting static websites was concerned.
This morning, I learned not only that this was no longer the case but also that I’d “missed the memo” about it, and from a good while ago at that. A few hours of docs-reading and tinkering later, I had migrated the site back to running on a Cloudflare Worker. (Cloudflare doesn’t call them “Workers sites” anymore.)
Every morning, one of my usual practices is to look through the Hugo Discourse forum to see what’s going on in Hugo-ville. Today’s visit brought me up short with a discussion of recent Cloudflare changes and their effect on Hugo users’ hosting on it. Nearly two months earlier, Cloudflare had issued a blog post that was mostly about enhancements to CFW. I had seen the post — the Cloudflare Blog is among many I follow via RSS — but apparently hadn’t scrolled down far enough to catch what I now consider its buried lede, at least for CFP users such as I:
Now that Workers supports both serving static assets and server-side rendering, you should start with Workers. Cloudflare Pages will continue to be supported, but, going forward, all of our investment, optimizations, and feature work will be dedicated to improving Workers. We aim to make Workers the best platform for building full-stack apps, building upon your feedback of what went well with Pages and what we could improve. [Emphases are Cloudflare’s.]
In short: the CFP platform is now largely in maintenance mode, while its parent platform, CFW, is where Cloudflare will be investing its future dev efforts.
I was chagrined, but also got the message. Even though someone on the Cloudflare Discord later told me that I could probably keep things as they are for now, the same person also said that migrating the site to CFW still would be the wisest choice. As I would later mention elsewhere on Discord:
I know CF says that existing Pages projects are OK, but it hasn’t been that long since CF was urging people to transition from Workers projects to Pages projects, and now the opposite seems to be the case . . . Not crazy about having to [migrate], but would rather move with the CF tide than be on a maintenance-only platform.
This meant I’d have to make some changes. And, as the saying goes, there was bad news and good news.
The bad news: Hugo is not among the recommended frameworks. Indeed, all of the current list’s members are JavaScript-based, so one might pessimistically suppose Hugo will be excluded for a while. Also: while there definitely is Cloudflare documentation for migrating from CFP to CFW, following it is no walk in the park.
The good news: Hugo’s amazingly helpful Joe Mooring had created an example repository which showed how to do this, right down to a custom build script and the necessary configuration file. So I adapted those for my site’s purposes, created a new CFW project which would handle my site’s contents, and did the usual site-swapping DNS stuff to point my domain to that Worker rather than a CFP project.
One aspect that initially slowed the migration process was the site’s existing use of a Pages Function to manage my Content Security Policy and the caching of static assets. That was a problem because a Pages Function actually is a Worker, so you can’t just move it, unchanged, into another Worker and expect good results. Fortunately, Cloudflare’s wrangler utility, used for doing a ton of stuff with both CFW and CFP, can compile the Pages Function code into a single file that works within a properly configured Worker.
The only remaining tricky thing for me was that, since October, 2023, I’d been doing my Hugo builds locally and then deploying the results directly to CFP, which I’d found ’waaaaay faster than the usual method of pushing changes to a linked online repository and then waiting for a cloud infrastructure to build and deploy the site. In addition, my way had been letting me push changes to the online repo without having to rebuild online as well, which was a more comforting way to manage version control. Thus, I ended up doing even a little more local retooling but got it to work by (1.) disconnecting the online repo from the CFW project and (2.) changing my local script to deploy to the CFW project rather than, as before, the CFP project.
During all of this rigamarole today, I did give some serious thought to whether I might be better off simply heading back to one of the previous hosts I’d used, rather than hoping Cloudflare doesn’t make it even more complicated down the line to host my humble little site (for the big zero dollars a month I pay for it, of course).
In the end, I stuck with Cloudflare, simply because it quickly became clear that, annoyances notwithstanding, none of the alternatives was truly any better. Besides, I’d still have to deal with various idiosyncrasies, regardless of which host I chose. It wasn’t quite a case of “If it ain’t broke…” — since, after all, I’d started the day assuming it wasn’t “broke” as a CFP site, only to end up deciding otherwise — but it was close enough.
2025-05-22 04:15:00
How to help a small percentage of visitors without inconveniencing the vast majority.
Since my site is a blog (rather than, e.g., a place for obtaining things like tickets to shows), you might think no visitor would need or want to print any of its pages. However, I occasionally hear from those who do, one of whom also requested that I provide print-specific CSS to make the results look better. I did, but knew it also meant I was making my other, non-printing visitors download CSS that they neither needed nor wanted.
As of yesterday, that is no longer a problem.
I’ve noted here before that I won’t let AI write my posts but I will make use of AI when I need help with code. This post is about the latter case.
From time to time, I think about how I might better handle the site’s delivery of CSS. For example, I practice what I call “sorta scoped styling,” wherein I split the CSS into files that get loaded only on certain types of pages. However, this wouldn’t help with the print CSS. While I did mark its link as media="print" — which, among other things, makes browsers treat it as a lower-priority download — I wanted to find a way to load it conditionally, only when that small number of users actually tried to print one of the site pages. So, yesterday, I asked ChatGPT:
Is there a way, through JavaScript or other coding, to have a browser download a website’s print-specific CSS file only if the user is actually printing a page? The obvious intent is to reduce how much CSS the website must deliver, especially since a relatively small percentage of users actually print web pages anymore.
That began a “discussion” which, although the AI’s response contained some of the hallucinatory behavior for which LLMs have become infamous, successfully gave me code which met my needs.
The code uses the matchMedia() method (and, for maximum compatibility, it also acts on beforeprint events) to detect an active print request from the browser. Only when such a request occurs will the code load the print CSS; so, now, only those users who are actually printing content from the site will download the additional styling to make their printouts look more “print-y” and less “web-y,” so to speak.
Armed with this AI-created JavaScript code submission, I added it to the appropriate partial templates for my Hugo site’s purposes.1 (For those who choose to disable JavaScript, the noscript section at the end delivers the print CSS anyway, just the way everyone else formerly got it.)
{{- /* for those who've requested CSS for printing */ -}}
{{- $printCSS := resources.Get "css/print.css" -}}
{{- if hugo.IsProduction -}}
{{- $printCSS = $printCSS | resources.Copy "css/print.min.css" | postCSS | fingerprint -}}
{{- end -}}
{{- with $printCSS -}}
{{ $safePrintLink := $printCSS.RelPermalink | safeURL }}
<script>
function loadPrintStylesheet() {
if (document.getElementById('print-css')) return; // Prevent multiple loads
const link = document.createElement('link');
link.rel = 'stylesheet';
link.href = '{{ $safePrintLink }}';
link.type = 'text/css';
link.media = 'print';
link.id = 'print-css';
{{- if hugo.IsProduction }}
link.integrity='{{ $printCSS.Data.Integrity }}';
{{- end -}}
document.head.appendChild(link);
}
// Use media query listener
const mediaQueryList = window.matchMedia('print');
mediaQueryList.addEventListener('change', (mql) => {
if (mql.matches) {
loadPrintStylesheet();
}
});
// Fallback for browsers that fire beforeprint/afterprint
window.addEventListener('beforeprint', loadPrintStylesheet);
</script>
<noscript>
<link rel="stylesheet" href="{{ $printCSS.RelPermalink }}" type="text/css" media="print"{{- if hugo.IsProduction }} integrity="{{ $printCSS.Data.Integrity }}"{{- end -}}>
</noscript>
{{- end }}This works fine on Chrome and Safari, as well as browsers based on their engines (Blink and WebKit, respectively), but I did find one oddity in Gecko-based browsers such as Firefox. While other browsers will load the print CSS when their respective Print Preview windows pop up, a Gecko-based browser will not load it if “Disable cache” is enabled — as often is the case when one is using the browser’s development tools. In that specific circumstance, you end up having to cancel out from the Print Preview window and then load it again to see the desired effect. By contrast, the other browsers will properly load the print CSS even with “Disable cache” enabled.
That said, now we’re talking about a glitch that affects an even tinier number of users than those who have any need for my site’s print CSS. Namely, they’re users who (a.) are using a Gecko-based browser and (b.) want to print from my site and (c.) are viewing my site with “Disable cache” enabled. And, even for them, closing and reloading Print Preview will fix the problem.
My original also contains code that, in production, enables a serverless function to provide a nonce for Content Security Policy purposes. ↩︎
2025-04-29 01:26:00
Whither the web, plus my reaction to some Fediverse drama.
This originally was going to be about just one thing, namely the overarching subject of two recent and significant blog posts by Open Web Advocacy (OWA). However, I needed to add a second “thing” when some unexpected-to-me Fediverse drama occurred even before I could actually start writing this.
We’re a few months away from a court ruling in the antitrust case wherein Google has been found guilty of having a monopoly in the web search biz. If the U.S. Department of Justice (DOJ) were to get its way in the ruling, Google would have to divest itself of the Chrome browser and stop paying makers of other browsers for defaulting to the Google search engine. I’ve already written in two posts this year about unintended bad results from those actions, so I was pleased in the last few days to see two major OWA blog posts on the subject.
In a normal day up until this past Friday, I may spend all of two or three minutes looking at posts on Mastodon, so Fediverse drama easily can happen without my knowing about it. Such was the case in the last few days, when I suddenly learned of a firestorm in certain Mastodon instances over the instance I’d been using for some time, Fosstodon.
The short story is that:
Thus, in order to be on an instance that wasn’t (to my knowledge) in the crosshairs of such actions of fedi-banishment, I migrated my account from Fosstodon to another tech-oriented instance, Hachyderm. There, I am @[email protected], to which this site’s appropriate links have pointed since yesterday.
I recommend Corey Snipes’s post, “Thoughts on Fosstodon,” as a good explanation of how it felt to us Fosstodon users who found ourselves unexpectedly involved in a war of angry words and accusations. Note that he, too, moved from Fosstodon to Hachyderm as a result of the goings-on. Also worth reading are these posts from the founders of Fosstodon:
2025-03-25 03:55:00
Sometimes, gut feelings get punched in the gut.
It can be unsettling to recognize just how much trust that software vendors expect us to place in their wares. The same can occur when, having given that level of trust, we find ourselves perhaps wishing we hadn’t. The last few weeks have provided for our examination two key cases in point: the Mozilla Firefox Terms of Use (TOU) SNAFU and the purchase of Strongbox.
Mozilla issued two significant blog posts near the end of February, 2025: “Introducing a terms of use and updated privacy notice for Firefox” and, two days later, “An update on our Terms of Use.” As the second post’s title suggests, the first post had provoked an avalanche of questions and concerns from the browser-watching community, but the second post helped little or not at all in stemming the flow of worries.
There was sufficient drama surrounding all this that I suspect you’ve already read and/or seen plenty about it, so I’ll avoid adding to it here. If you need additional context, just search for something like Firefox Terms of Use controversy and you’ll probably get more results — with, yes, a goodly mixture of opinions and sometimes well-founded comments — than you could hope to see. Suffice it to say these posts (and the resulting drama) shocked the increasingly small bloc of Firefox users, as well as those non-Firefox users who’d nonetheless wished the browser well in its quest to survive in a world trending toward domination by Chrome and Chromium.
Mozilla shed a ton of good will, not to mention much of the trust of Firefox’s previously most loyal users, with both these actions and Mozilla’s attempts at explaining them. Just exactly why Mozilla felt it necessary to make the changes is the key, I think, but at this writing we don’t know the answer to that. It comes down to which kind of legal exposure that the language in the TOU and the updated Privacy Notice was intended to prevent: i.e., was it to protect Mozilla regarding data-selling it already had been doing, or data-selling it was planning to do? Neither is a good look for a company and browser which have long proudly presented themselves as privacy-friendly.
Until a few days ago, security-minded Apple device users looking for KeePass-compatible password management software could safely select the Strongbox app for macOS and iOS. That changed with the announcement that Applause was buying Strongbox. Online communities of Strongbox users almost uniformly said they felt betrayed by this takeover of the app. (For example, check this Reddit thread.)
The particularly sensitive nature of the data one entrusts to a password management app only magnified these users’ outrage over the idea that Strongbox would now be in the hands of an entity which they hadn’t selected and didn’t want, especially one which has been known for (among other things) adding “phone-home” analytics to other apps it’s acquired. Moreover: unlike some other KeePass-compatible apps, Strongbox is not completely open-source, so “ah, just fork it and move on” isn’t an option even for those willing and technically able to go that route.
As I wrote a couple of months ago:
. . . I increasingly realize and reluctantly accept that most of my choices in life are from among products and services controlled by really nasty people and/or entities . . .
. . . but, that said, I also increasingly realize and reluctantly accept that, from time to time, it’ll turn out that previously trusted entities and tools either are no longer worthy of that trust or, in fact, may never have been so in the first place. That’s life, I guess.
2025-02-26 05:38:00
Some thoughts on where things are in the world of web browsers.
While I stopped doing any meaningful testing of web browsers over a year ago, I remain interested in the arena in which those apps engage daily. Here are some semi-idle thoughts on what’s been going on there of late, especially for those of us who actually care about which browsers we use, and what could follow in the not-too-distant future.
The latest Chromium-based browser to fall in line regarding whacking support for Manifest V2 extensions apparently will be Microsoft Edge. Although there probably never was much serious doubt whether Microsoft would buck Google on the Manifest V3/V2 issue, there now should be none. It won’t.
In an ideal world — i.e., one in which the vast majority of the world’s web users weren’t so willfully ignorant about browsers in general and browser extensions in particular — Mozilla’s stance regarding Manifest V3/V2 would help keep the Firefox browser afloat. We Do Not Live in That World, nor shall we.
While perusing one of the seemingly endless “my-browser-is-great-and-all-others-suck” battles on Reddit, I found a link to an interesting Lobsters discussion about why and how the Brave browser blocks the Lobsters site, a situation of which I hadn’t been aware. If you’re using Brave, use this link from the Internet Archive; otherwise, use this link from Lobsters itself.
Whenever such discussions on Reddit and elsewhere get into the whole issue of whether Firefox will even continue to exist if the U.S. Department of Justice1if an upcoming court ruling eventually drops the big one on Google, thus cutting off all that money Google pays Mozilla for getting the preferred search engine setting in a default Firefox installation, a frequent theme seems to be: “Well, it’s okay because Firefox is open-source.” Those taking that position note that there already are numerous Firefox forks so, even if Mozilla dropped the Firefox project altogether, those forks would continue and others would follow. Again, We Do Not Live in That World. Maybe, for the much simpler web of thirty years ago, small (and probably unpaid) teams of devs could keep a web browser going; but the web of today and the future is far more demanding. As is often noted, today’s browsers have gigantic code bases and essentially are “little” (but not too little) operating systems in and of themselves. So not only Firefox and its forks but, to be clear, Chromium and its forks — with the possible exception of Edge, thanks to Microsoft’s virtually unlimited resources — could easily face an existential crisis later this year. And not just in the U.S., either, so non-U.S. readers of this piece shouldn’t feel overly safe from the repercussions of said crisis.
Of course, there is one other major browser, namely the Webkit-based Safari, that also has a huge bankroll behind it. However, it runs on only the devices of its parent company (Apple, of course), so it’s irrelevant to many if not most of the world’s users. There was at least a Safari for Windows for a few years in the late 2000s and early 2010s, but that’s never coming back; nor do I expect there ever will be one for either Android or Linux. Thus, regardless of its apparent excellence on its targeted Apple platforms and its improving adherence to web standards, Safari is and will remain a non-factor in the browsers landscape for the vast majority of users.2
This is up to a judge’s ruling, not (as I erroneously wrote) the U.S. DOJ. ↩︎
In the same vein, the much-hoped-for Ladybird browser likely won’t be relevant as a truly cross-platform browser for a very long time to come. ↩︎
2025-01-17 05:54:00
I watch, I think, I write: the latest in a string of thoughts on what’s been happenin’.
It’s been about a year since the previous entry in this series of observations on things going on at the time. While that’s hardly a requirement for another — ah, well, let’s just do this, shall we?
The one-man development band behind one of my long-time app faves, the unbelievably full-featured MailMate email app for macOS, has announced a move to the subscription model. Previously, MailMate was a one-time purchase of about $50 but came with encouragement to donate to the project as a patron, particularly if the app was in play within a business environment. Starting with the currently-in-beta v.2.0, this changes to a $40/year subscription (i.e., $10 every three months). One interesting aspect is that a non-business user can still download and use MailMate without paying for it but, after a while, it will start to put identifying text in headers that make clear one is being a freeloader; those who’ve seen online videos that are “watermarked” with logos of unlicensed video-editing apps will get the idea. Business users are required to get the necessary number of per-user subscriptions, although the enforcement mechanism will still be the “header shaming,” if you will. Those MailMate users who bought their one-time-purchase licenses years ago are grandfathered until as late as July 1, 2025; after the applicable date, each such user must either drop MailMate or avoid the “header shaming” by starting on the subscription plan.
It’s increasingly likely that most web browsers will be affected by the ongoing battle between the U.S. Department of Justice and Google over the latter’s perceived search monopoly, but it’ll be later this year before the planned ruling that could clarify what the effects will be. A November, 2024, DoJ filing pushed for Google to divest itself of the Chrome browser. However, at this time, it’s unclear whether that would also require Google to cease being part of the Chromium project on which not only Chrome but also Microsoft Edge, Brave, Opera, and numerous other browsers depend. As one observer put it:
If [the DoJ is] is really just saying, ‘Give up Chrome,’ that would be very weird because Google would still control all the underlying technology and they could just tank anyone who would try to do stuff with it, including anyone who ends up owning Chrome.
Given that Google made well over ninety percent of 2024’s code commitments to the Chromium project — and that many other key projects, such as Electron, are Chromium-based — it will be extremely important how Chromium itself falls out from all this. And then there are Google’s counter-proposal and the creation of Supporters of Chromium-based Browsers, each of which is a completely different story.
One other aspect of the DoJ/Google snarl is that Google could be forced to stop paying other browser-makers to include Google as their default search engines. If so, the organization behind the already ailing Firefox, which is the last major cross-platform browser not based on Chromium, would lose the vast majority of its annual funding. (And there are other, lesser-known browsers which depend on Firefox’s Gecko engine. I’d guess they also would go down the drain soon thereafter, no matter how industrious or high-minded their developers might be.) Given how low Firefox’s market share currently sits, one can imagine the DoJ wouldn’t spend much time worrying about it.
Whether one definitely does get more cynical as one ages, I can’t say. In my own case, however, I increasingly realize and reluctantly accept that most of my choices in life are from among products and services controlled by really nasty people and/or entities, and my only true alternative would be to go totally off the grid à la Ted Kaczynski — which I’m not going to do. If that makes me a lesser human being, well, then, it does. In the same vein, I did find considerable common ground with Kev Quirk’s blog post, “On Virtue Signalling.”1
My writing app marks signalling as a typo. Of course, my writing app doesn’t know that Quirk is using the UK spelling. ↩︎
