A renovation week with three lessons I’d have charged a client to find. The podcast went live, and the launch turned into a long chase through five different feed validators. A Largest Contentful Paint (LCP) of 4.8 seconds on my own homepage finally got the diagnosis I’d been quietly avoiding, and a plugin I wrote shipped an early-Saturday emergency release after production caught an edge case my own install hadn’t. Three things worth writing down because they map directly onto problems I see on other people’s installs.
The podcast launched, and the launch-day fixes were the actual work
Sites I’ve Never Seen is now a real podcast in the world. Five episodes published Thursday and Friday: The Contract You Forgot You Made, The 40 Page PDF Nobody Reads, Enterprise WordPress, Headless WordPress, and 15 WordCamp Talks. Each episode is anchored to the blog post it grew out of, with a branded PDF download that captures the show notes in a format you can keep on your desk. The website end of this had been ready for weeks. The launch-day end of it was where the work actually was.
I built a thisismyurl_podcast custom post type (CPT) to hold the episodes properly, with each episode subjectOf-linked back to its source post in schema. That part was clean. The launch-day fixes were not. A literal em-dash inside the JSON-LD broke a couple of feed parsers because the character wasn’t escaped the way the spec wants it. The same character had to be sanitized to its entity form inside the RSS XML for the same reason. Apple Podcasts wanted an itunes:image at the channel level that my feed wasn’t emitting until a small must-use plugin bootstrapped it on the right hook. The Open Graph image resolver was returning the site default instead of the episode cover. The feed was emitting itunes:episode and itunes:season tags that the show type doesn’t allow for episodic shows, which Apple’s validator flagged in a way that took longer to read than to fix.
The thing worth writing down is that podcast distribution is a chain of validators, and every link in that chain has its own opinion about what a feed should look like. Building the CPT and the schema in the abstract is the easy part. Watching the feed render in five different validators and patching what each one objects to is the actual launch.
Four agents diagnosed my own mobile speed problem
The Largest Contentful Paint (LCP) on my homepage was clocking 4.8 seconds on mobile. That’s the kind of number I’d flag in a client audit and quietly hope they hadn’t already seen, because it sits well past the Core Web Vitals threshold and it’s the first thing a procurement buyer pastes into PageSpeed Insights before they even open your portfolio. Mine was 4.8 seconds. Fixing it took the byte-accountant agent, the mobile agent, the SEO agent, and the WordPress-expert agent working in concert, and the diagnosis was more interesting than the fix.
The byte accountant flagged LearnDash assets loading on the homepage even though there’s no LearnDash content there — a conditional-enqueue bug where the plugin was registering its full stylesheet stack on every page rather than only on pages that actually used it. The mobile agent flagged a CSS animation called heroRise that was triggering layout work during the critical render path, on a viewport where the hero is the first thing the visitor sees, which is the worst place for a layout shift to happen. The SEO agent caught a preload hint that was retargeted at an old image path that no longer existed, so the browser was eagerly fetching a 404. And the WordPress-expert ran the actual fix: kill the unconditional LearnDash enqueue, drop the heroRise animation on mobile widths, retarget the preload to the right image, and match the font weight of the Sora display face so the swap doesn’t cause a second paint when the web font lands.
What I want a reader to take from this: when your own homepage is slow, don’t fix it with a guess. Orchestrate the specialists who own each layer of the stack and let them tell you which layer the cost is hiding in. The patch took fifteen minutes once the four agents had agreed on the where; the rest of the time went into the diagnosis. That’s the shape of every senior-developer engagement I do for a client, and watching it play out on my own site was a useful reminder of why the diagnostic step is the thing they’re actually paying for.
Saturday morning, the Monday post came due
On Monday I published What you owe the people still running your old code, which makes the case that a plugin in the WordPress.org directory under your name is a standing commitment, not a portfolio entry you can stop maintaining. The same commitment holds for a plugin you’ve shipped on GitHub, which is where most of mine actually live. On Saturday morning — five days ago, as I write this — that commitment came due. A production site running thisismyurl-image-support, a GitHub-distributed plugin of mine, tripped a bug in the file-rotation logic that I’d shipped weeks earlier and hadn’t caught because my own install hadn’t hit the edge case yet. The site that found it for me wasn’t mine.
The WordPress-expert subagent did the actual diagnosis. The bug was small once you saw it: the rotation was being called with a stale handle that should have been refreshed after the file was renamed. The symptom, though, was a quiet failure that left orphaned files in the upload directory rather than a loud crash, which is the worst kind of bug to inherit from your past self. thisismyurl-image-support 0.6136 shipped Saturday morning, before the site owner had woken up: committed, pushed to origin, GitHub release cut, and copied straight onto the affected production site. The kind of week where you’re glad the plugin author lives in the same house as the person who can ship the fix.
Monday’s essay turned, by Saturday, into something I’d had to live: if your name is on the plugin, you owe the people running it a working answer when something breaks. A patch, in their environment, on the day the bug bit them, not a triage queue or a forum post promising to look at it next sprint. The post said the standing commitment lasts as long as the code is still installable. Saturday morning was the test of whether I meant it.
Also this week
- A pre-publish gate now sits in front of every scheduled post on this site. Five baseline checks plus four byline-blog checks; anything that fails reverts the post from scheduled back to pending until I clear the failure or override it with a documented reason of at least forty characters. The override exists because there are days when the right call is to ship anyway, and the audit log captures both the override and the reason for the next round of calibration.
- The cover-3000 cache job had been leaking storage for weeks. Two runaway PHP processes were still running from earlier this month — 10.5 hours of combined CPU time between them — and 76,546 orphan files were sitting in the temp directory eating 3.1 GB. Killed the processes, cleaned the files, and hardened the producer with a collision brake, file rollback on failed writes, and a failed-state directive that should keep the next runaway from getting this far. Nineteen dead temp must-use plugins tombstoned while I was in there.
- The photographer pipeline now runs vision-check on every generated image, maintains an orphan inventory that gets searched before any new generation call, and refuses to fire for any post more than ten days from its publish date. The waste budget on image generation was getting out of hand, and the ten-day window plus the orphan-first search closes most of it.
- Friday’s post was What a $275/hr WordPress consultant costs you over three years, which lays out the actual math on senior-consultant rate versus the all-in cost of a $75k in-house junior over a three-year window. It’s the post procurement buyers have been quietly asking for, and the numbers aren’t the ones the question usually expects.
The through-line this week is one I keep coming back to: the site is the portfolio, and the practice I build on my own install is the practice that walks into the next paid engagement. The Saturday patch is the one that landed hardest — a Monday essay turning into a working proof inside a week is how you find out whether you meant what you wrote. I’d rather find that out on my own install than on a client’s.
Last reviewed May 18, 2026.
Rate and review this content
Be the first to rate this. Submissions are reviewed before they appear.