@Summitt Dweller’s Personal Blog - Eleventy

NOT Like a Rolling Stone

Mark McFate — Fri, 11 Oct 2024 20:09:55 +0000

Where has the last year gone? While life (metaphorically the stream in the hero image) rolls on, this blog (any of the moss covered rocks in the image) has not.

This blog was born of good intentions, but frankly it’s too hard for an old fart like me to remember how to maintain it and make contributions. Having not posted here in many months, I had to consult my “documentation”, and ultimately my retired password manager, to get back in and post this. That’s unacceptable, and it won’t happen again.

So, I’m going to replace this Ghost-driven “semi-static” blog with something more familiar and less costly/complex to operate. Probably a Hugo static site that is truly “static”, but not stagnant! There will be no more blog-moss grown here!

Famous last words?

See you on the flip-side. Soon.

Fixing Wieting Guild Pages

Mark McFate — Sat, 03 Jun 2023 23:20:26 +0000

Just the other day I got an updated copy of the Wieting Theatre’s volunteer roster and assignment schedule. As I’m trying to post them to the theatre’s management website (it’s password protected) I keep having issues with npm and dependencies that won’t compile. The fix, thus far has included a local command stream like this:

cd wieting-guild-pages
git pull
code .
npm run build
npm run start 
  --> failed
npm update
npm audit fix
npm run build
npm run start
  --> failed
npm audit fix --force
npm run build
  --> failed
npm install axios
npm run build
  --> failed
npm update
npm run build

The last errors had this in common:

[11ty] Unhandled rejection in promise: (more in DEBUG output)
[11ty] connect ETIMEDOUT 54.243.162.8:443 (via Error)
[11ty] 
[11ty] Original error stack trace: Error: connect ETIMEDOUT 54.243.162.8:443
[11ty]     at AxiosError.from (/Users/mark/GitHub/wieting-guild-pages/node_modules/axios/dist/node/axios.cjs:836:14)

One explanation I found:

The ETIMEDOUT error is thrown by the Node.js runtime when a connection or HTTP request is not closed properly after some time. You might encounter this error from time to time if you configured a timeout on your outgoing HTTP requests. The general solution to this issue is to catch the error and repeat the request, preferably using an exponential backoff strategy so that a waiting period is added between subsequent retries until the request eventually succeeds, or the maximum amount of retries is reached. If you encounter this error frequently, try to investigate your request timeout settings and choose a more appropriate value for the endpoint if possible.

I also found a GitHub issues/bug report related to Axios and this error at https://github.com/SillyTavern/SillyTavern/issues/432. So, maybe it’s not just me?

Searching for a Search Solution

Mark McFate — Thu, 20 Apr 2023 17:02:00 +0000

A few months ago I sat in on a CFE.dev webinar and I was really impressed with what I saw. I made a note to come back and look closer at Pagefind, and my new blog – this blog that you’re presumably reading right now – really needed a search feature, so the “Search” box on this page (I hope it’s there) is the outcome.

Glad I Found Pagefind

So, I started looking closely at search options and considered things like Lunr, which I’ve used before, and Solr, which I both love and hate (because of its JAVA roots). Pagefind was, of course, also on that short list and it quickly solidified its position at the top of the list when I found Adding search to an Eleventy site by Mike.

Mike doesn’t explain the setup in detail, but this comment really resonated with me so I decided to follow the same path:

Weirdly, I’ve found that I seem to read the posts on this site more than I write them. I say read, but I just mean referring to the stuff I’ve written because it has left my head.

Mike does provide a link to the reference he used, namely Using PageFind with Eleventy for Search by Robb Knight. I found Robb’s guidance and experience to be VERY helpful. Thank you, Robb!

Implementing Robb’s Approach

I won’t bother duplicating what Robb explains quite well, but this wasn’t a 10-minute solution for me, probably because I’m really still learning Javascript and Eleventy, and also because I’m using a Ghost back-end with packages managed via Yarn rather than npm.

So, in the few sections that follow I’ll try to briefly described what’s different about my approach versus Robb’s, along with what didn’t, and what ultimately did work.

`yarn`, Not `npm`

The first significant difference I encountered was the requirement that this blog project uses yarn, not npm for package management. Eventually I found that I just needed to replace Robb’s npm install pagefind command with a yarn add pagefind equivalent. I don’t really understand the details of that difference, but it worked.

eleventy.after Never Fires?

The biggest hurdle for me was trying to get this bit of Robb’s code to work.

const { execSync } = require('child_process')

module.exports = function(eleventyConfig) {
  eleventyConfig.on('eleventy.after', () => {
    execSync(`npx pagefind --source _site --glob \"**/*.html\"`, { encoding: 'utf-8' })
  })
}

In my case the --source parameter needed to be dist since this blog is generated into a directory by that name, and my configuration object is simply config rather than eleventyConfig. I made those simple changes and added my snippet to the .eleventy.js file, but found that it never triggered. I even replaced the execSync function call with a simple console.log statement and still got nothing. And still to this day, I have no idea why that didn’t work.

That snippet of code is supposed to be responsible for indexing all of the .html files after Eleventy has generated them. Well, I found out that everything else was working properly, but the _pagefind bundle generated by that indexing operation was just “missing”, since the index never was created. That made me wonder what would happen if I “forced” the system to index my content in a different manner…and that wonder ultimately worked.

Using `npx pagefind...` to Index Content

Having studied some of the Pagefind documentation I wondered what adding some post-processing to my build workflow might do, something like npx pagefind --source dist? That ultimately worked, but not in that original form.

I found that when I ran yarn start to locally rebuild the site, there was no generated ./dist/_pagefind bundle present, so I got no “Search” user interface elements, but there was an empty <div> where that belonged. So, with my localhost instance still running I opened a new terminal and ran npx pagefind --source dist in the project directory. Voila! The ./dist/_pagefind bundle magically appeared and the “Search” control was instantly visible in my localhost window! It was working, and it was beautiful.

Added a `pagefind` Script… Didn’t Work

Ok, with the above breakthrough in-hand I made this addition to the scripts: key in my package.json file:

  "pagefind": "npx pagefind --source dist"

Then I added the following to the end of my steps: key in .github/workflows/build-and-deploy.yml:

  - run: yarn pagefind

This worked to some extent, but wasn’t reliable and absolutely didn’t work when deployed to my DigitalOcean app. The inner-workings of yarn and build caching in these environments is still a DEEP mystery to me!

Extending My `encrypt` Script

What does work, both locally and on DigitalOcean, is essentially an “extension” of my old encrypt script. My old build workflow included these two elements of package.json and build-and-deploy.yml:

    "encrypt": "staticrypt ./dist/rebuild.html '***hidden***' --short -o ./dist/rebuild.html -f ./src/auth/login.html -t 'Summitt Dweller Blog - Rebuild' -i 'Please enter the passphrase.<br/>Hint: gh0st' --label-error 'Sorry, Ella says no. Try again.'"

…and…

  - run: yarn encrypt

I took note of the relative path spec for ./dist/rebuild.html in the encrypt command, reasoned that I should run pagefind in a similar fashion – but just before encryption – and came up with this change in package.json:

    "encrypt": "npx pagefind --source ./dist && staticrypt ./dist/rebuild.html '***hidden***' --short -o ./dist/rebuild.html -f ./src/auth/login.html -t 'Summitt Dweller Blog - Rebuild' -i 'Please enter the passphrase.<br/>Hint: gh0st' --label-error 'Sorry, Ella says no. Try again.'"

It works!

When I’m running locally my build-and-deploy.yml doesn’t apply so in that case I typically will do this IF I want my search index (and encryption) updated:

yarn start
yarn encrypt

When I rebuild in production on DigitalOcean my build-and-deploy.yml configuration IS run so including npx pagefind... as part of the yarn encrypt step does the trick.

Time to Test…

I’m going to save this post now and rebuild this blog on DigitalOcean, where with any luck, a search for a term like “DEEP” should return this post, and maybe one or two others. Drum roll please… Huzzah!

Man, Do I Feel Stupid

Previously I mentioned that my additon of a package.json script named pagefind didn’t work, and that my DigitalOcean builds kept trying to do yarn encrypt after yarn build. Well, turns out that’s because build-and-deploy.yml, where I had inserted the yarn pagefind step IS NOT in control of building my DigitalOcean app. In fact, it’s a .github workflow so I’m really not sure what role that file plays, if any?

I went looking in my DigitalOcean app configuration settings for yarn encrypt and found it, in the app’s “App Settings” subsection titled “App Spec”. When I view that “App Spec” I see this:

alerts:
- rule: DEPLOYMENT_FAILED
- rule: DOMAIN_FAILED
domains:
- domain: blog.summittdweller.com
  type: PRIMARY
  zone: summittdweller.com
envs:
- key: TZ
  scope: RUN_AND_BUILD_TIME
  value: America/Chicago
name: blog-summittdweller-11ty-ghost
region: nyc
static_sites:
- build_command: |-
    yarn build
    yarn encrypt
  environment_slug: node-js
  github:
    branch: main
    deploy_on_push: true
    repo: SummittDweller/blog-eleventy-ghost
  name: blog-eleventy-ghost
  output_dir: dist
  routes:
  - path: /
  source_dir: /

Note the two build_command: elements. Let’s change those two steps to three, like so:

- build_command: |-
    yarn build
    yarn pagefind
    yarn encrypt

Note that I captured the “App Spec” in a file named blog-summittdweller-11ty-ghost.yaml and I’ve saved that file in the project directory (where I hope it will do no harm). Attention: After making the aforementioned addition I almost forgot to upload this file back to DigitalOcean to replace our existing App Spec! Don’t be stupid like me!

Next, I needed a corresponding change in package.json, specifically these two lines (like I had them before, duh):

  "pagefind": "npx pagefind --source ./dist",
  "encrypt": "staticrypt ./dist/rebuild.html '***hidden***' --short -o ./dist/rebuild.html -f ./src/auth/login.html -t 'Summitt Dweller Blog - Rebuild' -i 'Please enter the passphrase.<br/>Hint: gh0st' --label-error 'Sorry, Ella says no. Try again.'"

Push to Rebuild

Ok, having modified and UPLOADEDblog-summittdweller-11ty-ghost.yaml, and having modified package.json, it came time to commit and push all my changes to see what happens. Another drum roll, please…

Gating My Content

Mark McFate — Mon, 30 Jan 2023 14:45:01 -0600

Gating Content in JAMstack Sites

This section’s title was borrowed from a Stackbit article with the same title, Gating Content in JAMstack Sites. Working through that article to password protect some of the content at https://Wieting.TamaToledo.com is my tech pursit today.

Nope, Not on Netlify

😦 Last evening I took a shot at implementing the Netlify Identity tricks from the aforementioned article, but could not easily get it to work. The problem, I think, is that the https://Wieting.TamaToledo.com on Netlify already uses Netlify Identity for authentication of my Netlify CMS forms, and adding a second, separate instance of that service isn’t trivial and perhaps isn’t even feasible. I also tried implementing some quick Staticrypt CLI protection but that also failed. Netlify does provide a really quick and painless solution, but it costs $20/month, at a minimum, to enable it.

New Staticrypt Strategy?

So, my next shot at this will involve creating a new Eleventy site just for the Wieting’s protected content. Wish me luck and follow along here if you like.

Trying Azure DevOps

I recently created a personal Azure account, registered to summitt.dweller@gmail.com, and last evening (January 31, 2023) I took a dive into Azure DevOps under that account. The “welcome” email that I received says I now have an “organization” URL at https://dev.azure.com/summittdweller.

I jumped into Azure DevOps because it looks like within that environment I can establish a Content Management System (CMS) not unlike the NetlifyCMS (or perhaps it IS NCMS) that I run for the Wieting Theatre, hosted with Netlify.com. I really like NetlifyCMS, but thus far I’ve had limited success with it, and ONLY at Netlify.com where the user authentication process is nicely streamlined. I hope that Azure DevOps has user authentication that’s just as easy to manage, and at less cost.

So, I guess the strategy now is to see what Azure DevOps has to offer, rather than venturing further with Staticrypt.

That’s a TEMPORAY wrap, this post isn’t finished just yet.