Published by

SUCCESSFUL Adventures in setting up ActivityPub + Webfinger on a Flywheel-hosted WordPress site

Updated 31 October 2023 at 2:45pm to edit the NGINX config and give a further explanation.

I gave up too soon!

Emerson from Flywheel did more digging in the Fastly cache documentation and realized that we could tweak the NGINX config to fully support content negotiation. He added a Vary header to the necessary URLs et voilà, everything started working properly. Now, courtesy of Matthias Pfefferle’s great WordPress plugins and Flywheel’s dogged help, you can follow this blog on Mastodon if you search for @blog@piperhaywood.com or https://piperhaywood.com/@blog.

For future reference, this is the NGINX config tweak that got ActivityPub and Webfinger working on Flywheel with their Fastly caching setup:

location ~* /.well-known/webfinger {
    default_type application/activity+json;
    add_header Vary Accept;
    include internal-proxy.conf;
}

location ~* / {
    add_header Vary Accept;
    include internal-proxy.conf;
}

It’s fairly self-explanatory, but essentially the first location block ensures that all Webfinger endpoints have a default content type of application/activity+json, adds a Vary HTTP header so that Flywheel’s caching via Fastly will cache different versions of the page depending upon the content type, and includes further configuration via an internal-proxy.conf file. The second location block ensures that all URLs across the site basically do all of the above, but no default content type is set. (TBH I feel like I might only need the second block… but at this point everything is working nicely so I’m not going to ask the kind souls at Flywheel to change the config yet again!)

Colin from Flywheel explained the internal-proxy.conf file to me in my far-too-long support ticket:

The internal-proxy.conf is indeed an internal file that has platform-specific rules. Some of this config file is just simple cache rules, excluding common paths, whereas other parts are potentially sensitive as they pertain to our load balancing and proxy configs.

So that’s it! You can follow this blog now on Mastodon, and all blog posts published after October 30th should show up.

Published by

Adventures in setting up ActivityPub + Webfinger on a Flywheel-hosted WordPress site

Update: We got it working! Take a look at this post for more.

I recently moved my hosting from NFSN to Flywheel. NFSN had served me beautifully for years, very economically, but I just don’t have as much time for admin anymore and Flywheel’s managed WordPress hosting was a useful move to cut down on that stress.

Alongside the hosting move, I’ve been trying to set up the very talented Matthias Pfefferle’s ActivityPub and Webfinger WordPress plugins to get this site on Mastodon.

Unfortunately, Flywheel doesn’t seem to play super nicely with the plugins. Part of this is Flywheel’s NGINX configuration which they lock down tight with good reason. But the bigger sticking point is Flywheel’s full-page caching mechanism. Though their caching provider supports content negotiation, Flywheel itself does not. This causes issues where JSON can end up being cached instead of HTML on various pages, most notably the homepage. (Apologies if you saw a JSON blob when visiting this site recently!) We tried to get around this by forcing the content type on the homepage and Webfinger endpoints, but JSON was still served up on the homepage whenever a client sent through a header with Accept: application/activity+json.

For now, I’ve deactivated the plugins. I’m hoping that Flywheel might look in to supporting them more broadly, but that realistically depends on demand from their customers. For posterity since I hope to revisit this in the future 🤞, here is the discussion about all of the above within the Webfinger repo, including some tips from Matthias.

Flywheel’s support staff have been pretty fantastic through all of this and I’ve been really happy with the hosting thus far so I’m not tempted to move hosts (again) for this. Not yet at least!

Published by

General maintenance tips for website owners

This was originally written as a bit of a guide for my clients and collaborators, an aggregation of similar tips I have given to many of them individually in the past in so many shorter emails and conversations. Since it is relevant to most website owners though regardless of their relationship with me, I decided to share it more broadly here.

Websites require maintenance, even those with the smallest of footprints.

This is what I would consider “bare minimum” website-related maintenance tasks including checking your payment methods and contact details, reviewing your login and security practices, performing updates and taking backups, and checking your privacy policy.

If you do fall behind on maintenance (it happens to the best of us!) and something goes wrong, at the very bottom you’ll find some tips on what to do if your site goes down suddenly.

The vast majority of these tasks do not require a web developer or IT person, almost anyone can perform this maintenance so long as you have access to necessary logins, can follow instructions, and are willing to set aside the time.

