Category: Uncategorized

  • No internet!

    The Heavy Box on the Ethernet Cord: A Reminder to Check the Physical Layer

    Not every “the internet is down” problem lives in the software. Here’s one of my favorite support calls from my school tech days — symptom, cause, fix, and a lesson I still reach for.

    Symptom

    A teacher called: no internet on her workstation. I walked her through the usual first move — restart the machine — and we both expected that to be the end of it. It wasn’t. She called back a little later: still nothing. Same workstation, same dead connection, no improvement. So the easy explanation was off the table, and it was time to go look in person.

    Root Cause

    When I got to the room, the answer was sitting right there in plain sight: a heavy box, set down during an earlier workstation move, was resting squarely on top of the long Ethernet cable. The cord was being crushed hard enough to kill the connection. Nothing was wrong with the computer, the settings, or the network — the problem was physical, and it had walked into the room with the furniture.

    Fix

    It was a little challenging to move the box off the cable, but once I did, the connection returned immediately. There was no need for any setup or commands — just lifting the weight off the wire. We then discussed improved methods to secure and protect the cable so that a misplaced box wouldn’t disconnect her again.

    (Note: last paragraph simplified with WordPress AI!)

    Why It Matters

    It’s easy, especially as you get more technical, to assume every problem is a software or network issue and to skip right past the obvious. But a non-technical user was completely offline because of something no amount of remote troubleshooting would ever have found. The cause was in the room, not in the config — and only an in-person look caught it.

    Lesson

    Check the physical layer before you assume it’s software. Escalate methodically — the quick software fix first, then your own eyes on the actual hardware when that doesn’t work. Match the tool to the real cause, not the cause you expect. And one more thing this one taught me: keep your sense of humor. We both had a good laugh about it, the teacher felt helped rather than talked down to, and that matters as much as the fix.

  • Plato reset email bug

    A Password Reset That Led Nowhere: Debugging the Plato Email Link

    Few things are more frustrating than a “reset your password” link that doesn’t reset your password. Here’s how I tracked one down, fixed it with a one-line change, and got it shipped — symptom, cause, fix, and the lesson I’m keeping.

    Full issue and fix: https://github.com/1111philo/plato/issues/203 (resolved in PR #214)

    Symptom

    On the Plato learning platform, clicking the password-reset link in the email didn’t take you to a reset page — it dropped you right back on the login screen. As far as I could tell, there was simply no way to reset your password through email at all. I reproduced it on both macOS/Firefox and iPhone/Safari, so it wasn’t a one-off browser quirk. The link worked, technically — it just led nowhere useful.

    Root Cause

    It wasn’t a broken link; it was a link pointing at the wrong place. In src/lib/email.js, the reset URL was being built without the /reset-password route, so it resolved to the login page instead of the “Set new password” page. The email was doing exactly what the code told it to — the code just told it the wrong destination.

    Fix

    I asked Claude to help debug, and it flagged that the email was directing to the wrong route. From there I cloned the source onto my own server, found the culprit on line 67 of src/lib/email.js, and added the missing /reset-password route to resetUrl. AI sped up the hypothesis; I located and confirmed the actual fix myself. Reloaded, clicked the link, and the “Set new password” page finally appeared.

    Why It Matters

    A password reset is the one thing a locked-out user has to be able to do. If that path is broken, it’s not a cosmetic bug — people lose access to their accounts entirely, with no self-service way back in. It’s the kind of quiet failure that doesn’t crash anything but quietly blocks real users, which is exactly why it’s worth chasing down and documenting.

    Lesson

    Reproduce the bug in an isolated environment before you fix it. I stood up my own cloned copy, confirmed the broken behavior there, made the one-line change, and verified the reset page rendered correctly — so the fix was provably tied to the root cause, not a lucky guess. Then I filed a detailed, reproducible issue (steps, expected behavior, environment, screenshot), it was tagged ready-for-pilot, and the fix shipped as a verified commit in PR #214. The public issue-and-PR trail is the proof: anyone can audit the symptom, the cause, and the confirmation. Don’t assume it works — confirm it, and leave a trail.

  • Static Homepage

    Static Homepage, Missing Navigation: Why Your Blog Posts Disappear

    I published my first blog post, sat back, and then realized something a little funny: there was no way to actually get to it. What follows is the whole diagnosis — symptom, cause, fix, and what I’m taking from it.

    Symptom

    My brand-new WordPress.com site loaded a clean static homepage, exactly as designed — but a visitor landing there had no link, no button, nothing pointing them toward the post I’d just written. The content was live and completely invisible at the same time. My first instinct was that I’d done something wrong in publishing, but the post was fine. The page was fine. What was missing was the one thing I hadn’t thought about: a way in.

    Root Cause

    It turned out not to be a bug at all — it was a default. When you set a static page as your homepage on WordPress.com, the site stops showing your latest posts in the main spot, which is exactly what you asked it to do. But it doesn’t hand you a replacement path to those posts automatically. The clean homepage is the feature; the missing blog link is the side effect nobody warns you about. The posts were sitting in the blog archive the whole time — there just wasn’t a door leading to them.

    Fix

    The fix was small and lived in a place I hadn’t thought to check: the menus, tucked under a More… option in the editor. I created a menu item labeled “Blog,” pointed it at the blog archive, and assigned it to the site’s primary navigation. Saved, reloaded, and there it was — a link to my posts sitting right up top where a visitor would actually see it. One menu item turned an invisible blog into a visible one.

    Why It Matters

    The entire point of a portfolio or content site is that people can find the content. If you’re publishing case studies, write-ups, or anything you want read, a static homepage with no navigation quietly defeats the purpose — your best work is live and undiscoverable at the same time. That gap doesn’t announce itself. You only catch it if you look at your own site the way a stranger would.

    Lesson

    When you choose a static homepage, plan your navigation before you start publishing, not after. Static homepages are clean and professional, but they shift the responsibility for discoverability onto you. So map out where each section lives, add the menu items, and then — this is the part that actually saves you — visit your own site as a first-time guest and try to reach everything. If you can’t get there in a click or two, neither can your readers. Plan ahead, then test. It’s the same discipline as any good fix: don’t assume it works, confirm it.

    Fixed wpircles: