Cloning a site from the main site of a multisite gave me a duplicate key error and a half-built subsite. The cause was a blanket REPLACE on option names that collided with rows WordPress had already created, so I swapped it for an anchored, re-runnable rename. That fix let the code reach a serialized-object branch nobody had run in years, where a loop variable clobbered the column name, and then PHP 8 refused to write NUL-prefixed private properties. Three patches in twenty minutes. The takeaway: fixing an early crash turns everything behind it from unreachable into untested, so go looking for the next bug on purpose.

I wanted each hotel in an itinerary linked to its own website. A page check that asked whether the page mentioned the hotel passed a directory listing on someone else’s subdomain, which then outranked the real site. Booking-engine pages and chain sites with the name split across the path caused more trouble in turn. The fix was to judge the domain rather than the page: prefer a site whose own domain carries the name, accept only the top result otherwise, and give no link at all before a wrong one. A small diagnostic command that explains each choice found most of it.

An itinerary came back with a hotel on the day the traveller flew home. The model had researched hotels well, but it couldn’t count nights. Travel days landed in the wrong stay, and the departure day got a room. I first patched the symptom, then asked why I was taking a day-by-day list from the model at all. Which night belongs to which hotel is arithmetic: group the stays, give each recommended hotel its first N days, leave the rest empty. Now code builds that list and falls back to the model’s if the trip doesn’t line up. Use the model for judgement, and loops for counting.

A build split into parallel model calls is only as fast as its slowest call, and now and then one just goes quiet for minutes. A shorter timeout would have shot healthy web-searching calls too. So I borrowed hedged requests: after 100 seconds, start an identical second call beside the first, take whichever answers first, cancel the other. The awkward bits were waking a streaming HTTP loop when nothing arrives, and making sure a fast failure never displaces the original. Builds that took seven minutes on a bad day now take about three. If you can’t make the slow one faster, stop being loyal to it.

I built a 48-hour grace period before a removed domain’s certificate gets deleted, and it had three holes. A targeted cleanup rewrote the pending-removal file from one domain and wiped everyone else’s clock. Re-enabling a domain didn’t clear its old timestamp, so a second removal looked already expired and deleted at once. And browsers had been told by HSTS to insist on HTTPS for a year, so visitors would hit an unclickable error once the cert went. Each fix was small, and the lesson is about state files rewritten wholesale: any command that sees a subset has to say what it does with the rest.

Two small sites went down while Apache was still running. The log said the scoreboard was full but not at MaxRequestWorkers, which sounds like a contradiction. After rolling the fleet to PHP-FPM with the event MPM, I’d set ServerLimit to exactly MaxRequestWorkers divided by ThreadsPerChild, so one row on the small boxes. A child that’s exiting keeps its row until its connections drain, so the replacement had nowhere to go. Fifty-two of fifty-eight boxes logged it. The fix was spare rows, a much higher recycle limit, and a full restart rather than a reload, because ServerLimit is only read on restart. Check yours against the arithmetic.

My certificate wrapper kept flagging live domains for removal, a different one or two every run, even though they were plainly in the config. The cause: under set -o pipefail, echo piped into grep -q gets SIGPIPE when grep exits on the first match, so the pipeline returns 141 and the if takes the not-found branch. It’s a race, so it only bites on bigger lists. Left alone, it would eventually have deleted a live certificate. Swapping six pipes for here-strings fixed it. Check what’s feeding your grep -q.

Long itineraries started dying with a 30-second max_execution_time fatal inside PhpSpreadsheet’s Font.php. The model wasn’t involved this time. Every style change makes PhpSpreadsheet scan the whole style collection for a match, recomputing an md5 hash for every style as it goes, so a heavily formatted workbook gets quadratic. I wrote a Spreadsheet subclass with a hash-to-style index, re-verified hits against the current hash, made misses harmless, and only used it when the plugin’s own vendored copy of the library is the one loaded. Same bytes out, 20 to 28 times faster. The timeout’s line number was a profiler with a sample size of one, and it pointed straight at the problem.

A Let’s Encrypt certificate expired on one of my WordPress boxes and nothing told me first. Three causes were stacked up, and every box in the fleet had all of them. The installer had run under sudo, so cron couldn’t write its own log and bailed before reaching the renew step. Lego’s account key was root-owned too, so a manual renew failed with an unhelpful message. And an Apache fix I’d rolled out in September only patched the generated vhosts, not the generator on each box, so the next renewal put the bug back. Fixed all three and added a renew-on-the-spot step. If something regenerates a file, patching the file only buys time.

I shipped version 4.0.0 of an old tour-packages plugin at half past ten and 4.0.5 just after twelve. Every fix pulled away whatever had been hiding the next problem. A function_exists() guard that only protects you from code that loads after you. A null going into WP_Post on PHP 8. A rewrite flush on every request that had been quietly covering for a broken activation hook. Draft packages visible to anyone with the URL. And last, a search page whose fatal error was the only thing keeping a reflected XSS and a shortcode injection out of sight. When a page has been dead for a long time, read all of it before you make it work again.