I say “almost anyone” because some people are understandably uncomfortable with wading in to this stuff, they may get confused or a bit daunted by the user interfaces they have to use. In that case, just be sure that you are working with someone that can hold your hand through it or can simply do it for you. Also, not everyone has access to all of their service providers. If you’re in a different situation, for example if you retain a web developer, design studio, or IT person to continuously maintain your website, then these are worthy topics to discuss with them but ultimately they will probably need to complete these tasks for you.

Of course there are other maintenance tasks that are super worthwhile. For example it might be worth checking search performance or 404 pages with Google Search Console if search engine optimization (SEO) is important to you, or to check analytics if that’s relevant to your site. And it’s worth speaking to your web developer about front-end maintenance. CSS and JavaScript gets better all the time, as do browsers, so old front-end behavior can really date a site.

But that’s all just the cherry on top. If you complete the tasks below I’d say you’re pretty golden, probably a step ahead of 80% of the site owners I’ve come across.

Read more

Published by

Moving your email from one host to another

I recently helped an artist friend move an email address associated with her domain name from one host to another. These are the steps we took.

TL;DR — Moving email from one host to another is a pain. If you have to take it on yourself, take each step carefully and when in doubt, get in touch with your email hosting provider for advice.

⚠️ I wrote up these instructions as a self-help guide for my friend and decided to publish them here since I figured a lot of people might be in a similar boat. Turns out I was right, I get a lot of emails about moving email! However, if you want someone to manage an email move for you or provide one-on-one support for email, unfortunately I don’t offer this as a service. I’m not the right fit, my specialty is building websites, not managing email. If you don’t want to take it on yourself (which is fair!), you must get in touch with an IT person or systems administrator, not a web developer. If you’re not sure where to find one, ask around for recommendations or have a quick search online for local IT outfits that might fit the bill.

Read full instructions

Published by

Some excellent, specific podcast episodes

I often don’t end up listening to podcasts that are recommended to me. It’s a real shame. I think it’s sometimes hard to know where to start, to find a way in. The next time I get a recommendation, I’ll ask if there’s a specific episode I should try.

Along those lines, here’s a list of a few particular episodes I like. These are in date order, most recent first. Might add more at some point.

Risky Business #535, 20.03.19 — Stop giving Cloudflare money

Edit 28 August 2019 – Cloudflare finally dropped 8chan earlier this month following the El Paso Walmart shooting. From the Wired article: “‘When you have platforms that are effectively lawless like this, then maybe that shifts the responsibility further down the stack,’ [Cloudflare CEO Matthew] Prince says. Looking at [white supremacist site] Daily Stormer and now 8chan, Prince says that Cloudflare is attempting to find the line where ‘a site has shown repeatedly that it is causing active, real harm.’”

I’m very interested in information security but definitely an amateur, so most Risky Business episodes go a bit (or entirely) over my head. This episode with host Patrick Gray (AU) and guest Alex Stamos (US) is accessible for less infosec-aware people though. It’s heavy, but very worthy of a listen for anyone influenced by the internet (i.e. everyone).

The major topic is the Christchurch, NZ shootings on the Al Noor Mosque and Linwood Islamic Centre where 50 people were killed and 50 more injured by a white supremacist. They focus on the web’s role in the rise of white supremacist communities and propaganda, and what could be done about it. Cloudflare is highlighted as a particularly irresponsible and unsupportable service provider due to the company’s response following the attack. They have refused to pull their services from 8chan, a website that facilitates the spread of white supremacist ideology and the site where the attacker announced his intentions.

Stamos tries to present the difficulties that companies and law enforcement face. Gray understandably gets pretty heated during the discussion, I think initially interpreting Stamos’s comments as an excuse for the inaction of companies like Cloudflare (though I don’t think they were). Ultimately though they seemed to be in agreement. Towards the end of their discussion, around 40:51, Stamos summarises: “We’re going to have to start to treat white nationalists like the Islamic State was treated. To the point that if you’re on 8chan and you’re talking about an attack, you’re actually feeling that there’s some kind of risk, that somebody’s gonna bust your door down. That’s where we got to with the Islamic State. […] We’ve got to get to that same place, but [Cloudflare and other organisations] can make that hard for non-US law enforcement.” He is saying that white nationalist groups need to be classified as potential terrorist organisations so that there is a legal framework forcing companies to adopt stronger policies instead of just hoping they’ll do the right thing. It’s a very good point.

– – –

BBC Earth Podcast 27.12.18 — Hide and Seek

I’ve never finished an episode of BBC Earth… but that’s why I like it. It’s the perfect podcast to fall asleep to if you’re having trouble drifting off. Interesting – but not *too* riveting – facts and stories about nature told by presenter/producer Emily Knight and guests. And great jungle sounds. I’ve put this particular episode on here because I really liked the wildlife calls while they were explaining how to track tigers. Can’t really say much about what happened after that though, I was asleep.

– – –

Darknet Diaries #27, 01.12.18 — Chartbreakers

The tagline for Darknet Diaries is “True stories from the dark side of the Internet”. This episode is a little different, investigating something ongoing rather than covering something that has already occurred. Host Jack Rhysider tries to figure out why shady podcasts with zero reviews or subscribers regularly climb the Top Charts on Apple Podcasts. In doing so, he finds out that it involves dubious promotional activity, and it isn’t just the little guys doing it. He also finds out this isn’t a web-only problem, that a similar thing has happened multiple times with the New York Times Bestsellers list and could still be happening. It’s yet another wakeup call that we should be suspicious of algorithms, particularly those that are meant to be infallibly meritocratic. Rhysider ends the episode by saying that he hopes his listeners recommend the podcast to their friends since he puts no faith in likes or reviews. It made me think about how much I like receiving recommendations from people I care about, and kind of became the catalyst for this list.

– – –

Roderick on the Line #300, 13.08.18 — The Airplane Doesn’t Care

One of Merlin Mann and John Roderick’s weekly Skype calls. Their conversations go all over the place, this one is no different. They always touch a bit on philosophy and mental health, but it’s more prominent in this episode due to a then-recent event. On Saturday 11.08.18, 29-year-old Richard Russell stole an empty turboprop from SeaTac airport, performed difficult stunts with basically no training, and then committed suicide by deliberately crashing in to a small island in Puget Sound (more here). One of those things that made me laugh and cry.

– – –

Syntax #29, 24.01.18 — Hosting & Servers

Wes Bos and Scott Tolinski dive in to hosting. It’s a great primer on a lot of the options out there at the moment, even if you consider yourself relatively familiar with these things. It’s all about the way they walk through it, from Squarespace to Docker, including personal experiences, pitfalls, and use cases.

– – –

Ear Hustle #2, 28.06.17 — Misguided Loyalty

Ear Hustle, stories of life inside prison, is presented by visual artist Nigel Poor and former San Quentin inmate Earlonne Woods. I had no idea which Ear Hustle episode to choose, every one is a jewel. This early episode is about gangs; the pressure, the violence, and the repercussions.

– – –

Adam Buxton Podcast #37 and #38, 06.04.17 — Brian Eno

Adam Buxton having a chat in two parts with Brian Eno. Not much more to say.

Published by

My experience getting up and running with Homebase

I finally got round to exploring Homebase yesterday (jump straight to setup steps). My original intention was to get the SB-PH site on Dat + HTTPS à la this blog post by Tara Vancil. As far as I can tell though, without multi-writer support in Dat this setup would effectively lock Sam out of being able to quickly deploy changes. We’re interested in making that site a little bit more of a collaborative sandbox, so making deployment harder than it is currently is not the right step to take there.

So though I definitely want to get the SB-PH site on Dat eventually, we’re putting that on hold for now and I’m pivoting towards my site. In this blog’s earliest incarnation it was on Tumblr, and for a long while now has been a pretty standard WordPress site. The big task in moving to Dat, besides figuring out Homebase, is converting my site from WordPress to a static site via Jekyll/Hugo/Eleventy/GatsbyJS or something similar. It’s taking a while, I didn’t realise quite how much content has accumulated (1000+ tags?!) and there are a few WordPress-y features that I definitely want to build in (“more” tags, descriptions for tags+categories, proper pagination, etc.). More on that in a separate note.

So yesterday I put that aside and focused on getting Homebase up and running on a DigitalOcean droplet. Overall, setting up Homebase wasn’t too bad. The most involved part of the process was setting up the server. I kind of like tinkering with server stuff, so that’s cool. I 100% agree with the caveat at the top of the Homebase README, you should consider Homebase only if you’re comfortable with and interested in server administration. I would add that your interest should be *ongoing*. Servers take maintenance (related, see note on serverless setups). It’s your responsibility if a process stops running, or the software is out of date, or the Let’s Encrypt certificate doesn’t renew, etc. Hashbase looks like a great alternative for those that want the final result but don’t want to deal with the server configuration/maintenance.

The rest of this note is an outline of the steps I took to get Homebase working. Where good documentation exists elsewhere, I have linked to that instead of elaborating.

Read Homebase setup steps