allyson  

tldr: https://www.allysonmellbergtaylor.com/ runs on Kirby now instead of Squarespace


Seven and a half years ago, I helped an artist friend set up a Squarespace site back when those ran about $10/month and I've paid for it ever since. (In the credit card sense, not the suffering sense.) This month I noticed an email from Squarespace that the rate's going to nearly double that. That's not their fault, but it reminded me that the site we put up right away instead of spending a weekend together building something on Kirby is still more of a rental than a home.

Now, Kirby's a great system and I really enjoy using on small, free projects. Over the years, it's also ballooned from its origins as a PHP script that stitches flat text files into web pages into something more complicated to set up. It requires Composer to build, and probably node. It’s also got a Vue control panel for editing the flat files that runs afoul of security scans (that spot PHP editing text files) and needs hand-written YAML configuration that's honestly awful to write.

But this year I've had relatively good success getting Claude Code to write that YAML, set up some basic ddev + Vite local hosting, and figure out the state of rsync deploys and GitHub actions for this site, so while I'm not mad I gave Squarespace so much money over the years — they did what they promised — it’s time to cut bait and finally make Allyson an actual website.

Allyson's site has always been simple: a landing cover page (retired), galleries of images, index pages of those galleries, and a contact page that just links out to Instagram. Squarespace offers more, but it wasn't being used. Self-hosting also means the administration falls to me, which is no small part of what their service offers.

I couldn't find any kind of export from Squarespace (hmm) so I used Integrity Plusto scrape the site. (It’s quicker for me than trying to remember wget commands, but Claude Code probably could have done the wget)

From that archive, Claude Code figured out the URLs for the original resolution assets, made the flat-file Kirby content tree, defined the Kirby content model, and reverse engineered a similar front-end build.

I figured it’s worth a post about the phases of the process, not as a "hey you can clone your Squarespace and save money" but because the intent of signing up for the Squarespace in the first place was to get something up immediately and then work on the "real" site — in this case that took years to get to and a sea change in how to do the work.

It’s not vibe coded or one-shotted; the chat approach helped me write plans and chip away over a week or two in very small pockets of free time. Setting up tasks I understand, coming back to find Claude had failed spectacularly, then setting it on a better path. Could I have written the plan? Done the steps? Absolutely. Would I have put it off until the week before Squarespace wanted $200 more? Very likely.

The content model took some back-and-forth and it went down a lot of stupid rabbitholes and mistakes. It organized the site by the navigation, misunderstood the concept of galleries, dropped titles, etc. It wasted as much time as it saved, but I was also able to set it off to a task in very small bits of my time, chastise it for mistakes when I came back to see what it had done, repeat. It made an absolute mess in the final steps of htaccess, inventing whole areas of Dreamhost or Cloudflare's admin panel I should be looking for even when I gave it the two exact support URLs as reference.

But it’s up and it’s done and it runs locally on my little Mac Mini. I can screenshare over to that machine and run the updates. I can pull content changes from production and commit them to the private git repo, push them up to staging to sync. I skipped the GitHub Actions deploy on this one, but I'll add it to the half-dozen or so Kirby sites I've set up the same way(s) this year with Claude's help and make its maintenance part of my regular routines.

I tried intentionally not to wholesale copy the work of Squarespace's theme designers. Menu's on the left on larger screens and the index is masonry and there's a hamburger button. But I improved the accessibilty, replaced the interactions with Alpine, swapped out the fonts. I'll do another pass later to really tighten the whitespace and professionalize it more, but that's something I'd rather do with Allyson, hopefully sooner than seven years from now.

Anyway, here's the phases and the bin scripts (build, deploy, deploy-staging, push/pull-content, push/pull-accounts, pull-all, warm-cache): https://gist.github.com/maxfenton/cef7843392459a3ee9a5d67cead689c4

janet  

FENTON--Janet. Janet Rose Fenton passed away peacefully at her home in Manhattan on June 16, 2020, at the age of 94. Born in 1926, she was the only daughter of Arnold and Edna Munk. Under the pen name Watty Piper, Janet's father wrote, edited, and published scores of children's books including The Little Engine That Could. Janet attended PS 9 in New York and graduated from Fieldston in 1944. After one year at Syracuse University, she married Robert Fenton in 1946, and they were devoted to each other for 58 years until his death. A longtime member of Congregation Rodeph Sholom, the NY Society Library, numerous theaters, museums, and weekly bridge games, Janet was elegant and kind. She will be deeply missed by family, friends, and the countless New Yorkers she met in her long life on the island that was her only home. She is survived by her loving daughters Paula and Joan Fenton, her grandson Max Fenton and his wife Nicole, her great-granddaughter Eva, her step-grandson Ephraim Tabackman and family, and step-granddaughter Noa Summerfield and family. The family will sit shiva over video on June 18 and June 19. In lieu of flowers, please consider donating to your local food bank.

Published by New York Times on Jun. 18, 2020.

silicon mac mini with external drive for user folder  

(Sorry for the claudefeels in this — I was working through the actual process with Claude and Claude Code and tried to get the facts back out of that chat history into this story post and it blurred until I couldn't tell what was mine and what wasn't. Weird state of things, but this sat in drafts for three months instead of doing what I meant to do which was spare some folks the hassle of figuring out how to set up and external user drive on a Silicon Mac Mini)


TLDR: I finally upgraded my 2TB+256GB i7 Mac Mini file server to an M4 Mac Mini 256GB with an external 2TB SSD for the user directory and had some frustrating file permissions problems to figure out. Specific steps are at the end.


After a catastrophic RAID failure four years ago, I looked at my options and set a $500 budget for a file server that could serve two main purposes: local file sharing access to my replacement RAID and local and cloud backups of that RAID as well as all my cloud services files on iCloud, Dropbox, etc.

The current model of Mac Mini was both too expensive and un-repairable, but the two-core 2014 Mac mini was easy to open and expandable using a standard 2.5 inch SATA drive. I got a clean refurbished i7 Mini from Pacific Macs and a 2TB SATA SSD. It turned out I also needed a logic board removal tool and an 821-1501-A cable to run two internal drives in a Mini that shipped with only one, but those didn't count against the budget. It all worked out in the end and the i7 has been running 24/7 for approximately 1337 days.

Basically it worked like this: the Mac Mini was always on and always online. The RAID connects over Thunderbolt 2 and backs up with SuperDuper to an 8TB Seagate drive. Separately, another USB drive works as the Time Machine destination and the Mini syncs everything ("keep offline", don't "optimize storage", etc) — everything comes to the Mini in a normal MacOS way and gets backed up in a normal MacOS way. That's the convenience tax for not trying to run this through some other kind of home-rolled server.

So anyway, I got excited when Apple put out the M4 Mini with expandable storage but of course they did it in the worst Apple way, with firmware and form factor lock-in. Popular blog posts pointed to a few grey market vendors and a complex process that requires a second Mac — something I have, but it was enough friction to stop me from trying. For my purposes, the base price of $699 +$300 in storage was out of my budget. A year or two later, the jackpot prices of that storage have doubled, all the Minis have been bought by LLM farmers, and Tim Apple killed off the low cost base model... while I was driving to the store to pick up the very last M4 256/16. (More on that in a moment.)

In the meantime, if it ain't broke don't fix it. But the i7 was broken in a deep way and that was the OS. Without a more modern version of MacOS than the i7 could run, iCloud does not allow file encryption. That meant my terabyte of iCloud storage wasn't deeply encrypted on Apple's side and security patches were harder to come by. Not great for an always-on machine with my most important files.

In comes OpenCore Legacy Patcher. Hobbyist software to get modern MacOS running on older hardware and keep those perfectly functional computers out of the landfill. With OpenCore Legacy Patcher I was able to get the i7 Mini updated to Sequoia and install subsequent patches which have become more frequent of late.

And that was doing fine for a few months, but the last few security patches really did drag down the perceived speed. I started to worry it was an OCLP issue and/or the inevitable thermal paste decay on the i7.

But what I didn't realize was that I could situate my /user folder on an external drive. Now, external drives that were $89 last year are over $300 now, so "wait until it dies and buy an M4/2TB" was still my main option — but there was also a real risk of M4 Mac Minis going away in favor of a low-end Mac Neo in the $500–$1000 range, and higher prices across the board on an M5 Mini. And then I remembered I already bought an $89 Crucial X8 2TB last year to use as a more rugged laptop Time Machine.

So wiping that 2TB and connecting it with a TB3 cable to a low-end Mini seemed like it would work for me. A $500 machine + a thing that was already on my desk. I also already had the $49 Thunderbolt 2 to Thunderbolt 3 dongle to be able to connect the RAID to my laptop. So after far too many conversations with friends, I finally got in the car on May 1 to go to the store and get the last M4 16/256 they had in stock. When I got there they also had an $899 24/512, and I tell you I thought a long time about that upgrade — but again it was beyond the budget for the use I had, and after two years waiting to buy an M4 it wasn't perfect enough to justify nearly twice the price.

A week later I finally sat down to set it all up. It was awful.

My settings kept resetting. Everything moved slow as rocks. Total disaster, I thought. There are special permissions that were obvious in hindsight but really hard to search for or track down.

I'd made an admin user on the internal storage. That user had wiped the external drive and created my main user and set up the home directory on the external drive. One admin macOS user can't just sudo another user's files, so both the drive and the home directory were owned by the wrong user and the permissions were all out of whack.

The steps to set up a user on an external SSD on an Apple Silicon Mac:

External Home Folder Setup on macOS 26 Tahoe

Problem

macOS 26 does not correctly set ownership when a user home folder is placed on an external drive. Symptoms look like OS bugs: settings revert on logout, Finder crashes on login, widgets reset, preference files fail to write. The root cause is a permissions problem.

Requirements

  • External drive formatted as APFS
  • Admin account separate from the user being created

Steps

  1. Format external drive as APFS via Disk Utility

  2. Create the home folder directory on the external drive manually in Finder or Terminal:

     mkdir /Volumes/DriveName/username
  3. Create the user in System Settings > Users & Groups

  4. Change home directory — right-click the user, select Advanced Options, set Home Directory to:

     /Volumes/DriveName/username
  5. Log out of admin, log in as the new user once to initialize the home folder structure, then log back into admin

  6. Enable ownership on the volume — this is disabled by default on external APFS volumes and must be done before any permission changes will work:

     sudo diskutil enableOwnership /Volumes/DriveName
  7. Set correct ownership on the home folder:

     sudo chown -R username /Volumes/DriveName/username

    Note: some system-protected directories under ~/Library will return "Operation not permitted" — this is expected and harmless

  8. Verify ownership:

     ls -la /Volumes/DriveName/

    The home folder must show owned by username, not admin

  9. Full restart required — logout/login alone is not sufficient to stabilize the session

  10. Log in as the new user and verify settings persist