General note: This site’s appearance, configuration, hosting, and other basic considerations will change over time. As a result, certain content on this page could be at variance with what you’re currently seeing on the site, but the two were consistent when this post originally appeared.
Each entry in the “Gems in the rough” series is a collection of tips, explanations, and/or idle observations which I hope will be at least somewhat useful to those of you with websites built by static site generators (SSGs).
Getting giscus going again
I noted in the previous “Gems in the rough” that I was trying the giscus commenting system. giscus uses the GitHub Discussions API and brings in comments from Discussions that it automatically creates on your site’s repository.
At the time I issued that post, I had no expectation of migrating the site to a different repo. Still, even after I did, I figured, Ah, no problem, I’ll just transfer the Discussions from the previous repo to the new one, and everything will work again.
Well, I was half-right.
Yes, if you transfer the Discussions to the new repo, the website will still have the same comments as when it was on the old repo (presuming, of course, that you have properly configured the new repo to use giscus). The problem came in the transfer process. I tried for days and couldn’t get it to work. Every time I attempted it, GitHub gave me an error message saying that what I was attempting wasn’t possible “at this time.”
Finally, yesterday, giscus maintainer Sage Abdullah figured it out. Within a few minutes, I was able to get those Discussions transferred across and, with them, their comments restored to the appropriate pages in the site.1
I then posted word of this to a few Discords where I thought it might be useful; and, for the same reason, I will reproduce some of that post here:
If you use the giscus service . . . for commenting on your website, its reliance on GitHub Discussions means that comments are tied to the repo where your website’s code exists. If you change the site to a different repo, the Discussions must be transferred to that repo; otherwise, they won’t appear in the new repo’s giscus-equipped website. However, as of now, that’s not possible unless you change each Discussion’s category away from the giscus-recommended category of “Announcements.” Then you can transfer each Discussion to the new repo, and change it back to an “Announcements” Discussion — and all your comments magically come back in the new place.
However, I’d missed the most sensible solution of all: give the GitHub Discussions their own separate repo and point giscus to it from, well, whichever repo may be hosting this site at whatever time. (Thanks to the Astro team’s Sarah Rainsberger for the idea!) So, now, the comments live in a comments repo, where they should be eternally safe from my fickleness.
Later update: Turned out that, while the previous comments and reactions were indeed back on the site, it wasn’t possible for anyone to enter new ones — until (and, again, I have Sarah Rainsberger to thank for giving me the word that things were amiss) I went back into the giscus website and obtained a new set of variables for the comments repo. Now it all works again. So that’s one more thing you have to do in such a case.
Update, 2022-10-25: After several months of trying giscus, I decided to remove it, as explained in “Letting go of giscus.”
Netlify Edge Functions
On April 19, Netlify announced it had become the latest of the Jamstack-savvy hosts to provide edge-computing functions in the form of Netlify Edge Functions, which currently are in beta. Unlike how Netlify’s competitors have done it, this entry in the Edge Race uses Deno — at least theoretically providing better performance and more successful interactivity with various web development frameworks, although that obviously will remain to be seen.
That same day, Eleventy creator/maintainer Zach Leatherman — who Netlify now has working on Eleventy on a full-time basis — announced Eleventy Edge, a plugin that teams Eleventy 2.0.0-canary.7 or higher and Netlify Edge Functions “to add dynamic content to . . . Eleventy templates.”
Feed readers and built-in browsers
While this section isn’t really about web dev, I bring it up here because, during my recent (but now-reversed) site migration to Astro, I spent a lot of time tinkering with my RSS and JSON feeds2. That occasioned my testing the new repository’s feeds on the RSS reader apps I use, one of which is the subject here.
One thing I do almost every day is keep at least one feed-reader app open but minimized while I’m coding or writing, and then check it periodically to see what’s been added to the many feeds I follow. I have two feed-reader apps, sync’d via iCloud and running on both macOS and iOS: News Explorer (paid) and NetNewsWire (FOSS). Until a few days ago, I typically used News Explorer for this task, primarily because it has a built-in web browser and NetNewsWire doesn’t.
One day, I became curious about NetNewsWire’s lack of this seemingly obvious feature, so I did a search. Soon, I’d changed my mind after reading a 2019 blog post by NetNewsWire’s creator, Brent Simmons, about this very topic. Of the many good points he raised, the one that quickly altered my thinking about this question was:
[With a built-in browser,] your ad blockers and privacy extensions won’t run. . . . That means that viewing a web page in NetNewsWire would be less secure and more annoying than viewing the same page in [a secured browser].
(I’d already realized how janky web pages look in News Explorer, what with so many pop-up ads and garbage that my various browsers all hide; but I hadn’t sufficiently considered the security angle.)
And to the argument that long-ago versions of the app did have built-in browsing, he correctly replied:
. . . times have changed. Many websites are hostile these days. In 2005, this feature was fine — but these days it’s totally not.
NetNewsWire has since added a built-in reader option, using the open-source Mercury parser. In the same 2019 post, Simmons already anticipated this development, noting that it would provide only an item’s content “without all the extra junk that is not the article you want to read.”
So, for now, I’m with NetNewsWire and I suggest the same for you if you’re in the Apple ecosphere. NetNewsWire has always been a great RSS reader app, it’s actively and lovingly maintained, and it protects your privacy better than many of its seemingly more capable competitors. (Also: you can’t beat the price.)
There aren’t many, I know, but I still wanted them to appear. Several folks had taken the time to interact, and thus I figured that restoring the questions or thoughts they’d left for me was the least I could do. ↩︎
Those feeds still constitute a work in progress, while I wait to see whether the Astro team will make certain feature changes when Astro’s currently ultra-tight development schedule permits. ↩︎
Latest commit (08cb79e2) for page file:
2023-04-17 at 6:18:22 PM CDT.
Page history