DEV Community: Vicente G. Reyes

The CI/CD Pipeline That Was Lying to Us: A Deploy Debugging Story

Vicente G. Reyes — Tue, 01 Sep 2026 13:10:03 +0000

I had a GitHub Actions workflow called Deploy to DigitalOcean. It had been sitting in the repo for weeks, fully wired up — SSH action, secrets references, the works. And yet every single time I shipped a backend change, I still had to SSH into the droplet and run git pull by hand.

I hadn't stopped to ask why until I actually went looking. It turned out the pipeline wasn't broken in any one obvious way — it was broken in six small, unrelated ways, stacked on top of each other, each one hiding the next. This is the story of digging through all of them, in the order I actually found them.

Act 1: The Deploy Job That Never Ran

The setup looked correct on paper. deploy.yml was gated like this:

on:
  workflow_run:
    workflows: ['CI']
    branches: ['main']
    types: [completed]

jobs:
  deploy:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}

Reasonable: only deploy if CI passed. So the first thing worth checking wasn't the deploy job at all — it was whether CI had ever passed on main.

gh run list --workflow=ci.yml --limit 5

Every single row: failure. Every deploy run: skipped. The deploy pipeline wasn't broken — it was doing exactly what it was told, gating correctly on a CI workflow that had never once gone green on main. I hadn't connected those dots because the failures and the missing deploys lived in two different tabs of the Actions UI.

Act 2: Two Bugs Wearing One Trenchcoat

gh run view <run-id> showed two jobs failing for completely unrelated reasons.

The linter job died immediately:

The specified python version file at: .python-version doesn't exist.

.python-version was sitting right there in the repo root. Except it wasn't — it was in .gitignore, left over from a pyenv boilerplate line nobody had questioned. actions/setup-python's python-version-file input needs the file to actually exist in the checkout, and a gitignored file never reaches CI no matter how real it looks on disk locally.

The frontend job died differently:

Error: [vitest-pool]: Failed to start forks worker for test files ...
Caused by: TypeError: webidl.util.markAsUncloneable is not a function

That error has nothing to do with my test code. ci.yml pinned node-version: '20', but jsdom@30 (a Vitest dependency) requires:

"engines": { "node": "^22.22.2 || ^24.15.0 || >=26.0.0" }

Node 20 doesn't have markAsUncloneable — jsdom needs it. Every frontend test run was crashing before a single test file even executed. The actual backend test suite (pytest) had been passing this entire time; it was just outvoted by two infrastructure bugs with nothing to do with the code being tested.

Fix: un-ignore .python-version, commit it. Bump node-version to '22'. Two-line diff, two root causes eliminated.

Act 3: The Debt That Was Always There

Pushed the fix, watched CI run again. pytest and frontend went green. linter failed again — different reason this time:

black....................................................................Failed
- hook id: black
reformatted job_board/jobs/services.py

isort....................................................................Failed
- hook id: isort
Fixing job_board/jobs/services.py

djLint formatting for Django.............................................Failed
- hook id: djlint-reformat-django
1 file was updated.

Formatting drift had been quietly accumulating in three files — a multi-line import that black wanted split, a .envs file missing a trailing newline, an index.html <meta> tag that djLint wanted wrapped. None of it mattered locally because nobody had pre-commit wired into their git hooks. It only mattered in CI, which is exactly where it had been failing, unnoticed, this whole time.

The fix here was almost mechanical: CI's own hook output is the diff. Applied it verbatim rather than re-deriving it — no ambiguity about what "correctly formatted" means when the formatter already told you.

Act 4: The Flaky Cache and the Duplicate Runs

Two more small papercuts surfaced once real CI runs were flowing:

A cache backend race. PR-triggered builds started intermittently failing with:

Error: cannot parse bake definitions: ERROR: failed to solve:
failed to load cache key: repository does not contain ref refs/pull/166/merge

This is a known docker/bake-action + GitHub Actions cache quirk: a PR's merge ref gets recomputed (or invalidated) if the PR updates or merges while the cache backend is still resolving it. It never affected the push-triggered run on main — the one that actually gates deploy — but it left a false red X on every promotion PR. Buildx's GHA cache backend has a purpose-built escape hatch for exactly this:

django.cache-from=type=gha,scope=django-cached-tests,ignore-error=true

ignore-error=true degrades a cache-restore failure to a cache miss instead of failing the whole job.

Duplicate CI runs. With both pull_request: branches: [main] and push: branches: [main] as triggers, every promotion ran the exact same commit through CI twice — once when the PR opened, again the instant it merged. Since deploy only ever cares about the post-merge state of main, the fix was to drop the pull_request trigger entirely and let push do the only job that mattered.

While in there, I also pulled the frontend lint/test job out of backend CI altogether — the frontend deploys through Vercel, which already runs its own build/lint pipeline as a separate PR check. There was no reason a frontend typo should ever gate a DigitalOcean backend deploy, so frontend/** also got added to paths-ignore — a frontend-only commit no longer triggers a backend rebuild at all.

Act 5: CI Was Finally Green. Deploy Still Failed.

For the first time, CI showed success on a push to main. And for the first time, Deploy to DigitalOcean actually ran instead of showing skipped. It failed in 12 seconds:

ssh.ParsePrivateKey: ssh: no key found
ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain

gh secret list --repo <org>/<repo>

Zero rows. DO_HOST, DO_USERNAME, DO_SSH_KEY, DO_PORT — none of them existed. The workflow had been referencing four secrets that had simply never been created. CI passing had done its job; it just exposed the next layer down.

Act 6: Two SSH Gotchas

Setting these up surfaced two mistakes worth writing down because they're both easy to make and easy to misdiagnose.

Gotcha 1 — ssh-copy-id from inside the box. Trying to install a public key onto the droplet while already SSH'd into that droplet doesn't work: ssh-copy-id opens a new outbound connection back to the same host to install the key, but that connection has no valid key to authenticate with yet. Classic chicken-and-egg. Once you're already sitting in a shell on the target machine, skip ssh-copy-id and just append directly:

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Gotcha 2 — mangled secret content. Even after the public key was trusted server-side, the deploy still failed with the exact same ssh: no key found error. The private key had been set as a GitHub secret via a string interpolation (--body "...") rather than a direct file redirect, which had silently collapsed the multi-line PEM block. The fix is to never let anything touch the formatting:

gh secret set DO_SSH_KEY --repo <org>/<repo> < ~/.ssh/id_ed25519

Redirecting the raw file guarantees byte-for-byte fidelity, including the -----BEGIN/END----- lines and every internal newline that a shell string would otherwise eat.

Act 7: Right Key, Wrong Directory

With auth finally working, the deploy script actually reached the droplet and ran — into a new error:

err: bash: line 1: cd: /home/***/apps/gigglegigs: No such file or directory
err: fatal: not a git repository (or any of the parent directories): .git
err: open /home/***/production.yml: no such file or directory

deploy.yml assumed the checkout lived at ~/apps/gigglegigs. It didn't — a quick ls ~ on the droplet showed the actual clone sitting at ~/GiggleGigs. That path had apparently been copy-pasted from a different project's deploy config and never actually validated, because the workflow had never gotten far enough to hit it before. One-line fix, and the deploy script finally ran start to finish: build, collectstatic, migrate, up -d, all green.

Act 8: The First Real Deploy Broke the Site

Two minutes after that first fully green deploy, the admin's user list started returning 502 Bad Gateway. The instinct is to panic here — first automated deploy, and the site's down? But the logs told a much less dramatic story:

django-1  | PostgreSQL is available
django-1  | 186 static files copied to '/app/staticfiles', 538 post-processed.
django-1  | [2026-09-01 12:48:17 +0000] [1] [INFO] Starting gunicorn 21.2.0
django-1  | [2026-09-01 12:48:17 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000

Gunicorn didn't finish booting — Postgres wait, collectstatic, worker fork — until 12:48:17. The 502 was timestamped 12:48:16. One second earlier. Nothing crashed; I'd just refreshed the admin during the exact window where docker compose up -d had already killed the old django container and the new one wasn't listening yet.

That's not really a bug in the app — it's a gap in the deploy setup. Traefik here uses the static file provider, routing unconditionally to http://django:5000 with zero awareness of container readiness:

services:
  django:
    loadBalancer:
      servers:
        - url: http://django:5000

Every deploy, without exception, would keep hitting this same window. The right fix is an active health check so Traefik stops sending traffic to a container until it's actually answering:

services:
  django:
    loadBalancer:
      servers:
        - url: http://django:5000
      healthCheck:
        path: /healthz/
        hostname: api.example.com
        interval: '5s'
        timeout: '3s'

Two things worth calling out about that config. First, /healthz/ didn't exist — it needed to be a genuinely trivial, unauthenticated view (no DB touch, no auth, just 200 OK), because coupling infra health to a real business endpoint means a permissions change or a slow query silently takes your health check down with it. Second, hostname isn't optional: without it, Traefik's health check request sends Host: django (the internal service name), and ALLOWED_HOSTS — quite correctly — rejects that as a DisallowedHost, returning 400 and making Traefik think the container is permanently unhealthy. Setting hostname to the real public domain makes the health check's request indistinguishable from real traffic, from Django's point of view.

While already in production.yml, I added restart: unless-stopped to every long-running service (everything except the one-off backup container). Without it, a droplet reboot — a DigitalOcean maintenance window, a crash, anything — leaves every container down until someone notices and SSHes in to bring them back up manually. unless-stopped means Docker brings them back on its own the moment the daemon starts.

What Actually Was Wrong, All Together

Laid out in one place, the full list is almost funny:

A gitignored file broke Python setup in CI
A pinned Node version was two majors behind what a dependency required
Formatting drift had been silently failing lint for who knows how long
A GHA cache backend race gave false negatives on PR checks
CI ran twice per promotion for no reason
Zero deploy secrets existed
A private key got mangled by shell interpolation
The deploy script's target directory was simply wrong
Traefik had no way to know when a container wasn't ready yet
Nothing would restart itself after a reboot

No single one of these was hard to fix once found. What made this a slog was that each bug hid the next one — CI had to go green before deploy secrets could even matter; deploy secrets had to work before the wrong directory path could surface; the deploy had to actually succeed before the Traefik timing gap became visible at all. A pipeline with ten small breakages in series doesn't look like ten breakages. It looks like one big wall, and the only way through it is to fix the outermost failure, rerun, and see what the next layer reveals.

Takeaway

If your "automated" deploy still requires someone to manually pull and rebuild, don't assume the deploy job itself is broken — check whether the thing gating it has ever actually succeeded. A pipeline that's silently and permanently gated behind a red CI run looks, from a distance, exactly like a pipeline that doesn't exist. The fix isn't usually one big rewrite. It's peeling one failing layer at a time until the thing underneath finally gets a chance to run — and then trusting the next error message, however unrelated it looks, to point at the next real problem.

Side project deployed https://www.gigglegigs.com/ tomorrow is devops and SEO day!

Vicente G. Reyes — Mon, 31 Aug 2026 13:26:16 +0000

gigglegigs.com

What do you think is better, a free period or a freemium?

Vicente G. Reyes — Sun, 30 Aug 2026 05:47:21 +0000

Your App Center List Is Not a Security Audit

Vicente G. Reyes — Fri, 28 Aug 2026 05:10:02 +0000

I opened Ubuntu's App Center, scrolled through ~90 installed packages, and asked the obvious question: is any of this malware?

The list looked suspicious in all the wrong ways. A font package last updated nine years ago. A dozen unlabeled GStreamer plugins with generic gray icons. Something called BRLTTY I had no memory of installing. Plenty of surface area for paranoia.

None of it turned out to matter, and the reason is worth writing down: App Center is a package browser, not an inventory. It shows you the two sources it manages — the Ubuntu archive and the Snap Store — and nothing else. Every path an attacker would actually use to get code onto a developer workstation is invisible to it.

This is the audit I ran instead, and what each command is actually good for.

Reading the GUI correctly first

Two things I had wrong at a glance.

"Updated 9 years ago" is not neglect. That's the package version date. (URW)++ Core Font Set 20200910-8, TeXInfo, BRLTTY — these are frozen-by-design dependencies pulled in by other packages. A font metric file doesn't need a 2026 release to be safe.

Gray placeholder icons are not unsigned packages. They mean no AppStream metadata or .desktop file. Most are libraries that were never meant to appear in a launcher. A few, as I found later, are a real (and benign) finding.

Neither observation tells you anything about integrity. For that you need the actual tooling.

1. Snap publishers

snap list

for s in $(snap list | awk 'NR>1{print $1}'); do
  snap info "$s" | grep -E '^(name|publisher)'
done

The publisher column is the entire point. Snap uses two markers:

Marker	Meaning
`✓`	Verified publisher — identity confirmed by Canonical
`✪`	Starred — a trusted community maintainer

On my machine: 21 snaps, all marked. Canonical for the base and GNOME runtimes, mozilla✓ for Firefox, bitwarden✓ (8bit Solutions LLC), spotify✓. The three starred ones were Discord and ffmpeg-2404 from Snapcrafters, and Pinta from James Carroll — the legitimate upstream maintainers in both cases.

An unmarked publisher on a snap claiming to be a well-known app is the thing to look for. There weren't any.

2. Third-party APT repositories

This is the real risk vector, and it's the one App Center will never show you.

grep -rhE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Seven results, all using signed-by= with a dedicated keyring — which is the modern, correct form. The deprecated apt-key approach trusts a key for every repo on the system; signed-by scopes it to one. If you see repos without it, that's worth fixing regardless of whether anything is compromised.

Six were immediately recognizable: Docker, GitHub CLI, Heroku, Cloudflare WARP, mise, and the Ulauncher PPA. The seventh was truncated in my terminal and read, in part, antigravity-repo-key.gpg ... us-central1-apt.pkg.dev/projects/antigra....

Unfamiliar name, Google Cloud infrastructure hostname. Exactly the shape of thing that deserves thirty seconds of verification rather than a shrug.

It's Google's Antigravity IDE. Google's official Linux download page publishes that repo verbatim — same keyring path, same Artifact Registry host, same project. Confirmed, but confirming the URL is only half the check.

3. Verifying the signing key

A repo URL you recognize means nothing if the key trusting it was swapped.

gpg --show-keys --fingerprint /etc/apt/keyrings/antigravity-repo-key.gpg

pub   rsa2048 2021-05-04 [SC]
      35BA A0B3 3E9E B396 F59C  A838 C0BA 5CE6 DC63 15A3
uid   Artifact Registry Repository Signer <artifact-registry-repository-signer@google.com>

Full-length match against the published fingerprint, and a single pub key with no extra subkeys smuggled into the file. Compare all 40 characters — matching the last eight is a known-weak check that collision attacks have historically defeated.

One nuance that matters. This is Google's shared Artifact Registry signing key. It signs every public AR apt repo, not just Antigravity's. So the fingerprint proves "Google Artifact Registry published this" — it does not prove "the Antigravity team published this." The trust boundary is the repository path. Verify both halves or you've verified neither.

4. Binary integrity

This is the command that actually answers the malware question.

sudo apt install debsums
sudo debsums -s

debsums recomputes the checksum of every file installed from a .deb and compares it against what the package shipped. -s prints only problems. If something had patched a system binary, this is where it surfaces.

My output — three lines, all of the same kind:

debsums: missing file /usr/share/applications/btop.desktop (from btop package)
debsums: missing file /usr/share/applications/org.flameshot.Flameshot.desktop
debsums: missing file /usr/share/applications/org.gnome.SystemMonitor.desktop

Missing is not modified, and the distinction is the whole finding. Zero checksum mismatches means not one binary or library on the system differs from what Ubuntu published. What's missing is three launcher entries — which is also why those three showed gray placeholder icons back in the GUI. Almost certainly an app-grid cleanup I did and forgot. Malware adds .desktop files for persistence; it has no reason to delete them from unrelated packages.

sudo apt install --reinstall btop flameshot gnome-system-monitor

One caveat: not every package ships checksums, so debsums coverage is good but not total. Add sudo debsums -ca to list modified config files, which is a separate and noisier category.

5. Running services and persistence

systemctl list-units --type=service --state=running
ls -la ~/.config/autostart/ /etc/systemd/system/

Thirty-four running services, every one accounted for: Docker and containerd, warp-svc matching the Cloudflare repo, ClamAV daemon and freshclam, and the usual GNOME and systemd stack. Autostart held two entries, both mine.

The /etc/systemd/system/ listing had a detail I liked seeing:

avahi-daemon.service -> /dev/null
cups.service -> /dev/null
libvirtd.service -> /dev/null

Symlinking a unit to /dev/null is masking — a stronger form of disable that can't be overridden by another unit's dependencies. Past-me hardening the box and leaving a legible trace of it.

What this audit does not cover

Every check above is scoped to the package layer. That layer came back clean, and it's also not where compromise on a developer machine tends to originate.

The paths that stay invisible to all of it:

Language package managers — npm -g, pip, cargo install, go install. Typosquats and compromised maintainer accounts are a live and recurring problem here, and postinstall scripts run with your privileges.
curl | bash installers — no signature, no manifest, no uninstall path, nothing for debsums to compare against.
Editor and IDE extensions — VS Code marketplace extensions run with full user permissions and are minimally reviewed.
Agentic coding tools — anything with filesystem write access and an autonomous execution loop. This is the newest item on the list and the one with the least established review culture around it. That is the sensible next audit. The system package layer is the part with actual cryptographic guarantees behind it — signed repos, verified publishers, reproducible checksums. Everything above it is running on trust.

The runbook

# Snap publishers — every entry should be ✓ or ✪
snap list
for s in $(snap list | awk 'NR>1{print $1}'); do
  snap info "$s" | grep -E '^(name|publisher)'
done

# Third-party APT repos — all should use signed-by=
grep -rhE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

# Verify any unfamiliar repo key against its published fingerprint (all 40 chars)
gpg --show-keys --fingerprint /etc/apt/keyrings/<name>.gpg

# Binary integrity — the check that matters
sudo apt install debsums && sudo debsums -s

# Persistence and running services
systemctl list-units --type=service --state=running
ls -la ~/.config/autostart/ /etc/systemd/system/

Five minutes end to end. Worth running on any machine you build client work on, if only to replace a vague sense of unease with an actual answer.

Why I Couldn't Access My Own Site (But My Phone Could): A Cloudways Auto-Ban Story

Vicente G. Reyes — Mon, 24 Aug 2026 13:12:24 +0000

I sat down to work on Rev6 and couldn't load the site. Not a slow load, not an SSL warning — nothing. The browser just spun until it gave up. My first assumption was the usual suspect: the server was down.

Then I checked my phone, on the same Wi-Fi. Rev6 loaded instantly.

That one detail sent me down a much longer rabbit hole than I expected — and the actual cause had nothing to do with my laptop, my router, or even my ISP.

The Setup

Rev6 is hosted on Cloudways, which provisions on top of DigitalOcean. DNS resolved fine — the domain pointed to the correct droplet IP. So this wasn't a broken domain or expired DNS record. The problem was specifically about reaching that IP.

The Failed Attempts

I went through the usual network debugging checklist, and every single one came back clean:

Ping and curl to the server — both hung and eventually timed out on ports 80, 443, and even 22 (SSH). Not "connection refused," just total silence, as if the packets vanished.
General internet sanity check — Google, GitHub, Cloudflare all loaded instantly. So this wasn't a broken connection, just this one destination.
Local firewall (ufw/iptables/nftables) — checked the full ruleset, OUTPUT policy was ACCEPT, no rule matched the server's IP or any DigitalOcean range.
VPN or proxy — none active, no http_proxy/https_proxy env vars, no tunnel interfaces.
MAC-based router filtering — randomized my Wi-Fi adapter's MAC address entirely. Still blocked.
Hostname-based filtering — some routers key parental-control rules off the DHCP hostname instead of the MAC. Disabled hostname broadcasting, renewed the lease. Still blocked.
The router itself — logged into the ONT admin panel and checked every filtering section: IP Filter, MAC Filter, WLAN MAC Filter, Parental Control, Device Access Control. All disabled, all empty.

At this point every layer between my laptop and my ISP was confirmed clean. Whatever was blocking the connection wasn't local.

The Clue That Cracked It

The "works on my phone" comparison turned out to be misleading. When I checked my phone's actual public IP (via whatismyip.com), it came back as a completely different address in a different range than my laptop's real ISP-assigned IP — a sign that Brave's VPN feature was tunneling all my phone's traffic elsewhere. My phone was never a fair comparison; it simply wasn't taking the same path to the internet.

The real breakthrough came from testing the connection from a network entirely outside my ISP. From there, the request to the server didn't time out — it came back as an active refusal. That's a meaningfully different signal:

From my home connection: total silence — no response at all
From an outside network: an explicit "connection refused"

Silence usually means something in the path is dropping packets. An active refusal means the packets arrived, and something on the other end responded. That distinction pointed the investigation away from my network entirely and toward the server side.

The Real Issue: Cloudways Had Auto-Banned My IP

Cloudways includes a Bot Protection feature — AI-driven heuristics and CAPTCHA challenges meant to keep malicious bots off the server. It's a genuinely useful feature. It's also fully automated, which means it can ban a legitimate visitor without any human ever reviewing the decision.

Under Server → Security → Firewall, there's a blacklist table showing banned IPs, the country they're associated with, and the reason. Searching my own IP directly returned nothing — but filtering by country (Philippines) surfaced it immediately:

IP	Purpose	TTL	Country	Event
(my IP)	black	1 week from now	Philippines	Blacklisted for CAPTCHA failure

My own home IP had been silently banned for a full week after failing a CAPTCHA challenge — almost certainly an automated bot check I never even saw, triggered while browsing my own site.

The Fix

From the same Firewall screen:

Search for the banned IP (or filter by country if the exact IP search comes up empty)
Open the ⋮ actions menu on that row
Remove/delete the blacklist entry

Access was restored immediately — no server restart, no DNS changes, nothing else required.

Takeaway

When a site is unreachable but DNS resolves and the rest of the internet works fine, don't assume it's your network just because another device on the same Wi-Fi can get through — verify that device is actually taking the same path out to the internet first. A background VPN can make an "it works on my phone" comparison completely meaningless.

And when the destination is a managed host like Cloudways, remember that automated bot/security protections can ban you just as easily as an actual attacker. If everything on your end checks out clean, check the host's own security dashboard before assuming there's a deeper network problem — the block might already be sitting there in plain sight, just filed under "security."

The Bug That Threw No Errors: How a Repeat-Trial Guard Silently Killed Our Free Trial Funnel

Vicente G. Reyes — Fri, 14 Aug 2026 12:06:09 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The setup

I'm the lead developer on Rev6.fit, a fitness membership platform built on WordPress + WooCommerce Subscriptions + LearnDash. It runs 49 plugins, five membership families, and a stack of custom code snippets — the kind of production environment where every change has a blast radius.

Rev6's entire top-of-funnel is a 7-day free trial. Every consumer membership — All-Access, On-Demand, Vitality — leads with "$0 today, first charge in 7 days." If the trial disappears, new signups don't slow down. They stop.

And one day, it disappeared. For every prospect. Silently.

The symptom

Logged-out visitors — which is to say, every single potential new customer — landed on membership product pages and saw... a full-price subscription. No "with a 7-day free trial" label. No "$0 today." Just the sticker price.

Existing members saw everything correctly. The client saw everything correctly (logged in, obviously). The site threw zero errors. Sentry — which we run on both the PHP and JS sides — was green. PageSpeed was fine. Checkout worked.

The funnel was just quietly bleeding out.

The catch didn't come from a dashboard. It came from a human: Avie, my primary client contact, noticed the trial messaging was gone from the membership pages and flagged it. That detail matters to the story — with all our monitoring green, the alerting system that actually fired was someone who knows the site well enough to feel when something's off. Every production stack has one of those. They're underrated.

The root cause

Here's the part I love, because it's such a classic shape: the bug was inside a guard written for a different problem.

The site carried a custom snippet whose job was to enforce one free trial per customer — if you'd already consumed your trial, the trial offer was stripped from the subscription for you. Reasonable policy for any trial-led membership business.

The right logic is:

"Has this user already had a trial? If yes, remove the trial."

But the snippet carried an extra condition that effectively turned it into:

"Can I confirm this user deserves a trial? If not, remove the trial."

And for a logged-out visitor, there's no user to check. No account → no trial history → can't confirm eligibility → strip the trial. The guard failed closed against the exact people it should have failed open for: first-time visitors who haven't created an account yet.

A simplified reconstruction of the shape (the real snippet stays private, but this is the logic faithfully):

// The repeat-trial guard — intended behavior
add_filter( 'woocommerce_subscriptions_product_trial_length', function ( $trial_length, $product ) {
    $user_id = get_current_user_id();

    // ❌ The extra condition: guests have no $user_id,
    // so they fell into the "no trial" branch too
    if ( ! $user_id || rev6_user_has_used_trial( $user_id ) ) {
        return 0; // no trial for you
    }

    return $trial_length;
}, 10, 2 );

The subtle trap: on Rev6, guest checkout is disabled — accounts are auto-created at signup. So a guest seeing the trial offer is completely safe; by the time money and trial entitlement are involved, they have an account and the repeat-trial check can do its job. The guest branch in the guard wasn't just wrong — it was protecting against a scenario the platform's own architecture already made impossible.

The fix

The fix was almost anticlimactic — remove the guest condition, keep the repeat-trial protection:

if ( ! $user_id ) {
    return $trial_length; // ✅ guests see the trial — accounts are created at signup anyway
}

if ( rev6_user_has_used_trial( $user_id ) ) {
    return 0; // repeat-trial protection stays intact
}

return $trial_length;

One condition. That's the whole diff. But the verification checklist was the real work:

✅ Logged-out visitor sees "with a 7-day free trial" on every membership product
✅ Checkout shows $0 today / first charge in 7 days
✅ Account auto-creation at signup still works
✅ A user who already consumed a trial still gets no second trial
✅ Verified on staging first, then live The last item on that list matters most: it would have been very easy to "fix" this by deleting the guard entirely — and quietly reopen the repeat-trial loophole the snippet existed to close. Smashing a bug shouldn't resurrect its predecessor.

What Sentry taught me by not catching this

Rev6 runs Sentry on both PHP and JS, and it's caught real production issues for us — an orphaned marketing-automation job erroring every 60 seconds, broken script dependencies on product pages, a Stripe Express Checkout misconfiguration. It's earned its keep.

But this bug was invisible to it, and that's the lesson I'd hand any dev working on revenue-critical flows:

Error monitoring catches code that fails. It can't catch code that succeeds at doing the wrong thing.

The trial guard executed perfectly. No exception, no warning, no log line. It returned 0 exactly as written — the code was correct; the condition was wrong. That's a whole class of bug that lives below the monitoring waterline: pricing logic, discount eligibility, visibility rules, permission gates. The stuff that decides whether money moves.

My takeaways for that class of bug:

Test your money paths logged out. Your default browsing state as a developer (logged in, admin bar on, caches primed) is the state your prospects will never be in. Incognito is a QA tool.
Guards should fail open or closed deliberately. Every early-return in an eligibility check is a policy decision. Write the comment. "Guests: allow, because accounts are created at signup" would have made this bug impossible to write.
Behavioral monitoring complements error monitoring. An alert on "trial signups per day dropped to zero" would have caught this in hours — instead of waiting for a sharp-eyed human to happen across the page. ## The win

The trial is back, the repeat-trial abuse protection still holds, and every first-time visitor to Rev6 now sees the offer that the entire funnel was designed around. No new plugins, no rewrite — one condition removed, with a verification list long enough to trust the change on a live revenue path.

The bugs that throw exceptions are the easy ones. The legendary ones return 0 and walk away clean.

I'm Ice — freelance full-stack dev (Django/React + WordPress/WooCommerce + Shopify). More at vicentereyes.org.

The WebP Migration That Wasn't About WebP

Vicente G. Reyes — Fri, 31 Jul 2026 10:58:28 +0000

Nobody asked me to do this.

I maintain a WooCommerce store bolted to LearnDash courses on a Divi theme — eight years of content, a few thousand images. Page weight had been nagging at me for a while, so I put "convert the images to WebP" on my own list. No ticket, no client request, just a maintenance item I thought would take an afternoon.

I almost installed ShortPixel and called it a day.

Instead I spent twenty minutes auditing first, and found that WebP was maybe the fourth most important thing wrong with how that site served images. This is what the audit turned up, and why "just install an optimizer plugin" would have made things worse.

Always inventory before you optimize

The site runs on a 4GB VPS that had already OOM-killed MySQL twice that quarter. Bulk image transcoding is CPU and memory heavy. So before touching anything:

cd wp-content/uploads
du -sh .
echo "JPEG:  $(find . -type f \( -iname '*.jpg' -o -iname '*.jpeg' \) | wc -l)"
echo "PNG:   $(find . -type f -iname '*.png' | wc -l)"
echo "WebP:  $(find . -type f -iname '*.webp' | wc -l)"

The output stopped me cold:

2.1G    .
JPEG:  3245
PNG:   1443
WebP:  12301

Twelve thousand WebP files on a site that supposedly had no WebP.

Finding 1: 241MB of files nothing was serving

The naming told the story — image.jpg.webp, sidecar files in the same directory as the original. That's EWWW Image Optimizer's convention.

EWWW was not installed. Somebody had run it, then removed the plugin.

When EWWW generates sidecars, delivery depends on either an .htaccess rewrite doing Accept-header negotiation, or a <picture> element filter. Both live in the plugin. Remove the plugin and the files become inert — 241MB of dead weight, still being scanned by the server's malware scanner on every pass, still counted in every backup.

Verified they were genuinely unreferenced before deleting:

# no content references
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%.jpg.webp%';"
# no attachment metadata references
wp db query "SELECT COUNT(*) FROM wp_postmeta WHERE meta_value LIKE '%.jpg.webp%';"
# no rewrite rule anywhere
grep -in webp .htaccess ~/conf/*

Three zeros. Deleted, 241MB back.

Lesson: image optimizer plugins leave their output behind when uninstalled. If you inherit a site, grep the uploads directory for orphaned formats before you add another optimizer to the pile.

Finding 2: the size ladder had been demolished

This is the one that mattered.

wp eval 'print_r( get_intermediate_image_sizes() );'

Array
(
    [3] => large
    [16] => gform-image-choice-sm
    [17] => gform-image-choice-md
    [18] => gform-image-choice-lg
)

Four registered sizes. No thumbnail, no medium, no medium_large. And critically — no woocommerce_thumbnail, no woocommerce_gallery_thumbnail, none of Divi's.

Look at the array keys. They're non-sequential: 3, 16, 17, 18. The array originally held 0 through 18 and something had unset() entries without reindexing. That's a filter stripping sizes at runtime, not sizes that were never registered.

The culprit was a plugin called disable-thumbnails-and-threshold, hooking intermediate_image_sizes at priority 100, with eighteen sizes checked off in its settings. A previous dev had installed it to fight disk pressure. Understandable instinct, catastrophic execution.

Why this is worse than it sounds

WooCommerce still believed it had a 300×300 thumbnail size:

wp eval 'print_r( wc_get_image_size("woocommerce_thumbnail") );'
# => width 300, height 300, crop 1

The size was registered in WooCommerce's config, but the files were never generated. WooCommerce ships WC_Regenerate_Images, which hooks wp_get_attachment_image_src and resizes on the fly when a requested size is missing.

I counted actual coverage:

find wp-content/uploads -type f \( -iname '*-300x300.jpg' -o -iname '*-300x300.png' \) | wc -l
# => 141

141 files out of 2,216 attachments. Six percent coverage.

Meaning: for roughly 94% of product image requests, WooCommerce was doing an on-the-fly Imagick resize. On a box the host had already flagged for CPU saturation.

And the srcset consequence: with only large (1024px) registered, every responsive image had exactly one candidate. A phone loading a product grid pulled 1024px files into 300px slots. WebP shaves ~30% off a file. Serving the right dimensions shaves 90%.

The format was never the problem. The missing size ladder was.

Finding 3: the images weren't the disk hog

Adding up the raster formats: 705MB PNG + 242MB WebP + 192MB JPEG = 1,139MB. Total uploads: 2.1GB.

Where was the other gigabyte?

find . -type f -printf '%f\n' | awk -F. 'NF>1{print tolower($NF)}' | sort | uniq -c | sort -rn | head

122 PDFs, 12 MP4s, 2 Keynote files. Course manuals and lesson videos — two videos alone were 170MB, and one training manual existed in four copies across two editions for 185MB.

If I'd gone in with "let's reclaim disk by optimizing images," I'd have spent a day of CPU to reclaim less than the duplicate PDFs were wasting.

The fix: three filters, no new plugins

I considered ShortPixel and Imagify. Both are good. Both were wrong here:

They'd add ~17,000 API credits of cost for 2,216 attachments across 8 sizes
They write sidecar files and need a delivery mechanism — the exact pattern that left 241MB of orphans when EWWW was removed
They'd be plugin #50 on a site already carrying too many WordPress core has done this natively since 6.x. Three snippets, no dependencies.

1. Restore the size ladder

Rather than deactivating the disable-thumbnails plugin — which would swing from "no sizes" to "all nineteen sizes" and regenerate every unused Divi variant — I unchecked exactly five and left thirteen stripped:

$o = get_option( 'dtat_disablethumbnails_option_name', [] );
foreach ( [ 'thumbnail', 'medium', 'medium_large',
            'woocommerce_thumbnail', 'woocommerce_gallery_thumbnail' ] as $k ) {
    unset( $o[ $k ] );
}
update_option( 'dtat_disablethumbnails_option_name', $o );

Nine registered sizes instead of four or nineteen. The Divi et-pb-* sizes stay stripped — the theme's own bloat wasn't worth reintroducing.

2. WebP output for generated subsizes

add_filter( 'image_editor_output_format', function ( $formats, $filename, $mime_type ) {
    if ( in_array( $mime_type, [ 'image/jpeg', 'image/png' ], true ) ) {
        $formats[ $mime_type ] = 'image/webp';
    }
    return $formats;
}, 10, 3 );

add_filter( 'wp_editor_set_quality', function ( $quality, $mime_type ) {
    return ( 'image/webp' === $mime_type ) ? 82 : $quality;
}, 10, 2 );

The critical property here: WordPress preserves the source file as original_image in attachment metadata. Every future regeneration encodes from the lossless master, not from the WebP. Verify it before you commit to a bulk run:

wp eval '$m = wp_get_attachment_metadata( 123 ); var_dump( $m["original_image"] ?? "ABSENT" );'

If that returns ABSENT, stop. You'd be setting up cumulative quality loss — every regeneration re-encoding lossy from lossy, degrading invisibly over months until it's baked into everything.

3. Rewrite hardcoded URLs at render time

This is the gotcha that nearly shipped broken.

image_editor_output_format governs what WordPress generates. It does nothing about URLs already written into post_content. A Gutenberg wp-block-image figure has the path baked into the block markup. So does a Divi shortcode. Regeneration doesn't touch stored markup.

I measured the exposure:

SELECT post_type, COUNT(*) AS n
FROM wp_posts
WHERE post_status IN ('publish','draft','inherit')
  AND post_content REGEXP 'wp-content/uploads/[^"]+[.](png|jpe?g)'
GROUP BY post_type ORDER BY n DESC;

190 non-revision posts — including 25 Divi Library items and 3 Theme Builder layouts, which inject into many pages each. Left alone, most of the site's content images would have kept serving PNG while their WebP siblings sat unused on disk.

Fixed at render time rather than with a database search-replace:

add_filter( 'wp_content_img_tag', function ( $html, $context, $attachment_id ) {
    if ( false === strpos( $html, '/wp-content/uploads/' ) ) {
        return $html;
    }

    $dir = wp_get_upload_dir();

    // Original filename -> current primary file, for -scaled attachments.
    $orig_map = [];
    if ( $attachment_id ) {
        $meta = wp_get_attachment_metadata( $attachment_id );
        if ( ! empty( $meta['original_image'] ) && ! empty( $meta['file'] ) ) {
            $orig_map[ $meta['original_image'] ] = wp_basename( $meta['file'] );
        }
    }

    static $cache = [];

    return preg_replace_callback(
        '#(/wp-content/uploads/[^\s"\']+?)\.(png|jpe?g)#i',
        function ( $m ) use ( $dir, $orig_map, &$cache ) {
            $key = $m[0];
            if ( ! isset( $cache[ $key ] ) ) {
                $rel           = substr( $m[1], strlen( '/wp-content/uploads' ) );
                $cache[ $key ] = file_exists( $dir['basedir'] . $rel . '.webp' );
            }
            if ( $cache[ $key ] ) {
                return $m[1] . '.webp';
            }

            $base = wp_basename( $m[0] );
            if ( isset( $orig_map[ $base ] ) ) {
                return dirname( $m[1] ) . '/' . $orig_map[ $base ];
            }

            return $m[0];
        },
        $html
    );
}, 20, 3 );

The `-scaled` trap

My first version of that filter was ten lines shorter — just the extension swap and the
file_exists() guard. It tested clean and shipped, and then I found this in a Divi module:

<img src=".../DrEdythe_7.2024.png"
     srcset=".../DrEdythe_7.2024-scaled.webp 1831w,
             .../DrEdythe_7.2024-215x300.webp 215w, ...">

Every srcset candidate WebP. The src still a 9.9MB PNG — the largest file on the site.

WordPress scales any upload over big_image_size_threshold (2560px by default) and makes the
scaled copy the primary file, keeping the upload as original_image. With WebP output enabled
you get foo-scaled.webp as primary and foo.png as the preserved master. There is no
foo.webp. So the naive swap looks for a file that will never exist, finds nothing, and
leaves the PNG in place — silently, on exactly the biggest images you most wanted to fix.

The fix is to stop guessing filenames. wp_content_img_tag passes the attachment ID, so
metadata can tell you the real current filename. Just remember , 20, 3 on the add_filter
call — without the argument count the ID never arrives and the branch is dead code.

Why render-time over wp search-replace:

No database mutation. Rollback is deactivating a snippet.
It's conditional. It only rewrites when a real target exists — a .webp sibling on disk, or a primary file named in attachment metadata. A blind .png → .webp search-replace would have broken every reference to the ~54 icons that were correctly never converted.
It covers everything. Gutenberg blocks, Divi modules, classic editor content — all pass through the_content. The per-request static cache keeps file_exists() negligible, and page caching absorbs the rest.

Running the regeneration

The site had Regenerate Thumbnails installed with a perfectly good UI. I used WP-CLI anyway, for two reasons.

Disk visibility. The plugin runs until done or until the volume fills. The box was at 84%. Batching from CLI let me check headroom between chunks:

wp post list --post_type=attachment --post_mime_type=image/jpeg,image/png \
  --format=ids --posts_per_page=-1 | tr ' ' '\n' > /tmp/ids.txt
split -l 200 /tmp/ids.txt /tmp/idb_

for b in /tmp/idb_*; do
  nice -n 19 wp media regenerate $(tr '\n' ' ' < "$b") --only-missing --yes
  du -sm wp-content/uploads
  free -m | head -2
  sleep 30
done

Action Scheduler. The site had a chronic Action Scheduler backlog the host had already flagged as a CPU source. Admin-driven bulk tools queue work there. WP-CLI is synchronous and bypasses it entirely.

I also blocked WooCommerce's own background regeneration for the duration, since re-registering woocommerce_thumbnail can trigger it:

add_filter( 'woocommerce_background_image_regeneration', '__return_false' );

nice -n 19 matters more than it looks. It means the kernel gives live traffic priority over the migration on every single scheduling decision. CPU sat around 69% during the run and the site stayed responsive, because the 69% was work nobody else wanted.

Measured throughput: 66 seconds per 200 attachments. The full run took under twenty minutes.

Rolling it out to production

Staging and production were separate applications on the same server. I wrote the whole thing up as a runbook and replayed it, and it went nearly identically — which is the point of rehearsing.

Nearly. One thing bit me.

The host gives each application a private /tmp namespace. My batch files, ID list, and log had all been written to /tmp during the rehearsal, owned by the staging user. On production, every /tmp write failed:

bash: /tmp/ids.txt: Permission denied
rm: cannot remove '/tmp/idb_aa': Operation not permitted
split: /tmp/idb_aa: Permission denied

Except the reads didn't fail. wc -l /tmp/ids.txt cheerfully returned 2216 — staging's file. My first production batch ran against the rehearsal environment's ID list. It happened to work, because the two databases share attachment IDs, but that was luck. The background script never started at all, and I only noticed because the log line count sat at zero.

Moved everything to a private directory outside the web root and it ran clean.

The lesson isn't "check permissions." It's that a partially-failed setup is more dangerous than a fully-failed one. If /tmp had been readable and unwritable in a consistent way I'd have caught it instantly. Instead the writes failed loudly and the reads succeeded silently, and the silent success is what nearly shipped a run against the wrong data.

Final numbers matched the rehearsal exactly: 2,097 of 2,216 converted, 55 sub-threshold icons untouched, 64 attachments whose files were already missing, and every oversized -scaled image passing the URL-rewrite check.

Results

Metric	Before	After
WooCommerce thumbnail coverage	141 / 2,216 (6%)	complete
`srcset` candidates per image	1 (1024px)	4 (100/150/300/768)
Attachments with WebP primary	18	2,097
Uploads directory	~2,100MB	~1,900MB
Sample: 1.33MB PNG hero	1,332,273 B	27,634 B
Sample: 322KB JPEG headshot	322,419 B	37,214 B

The uploads directory got smaller. Adding roughly 11,000 WebP files while deleting 12,283 orphaned sidecars nets out negative. Disk was never the constraint I'd braced for.

The biggest win isn't in that table. It's that WooCommerce stopped resizing images on demand for 94% of product requests. That was real CPU on every uncached page load, and it's simply gone now.

What's still wrong

I'd have called this done, except the first Divi page I checked afterward served this:

<img src=".../DrEdythe_7.2024-scaled.webp"
     srcset=".../DrEdythe_7.2024-scaled.webp 1831w,
             .../DrEdythe_7.2024-732x1024.webp 732w, ..."
     sizes="(max-width: 1831px) 100vw, 1831px">

Correct format, correct src, four srcset candidates. And still wrong.

Read the sizes attribute. It tells the browser the image occupies the full viewport width up to 1831px. The module actually renders in a column a third of that. So the browser dutifully picks the 1831w candidate — 574KB — when the 732w file at 99KB would have covered the slot.

Which is the same failure as the thumbnail ladder, wearing a different hat. I spent a session making sure the right files existed and the right URLs pointed at them, and the browser is still downloading 6× more than it needs because one attribute lies about the layout.

That one's fixable through wp_calculate_image_sizes, but it needs measuring against real module widths rather than guessed — and it's a bigger remaining win than the format change was.

There's also a cleanup I deliberately didn't do. Superseded originals are still on disk: DrEdythe_7.2024-732x1024.png at 1.36MB sitting inert next to its 99KB WebP, and hundreds more like it. Tempting to sweep. But while the render-time filter is doing delivery, those files are the rollback path — deactivating the snippet reverts URLs to .png, which only works if the .png is still there. That deletion waits until WebP has been boring in production for a month.

What I'd tell past-me

Audit before you optimize. The task I'd written down for myself was "convert images to WebP." The actual problem was a stripped size ladder causing on-the-fly resizing and 3× mobile payloads. Twenty minutes of find and wp eval reordered the entire job — and turned a cosmetic improvement into a real one.

Non-sequential array keys are a fingerprint. [3], [16], [17], [18] told me a filter was unsetting entries at runtime, not that sizes were never registered. That one detail pointed straight at the plugin responsible.

Check what the previous optimizer left behind. Uninstalling an image plugin doesn't remove its output. Grep for orphaned formats before adding another.

original_image is the check that prevents slow-motion disaster. Without it you get lossy-from-lossy regeneration compounding over years, and nobody notices until every image on the site is soft.

Check the biggest images last, not first. My URL-rewrite filter passed every test I wrote
and still left the single largest file on the site unconverted, because -scaled originals
don't have the filename the naive swap looks for. Verify against your worst-case asset, not a
representative one.

A verification query can measure itself. Those 64 missing files bothered me, so I wrote a
check to find out whether anything referenced them. It reported 64 out of 64 referenced —
alarming, and wrong. It was counting each attachment's own _wp_attached_file and
_wp_attachment_metadata rows as evidence that something else pointed at it, and matching a
filename stem like back against every post containing the word "back." Every row came back
"used" because the query couldn't tell a reference from a reflection. Walking the actual pages
in a browser had already given the right answer; I just trusted the SQL more because it had a
number in it.

Generating the right sizes beats changing the format — and telling the browser the truth beats both. WebP is maybe 30% off a file. Serving a 300px image instead of a 1024px one is 90%. And an honest sizes attribute is what makes the browser actually choose the 300px one. Format, dimensions, declaration — in ascending order of how much they matter and descending order of how much attention they get.

Notes: written up from a real migration on a WooCommerce + LearnDash + Divi site I maintain. Proactive maintenance work, not a client request. Site details anonymized — swap in specifics if you have sign-off. Table prefix shown as wp_ throughout; use $(wp db prefix) on real sites.

How fast do you finish your usage on Claude Code?

Vicente G. Reyes — Wed, 29 Jul 2026 04:24:30 +0000

On heavy coding work, I finish Claude's usage in more or less 2 hours. Is that fine or not? I'm on Claude Pro. How about you?

The Case of the Disappearing Free Trial

Vicente G. Reyes — Fri, 24 Jul 2026 14:18:17 +0000

A debugging story about WooCommerce Subscriptions, caching red herrings, and one deliberate line of code that quietly broke a conversion funnel.

The Symptom

A client's fitness membership site offers a 7-day free trial on its subscription products. Simple enough: sign up, browse the workout library free for a week, get charged automatically after — standard WooCommerce Subscriptions behavior.

Except guests visiting the site couldn't see the trial at all. The product page just showed the regular monthly price. No trial messaging, no "$0 due today." And when a guest actually went through checkout, they were charged the full price immediately — no 7-day grace period in sight.

Logged-in users saw the trial just fine. Every time.

That single fact — logged in: works, logged out: doesn't — turned out to be both the biggest clue and the biggest trap of the entire investigation.

First Theories (All Wrong)

The obvious first guess: maybe this particular product's trial configuration was broken. A quick look at the product's variations showed the trial length was set correctly — 7 days, right there in the admin. So that wasn't it.

Next theory: maybe it was a caching problem. The site ran multiple cache layers — a page cache, a reverse proxy cache, and a persistent object cache. Guest requests are cached far more aggressively than logged-in ones, so a stale cached copy of the page (generated before some earlier fix) could easily explain "guests see the old broken version, logged-in users always get a fresh page."

This felt promising enough to chase hard:

Purged the page cache. No change.
Purged the reverse-proxy cache. No change.
Flushed the persistent object cache directly via WP-CLI. No change.
Tested with cache-busting query strings and Cache-Control: no-cache headers, confirmed via response headers that the request was a genuine cache MISS, generated fresh, at that exact moment. Still no trial for the guest request.

That last test was important. It proved, with certainty, that this wasn't caching at all. PHP was executing fully, fresh, for an anonymous visitor — and still choosing not to show the trial. Whatever was happening, it was happening in application logic, not in a cache layer.

Ruling Out an Entire Stack, One Piece at a Time

With caching off the table, the search moved into the code itself. Over the following days:

Product-level theories (duplicate variations, a "Virtual" checkbox left unchecked, a product-type mismatch between simple vs. variable subscriptions) were tested and eliminated — the same behavior showed up across every subscription product on the site, not just one.
Custom code — theme files, must-use plugins, active Code Snippets — was searched exhaustively via grep for anything referencing trial length, price display, or login state. All clean.
WooCommerce Dynamic Pricing, a plugin capable of role-based price rules, was a strong suspect for a while. Ruled out by testing as a plain logged-in Customer account (no special role) — the trial showed correctly, meaning it wasn't about which role you had, only whether you were logged in at all.
A subscription "Enhancer" plugin with its own trial-limiting logic looked like the smoking gun for a moment. Tracing its actual function line-by-line showed it explicitly left guests untouched — it only affected logged-in users checking for repeat trials. Not the cause.
WooCommerce Subscriptions' own core code was traced end-to-end: the function that reads a product's trial length, the function that turns that into the "with a 7-day free trial" string, the method that assembles the final price HTML. No login check anywhere in any of it.

By this point, every obvious suspect — and several non-obvious ones — had been checked and cleared. The trial data was correct. The display logic was correct. And yet, for a guest, the number was still coming out as zero.

Following the Data, Not the Guesses

The turning point was switching from "search the files" to "ask WordPress directly what's actually happening at runtime."

WP-CLI made this possible:

wp eval 'echo WC_Subscriptions_Product::get_trial_length(11343);'

Run as an anonymous request (user ID 0, matching a real guest), this returned 0. Run with an authenticated user context, it correctly returned 7. Confirmed, cleanly: the discrepancy was real, reproducible, and happening inside this exact function call.

That function's actual implementation was almost embarrassingly simple:

public static function get_trial_length( $product ) {
    return apply_filters( 'woocommerce_subscriptions_product_trial_length', self::get_meta_data(...), ... );
}

It reads the correct value from the database (7, confirmed directly via wp post meta get) — then passes it through a WordPress filter before returning it. Somewhere, something was hooked onto that filter and changing the number.

A plain-text search for that filter name across the plugin and theme files found only two matches: the definition itself, and one plugin's filter (already cleared above). Nothing else — which didn't make sense, because something was clearly modifying the value.

The missing piece was that custom code snippets aren't stored as files at all — they live in the database, injected into the request at runtime. No filesystem search will ever find them.

The real breakthrough came from asking WordPress's own hook registry directly:

wp eval 'global $wp_filter; 
foreach ($wp_filter["woocommerce_subscriptions_product_trial_length"]->callbacks as $priority => $callbacks) { 
    foreach ($callbacks as $cb) { 
        echo "Priority $priority: " . (is_array($cb["function"]) 
            ? get_class($cb["function"][0]) . "::" . $cb["function"][1] 
            : "Closure") . "\n"; 
    } 
}'

This listed every single callback actually hooked onto that filter, in execution order — including a Closure, running before everything else, that no static search had caught. Using PHP's reflection API to ask that closure where it was defined pointed straight at a database-stored code snippet.

The Actual Bug

The snippet in question, named "Blocks Multiple Free Trials," was a perfectly reasonable piece of anti-abuse logic: don't let a customer claim a second free trial on a product they've already subscribed to before. Good instinct, sound feature.

But nested inside it was this:

if ( ! is_user_logged_in() ) {
    return 0; // Stronger enforcement: require login for any trial
}

Not a bug in the traditional sense — a deliberate design decision, with a comment explaining exactly what it did. Someone had decided that requiring a login before offering any trial was a form of "stronger enforcement." It technically worked as written. It just wasn't what the business actually wanted: real customers were landing on the site from social media, seeing a product that advertised a 7-day trial, and getting charged in full the moment they checked out as a guest.

The Fix

The fix didn't touch the legitimate repeat-trial protection at all — only the guest-blocking branch:

if ( ! is_user_logged_in() ) {
    return $trial_length; // Guests get the trial; repeat-check only applies to logged-in users
}

Guests now see the trial correctly, first-time visitors get $0-today checkout with the first charge seven days later, and returning customers still can't double-dip on a second trial. One line changed; the intended behavior preserved.

What Made This One Hard

A few things stack up to make a bug like this genuinely difficult, worth naming for anyone hitting something similar:

The correlation was real but the causation was wrong. "Logged in vs. logged out" was a completely accurate description of the symptom the entire time — it just pointed everyone toward login-related plugin settings and eligibility logic, when the actual cause was a single conditional buried three layers deep in unrelated anti-abuse code.
Every individual system was innocent. WooCommerce core, the theme, the caching layers, the pricing plugin — each one, checked in isolation, was completely correct. The bug lived in custom glue code that no one else's system could see or account for.
Code Snippets don't show up in a filesystem search. Anything stored and evaluated from the database is invisible to grep, and easy to forget existed at all if it isn't the snippet you're actively thinking about.
A deliberate decision looks identical to a bug from the outside. The code wasn't broken; it was doing exactly what it was told. The mismatch was between what the code said and what the business actually wanted — which no amount of debugging tools can catch unless you're willing to trace all the way down to the literal returned value and ask "why."

Takeaways

When behavior differs by user state, don't assume it's a permissions/eligibility setting — check for custom filters hooked into the same pipeline, especially in code you didn't write yourself.
grep is powerful, but it can't see what's stored in a database. If a site has any kind of snippet manager, check its actual contents directly — not just "how many snippets are active" in an admin list.
When static analysis stalls, ask the running application directly. wp eval and inspecting $wp_filter at runtime found in minutes what days of file searching couldn't.
Not every "bug" is broken code. Sometimes it's a correct implementation of an incorrect assumption — and the fix is a conversation about intent, not just a patch.

The Button That Sent People to a Blank Form

Vicente G. Reyes — Wed, 22 Jul 2026 11:03:55 +0000

Every service page on my portfolio ends with the same call to action: a big Start Project button. Click it on the Automation page, and you land on the contact form ready to talk about automation. That was the idea, anyway.

What actually happened: you'd click Start Project on /services/automation-solutions, get redirected to /contact, and the "What do you need?" picker would be sitting there completely unselected. The one piece of context the user had just handed me — I want automation — was thrown away the moment they navigated. They'd have to re-tell me what they came to tell me.

This is a small bug. It's also exactly the kind of friction that quietly costs conversions. Here's the fix.

The Setup

There are actually two contact forms in this codebase, which is where the confusion started.

The service pages (ServicePage.tsx) each render their own inline contact form near the bottom, and that one already pre-selected the right service — it derives the default from the URL slug:

const SLUG_TO_SERVICE: Record<string, string> = {
  'software-development': 'software',
  'shopify-development':  'shopify',
  'automation-solutions': 'automation',
  // ...
};

const defaultService = (SLUG_TO_SERVICE[slug ?? ''] ?? '') as ServiceValue;

But the Start Project button in the hero didn't scroll to that inline form. It navigated to the standalone contact page, a completely separate component (ContactPage.tsx):

<Button onClick={() => navigate('/contact')}>
  Start Project <ArrowRight size={20} />
</Button>

And ContactPage always initialized its form with an empty service:

const [form, setForm] = useState<FormData>({
  name: '', email: '', service: '', budget: '',
  timeline: '', website: '', message: '', honeypot: '',
});

So the button crossed a boundary — from a page that knew what the user wanted to a page that had no idea — and nothing carried the context across.

The Fix: Carry the Intent in the URL

The cleanest way to pass a small piece of state across a navigation is the URL itself. A query param is shareable, bookmarkable, survives a refresh, and doesn't need any global store. So the button now appends the service it already knows about:

<Button
  onClick={() => navigate(defaultService ? `/contact?service=${defaultService}` : '/contact')}
>
  Start Project <ArrowRight size={20} />
</Button>

Note the guard: if the slug maps to nothing (defaultService is ''), it falls back to a plain /contact instead of producing an ugly /contact?service=.

On the receiving end, ContactPage reads the param on mount and validates it before trusting it. That validation matters — a query param is user-editable, and I don't want ?service=drop-table (or just a typo) to put the form into a weird state:

import { useSearchParams } from 'react-router-dom';

const VALID_SERVICES = SERVICES.map((s) => s.value) as readonly string[];

const normalizeService = (raw: string | null): ServiceValue =>
  raw && VALID_SERVICES.includes(raw) ? (raw as ServiceValue) : '';

Then I use a lazy initializer for the form state so the param is applied exactly once, when the component first mounts:

const [searchParams] = useSearchParams();

const [form, setForm] = useState<FormData>(() => ({
  name: '', email: '', service: normalizeService(searchParams.get('service')), budget: '',
  timeline: '', website: '', message: '', honeypot: '',
}));

That's the whole change — two files, about eleven lines. The service picker now highlights the right option the moment the page loads, and because the budget selector only appears after a service is chosen, arriving from a service page also reveals the correct price ranges immediately.

A Subtlety About When It Runs

The lazy initializer only runs once, on mount. That's deliberate, and it's worth understanding why it's correct here.

When a user clicks Start Project, they navigate from the /services/... route to the /contact route. React Router unmounts one page component and mounts the other — a fresh mount, so the initializer runs and reads the param.

But if you were already on /contact and only the query string changed, React Router would keep the same component mounted and the initializer would not re-run. For a second I wondered if I needed a useEffect to sync on param changes. I decided against it: there's no UI path where the query param changes while you're sitting on the contact page. Adding an effect to handle a situation that can't happen is just a new bug waiting to be misunderstood later. If that ever changes, the effect is easy to add.

Testing It for Real

I didn't want to eyeball this one. A pre-select bug is exactly the kind of thing that "looks fine" and silently regresses, so I drove a real browser against the dev server and checked the actual DOM state instead of trusting a screenshot.

The selected service button carries a -translate-y-1 class (the little neubrutalist "lift"), so I could assert on it directly:

Scenario	URL after action	Selected option	Budget section
Click Start Project on Automation	`/contact?service=automation`	Automation	Visible, automation ranges
Land on `/contact` directly	`/contact`	(none)	Hidden
Tampered `?service=bogus`	`/contact?service=bogus`	(none)	Hidden

The middle and bottom rows are the ones I actually cared about — they prove the feature doesn't leak into the no-param case and that normalizeService throws away garbage instead of choking on it.

One gotcha while testing: my first attempt navigated between cases with history.pushState inside the running app, and every case came back showing "Automation" still selected. That wasn't a bug in the fix — it was the same behavior I described above. pushState doesn't remount ContactPage, so the initializer never re-ran and the old state persisted. Switching to full page loads for each case gave honest results. A nice reminder that your test harness has to respect the component lifecycle you're actually shipping.

The Takeaway

The bug wasn't a broken function. Everything worked in isolation — the button navigated, the form rendered, the picker picked. The bug lived in the gap between two components, where a piece of user intent quietly fell on the floor.

The URL is a great place to catch things falling through those gaps. It's the one piece of state both sides of a navigation can always agree on. Put the intent in the query string, validate it on the way in, and the two pages don't need to know anything about each other.

I Added Sentry to a WooCommerce Membership Site. It Caught a Real Bug Within the Hour.

Vicente G. Reyes — Mon, 20 Jul 2026 13:16:19 +0000

I'm the lead developer on a WooCommerce/Divi/LearnDash membership platform. Like most mature WordPress sites, it runs a lot of plugins — page builder, LMS, membership gating, marketing automation, forms, SMTP — and when something breaks, the failure usually surfaces as a vague member complaint days later, not as an actionable error with a stack trace.

I finally fixed that by wiring up Sentry with the WordPress Sentry plugin (wp-sentry-integration). Setup took about twenty minutes. The first real bug showed up in the feed within the hour — an error loop that had been silently firing on every hit to a REST endpoint, and that nobody would ever have reported, because it never broke anything a user could see.

This post covers the setup, the gotchas, and the first catch.

Why the wp-sentry plugin and not the raw SDK snippets

When you create a Sentry project, the onboarding page hands you a \Sentry\init() snippet for PHP and a loader <script> tag for the browser. You don't want either of them on a WordPress site.

The wp-sentry-integration plugin bundles both official SDKs and does the integration work you'd otherwise hand-roll:

Initializes the PHP SDK early enough in the WordPress bootstrap to catch fatals from other plugins
Hooks PHP errors, exceptions, and fatal errors
Enqueues the browser SDK on the frontend and wires up tracing and Session Replay
Attaches WordPress context to every event: the logged-in user, environment, release, and plugin/theme metadata

The part that confused me at first: the plugin's settings page has checkboxes, and none of them are clickable. That's by design. The plugin has zero UI configuration. Everything is driven by constants in wp-config.php, and the settings page is a read-only dashboard that reports which constants it detected. Checkbox ticked means the constant exists and is valid. You can click them all day and nothing happens.

I've come around to this being the right call. Your error-tracking config lives in code, survives plugin updates, can't be broken from wp-admin, and a compromised admin account can't quietly redirect your error stream to someone else's DSN. Same philosophy as DISABLE_WP_CRON.

Setup

1. Two Sentry projects, not one

Create separate projects for PHP and browser JavaScript. On a plugin-heavy WooCommerce site, browser noise — extension errors, ancient browsers, third-party scripts — will drown out real server-side errors if they share a project. Splitting them keeps triage sane and lets you set different alert rules and quotas per side.

2. Constants in wp-config.php

Everything goes above the /* That's all, stop editing! */ line:

// --- Sentry ---
define( 'WP_SENTRY_PHP_DSN', 'https://xxxx@oXXXX.ingest.us.sentry.io/PHP_PROJECT_ID' );
define( 'WP_SENTRY_BROWSER_DSN', 'https://xxxx@oXXXX.ingest.us.sentry.io/JS_PROJECT_ID' );

define( 'WP_SENTRY_ENV', 'production' );

// Attach the logged-in WP user (id/username/email) to events
define( 'WP_SENTRY_SEND_DEFAULT_PII', true );

// Keep tracing cheap — it eats quota fast
define( 'WP_SENTRY_TRACES_SAMPLE_RATE', 0.05 );
define( 'WP_SENTRY_BROWSER_TRACES_SAMPLE_RATE', 0.05 );

// Session Replay: no ambient recording, full replay on error
define( 'WP_SENTRY_BROWSER_REPLAYS_SESSION_SAMPLE_RATE', 0 );
define( 'WP_SENTRY_BROWSER_REPLAYS_ON_ERROR_SAMPLE_RATE', 1.0 );

One trap: the browser value must be the DSN from Settings → Client Keys, not the CDN loader script URL that Sentry's JS onboarding page shows you. They look superficially similar. The DSN has the https://key@org.ingest...sentry.io/project_id shape.

A few decisions worth explaining:

SEND_DEFAULT_PII on a membership site is genuinely useful — you can tie a checkout error directly to the member who reported it instead of playing email tag. The tradeoff is that member emails now live in Sentry, so lock down team access and account for it in your privacy policy.
Replay sample rates of 0 / 1.0 means no routine session recording, but when a JS error fires you get the full replay of what the user did leading up to it. On checkout flows this is gold. Sentry masks all text and inputs by default; verify that before trusting it near payment forms.
Skip profiling. It requires the excimer PHP extension, which most managed WordPress hosts don't ship. Tracing plus replay covers what you actually need.

3. Verify

Reload the plugin's tools page — the checkboxes should now be ticked and the test buttons active. Fire the PHP test event and the browser test error, and confirm each lands in the correct project. The browser test on my setup also captured a session replay, which confirmed the whole replay pipeline in one shot.

4. Turn on inbound filters immediately

In the JS project: Settings → Inbound Filters → enable the browser-extension, legacy-browser, and web-crawler filters. Do this on day one, not after your quota is gone.

The first catch

Within the hour, a real issue appeared in the PHP project:

Exception: Scheduled action for bwfcrm_broadcast_run_queue will not be
executed as no callbacks are registered.

Firing from GET /wp-json/woofunnels/v1/worker — FunnelKit's background worker endpoint.

Reading the trace

The exception came from Action Scheduler's safety check:

if ( ! has_action( $hook ) ) {
    throw new Exception( 'Scheduled action ... will not be executed
        as no callbacks are registered.' );
}

Action Scheduler refuses to run a scheduled job that has no listeners — it treats a dangling hook as a broken state and throws.

The hook, bwfcrm_broadcast_run_queue, belongs to FunnelKit's CRM/broadcast module. The site doesn't use email broadcasts (I confirmed with the client — a one-line message, thirty seconds), so nothing registers that hook anymore. But the recurring action for it still lived in FunnelKit's custom action store, scheduled to run every 60 seconds.

Sentry's SQL breadcrumbs made the loop visible: the worker fetches the action, the execution throws, and the fetch path re-schedules the next occurrence. An orphaned job, erroring and rebooking itself forever. It had presumably been doing this since whenever the CRM module was deactivated — invisible, because the exception is handled and nothing user-facing ever broke.

This is exactly the class of bug error monitoring exists for. No member would ever report it. No admin screen showed it. It was just background waste: a query cycle and a thrown exception on every worker run, on a site that already had a history of Action Scheduler bloat.

The fix: delete the work, keep a guard

Two parts.

Delete the orphaned recurring action. The table and hook name come straight from the event's own breadcrumbs, so the query is exact — but look before you delete:

wp db query "SELECT id, hook, status, recurring_interval, group_slug
  FROM wp_bwf_actions
  WHERE hook = 'bwfcrm_broadcast_run_queue';"

wp db query "DELETE FROM wp_bwf_actions
  WHERE hook = 'bwfcrm_broadcast_run_queue';"

(Adjust the table prefix for your install.) This isn't as scary as deleting from an unknown table sounds: the plugin's own queue runner deletes rows from this table constantly as part of normal processing — the last breadcrumb in the Sentry event was literally a DELETE on the same row. Worst case, re-enabling the CRM module re-registers the hook and re-seeds the schedule from scratch. There's no unrecoverable state in a row that says "run this hook every 60 seconds."

Register a no-op guard. Some plugins have a habit of re-seeding their recurring actions on init or after updates. If that happens here, I don't want the error loop back — so I registered a listener that does nothing:

// Guard: orphaned FunnelKit CRM broadcast hook.
// The bwfcrm_broadcast_run_queue recurring action has no registered
// callback (CRM/broadcasts unused — confirmed with the client).
// This no-op prevents Action Scheduler from throwing if the action
// gets re-seeded. Safe to remove if FunnelKit CRM is ever activated.
add_action( 'bwfcrm_broadcast_run_queue', '__return_null' );

__return_null is a WordPress core utility whose entire body is return null;. Registering it means has_action() returns true, the safety check passes, and a re-seeded action "runs" harmlessly instead of restarting the error stream.

I put this in Code Snippets rather than the theme's functions.php — it's an infrastructure fix, not presentation code, and it should survive theme switches, stay individually toggleable, and be findable by name by the next developer (or by me in six months). The comment block matters as much as the code: a bare add_action( 'something', '__return_null' ) with no explanation is a trap for whoever finds it later.

Then: resolve the issue in Sentry. If the action ever re-seeds and the guard is somehow gone, Sentry reopens the issue and I know immediately — that's regression detection for free.

Takeaways

On WordPress, configure Sentry through the wp-sentry plugin's constants, not the onboarding snippets. The plugin is the engine; wp-config.php is the ignition key.
Split PHP and browser into separate projects and enable inbound filters on the JS side before the noise starts.
Handled exceptions are still signal. The bug I found threw a caught exception — nothing crashed, no user saw anything. Without monitoring it would have run forever.
Sentry breadcrumbs can hand you the fix. The SQL breadcrumbs contained the exact table, the exact row, and proof that deleting the row was an operation the plugin itself performs routinely.
Fix orphaned scheduled actions in two layers: delete the orphan (stop the waste), and register a no-op guard (stay fixed if the plugin re-seeds it). Then resolve the issue in Sentry and let it be your regression alarm.

Total time from "install the plugin" to "real production bug found, diagnosed from the stack trace and breadcrumbs, fixed with a two-layer patch": about an hour. That's the fastest an observability tool has ever paid for itself on one of my projects.

Closing the Loop: Emailing Myself When My Resume Gets Downloaded

Vicente G. Reyes — Fri, 17 Jul 2026 12:06:56 +0000

I already had a resume download gate — email required, signed link, 15-minute expiry, presigned S3 URL good for two minutes. What it didn't have was a way for me to know it happened. Someone could download my resume and I'd never find out unless I went digging through ResumeDownloadRequest rows in the admin.

This is the short follow-up: one notification email, sent to me, the moment someone actually opens the PDF.

Where to Hook It

The gate has two views:

ResumeRequestDownloadView.post() — fires when someone submits their email and gets sent a link
ResumeDownloadView.get() — fires when someone clicks that link and the signed token is verified

Submitting an email isn't the same as downloading. Plenty of people fill in a form and never check their inbox. I wanted the notification tied to a confirmed download, so it belongs in ResumeDownloadView.get() — right after the token is verified and the resume is confirmed to exist, just before the redirect to the presigned S3 URL.

Finding the Right Recipient

My first instinct was to reach for settings.ADMINS, Django's built-in list for mail_admins(). But ADMINS in config/settings/base.py looked like a placeholder:

ADMINS = [("""Vicente G. Reyes""", "me@example.com")]

me@example.com — that x reads exactly like scaffolding nobody replaced. I almost went and fixed it to a real inbox before sending anything.

Then I noticed something else: .envs/.production/.django also had DJANGO_SERVER_EMAIL=x. Two placeholder-looking values with the same address wasn't a coincidence — it turned out me@example.com is a real catch-all alias on the domain, already wired to forward to an inbox that gets checked. Not a placeholder at all.

That distinction mattered for a second reason: SERVER_EMAIL and ADMINS do different jobs in Django. SERVER_EMAIL is the From address Django uses when it sends admin error emails via mail_admins(). ADMINS is the recipient list for those same emails. Confusing the two would have had me trying to "fix" a sender address as if it were a destination.

Given me@example.com was already correct and already sitting in ADMINS, there was nothing to add. I just needed to read from the setting that already existed.

The Change

project/core/views.py — inside ResumeDownloadView:

class ResumeDownloadView(APIView):
    authentication_classes = []
    permission_classes = []

    def get(self, request):
        token = request.query_params.get("token", "")
        if not token:
            return Response(
                {
                    "data": None,
                    "message": "",
                    "errors": {"token": ["This field is required."]},
                },
                status=status.HTTP_400_BAD_REQUEST,
            )
        signer = signing.TimestampSigner()
        data = None
        with contextlib.suppress(signing.SignatureExpired, signing.BadSignature):
            data = signer.unsign_object(token, max_age=RESUME_TOKEN_MAX_AGE)
        if data is None:
            try:
                signer.unsign_object(token)
                return Response(
                    {
                        "data": None,
                        "message": "Download link expired. Please request a new one.",
                        "errors": None,
                    },
                    status=status.HTTP_410_GONE,
                )
            except signing.BadSignature:
                return Response(
                    {
                        "data": None,
                        "message": "Invalid download token.",
                        "errors": None,
                    },
                    status=status.HTTP_400_BAD_REQUEST,
                )
        resume = Resume.objects.filter(pk=data.get("pk")).first()
        if not resume or not resume.pdf:
            return Response(
                {"data": None, "message": "Resume not found.", "errors": None},
                status=status.HTTP_404_NOT_FOUND,
            )
        self._notify_owner(data.get("email", "unknown"))
        return HttpResponseRedirect(resume.pdf.url)

    def _notify_owner(self, downloader_email: str) -> None:
        recipients = [admin_email for _, admin_email in settings.ADMINS]
        if not recipients:
            return
        body = (
            f"Someone just downloaded your resume.\n\n"
            f"Email: {downloader_email}\n"
            f"Time: {timezone.now().strftime('%Y-%m-%d %H:%M:%S %Z')}"
        )
        with contextlib.suppress(Exception):
            send_mail(
                subject="Resume downloaded",
                message=body,
                from_email=settings.DEFAULT_FROM_EMAIL,
                recipient_list=recipients,
                fail_silently=True,
            )

Same pattern as the existing _send_download_email right above it in the file: plain send_mail, wrapped in contextlib.suppress(Exception), fail_silently=True. If Mailgun hiccups, the downloader still gets their redirect — a failed notification email should never block the actual download.

recipients iterates all of ADMINS rather than hardcoding settings.ADMINS[0][1], so adding a second admin later needs zero changes here.

One import needed adding — django.utils.timezone, for the timestamp in the notification body.

Tests

project/core/tests.py had zero coverage for the resume download flow before this — the gate shipped without tests originally. Added a fixture for a Resume with a real uploaded file, a fixture for a signed token, and a test class covering the redirect, the notification, and the existing error paths:

import datetime

import pytest
from django.core import signing
from django.core.files.uploadedfile import SimpleUploadedFile
from django.urls import reverse
from rest_framework.test import APIClient

from project.blogs.models import BlogPost
from project.projects.models import Project
from project.services.models import Service

from .models import FAQ
from .models import Resume
from .models import Skill
from .models import Stat
from .models import Testimonial


# ---------------------------------------------------------------------------
# Resume download
# ---------------------------------------------------------------------------


@pytest.fixture
def resume(db):
    return Resume.objects.create(
        pdf=SimpleUploadedFile("resume.pdf", b"%PDF-1.4 fake", content_type="application/pdf"),
    )


@pytest.fixture
def resume_token(resume):
    signer = signing.TimestampSigner()
    return signer.sign_object({"pk": resume.pk, "email": "downloader@example.com"})


@pytest.mark.django_db
class TestResumeDownloadView:
    def test_valid_token_redirects_to_pdf(self, client, resume, resume_token):
        response = client.get(reverse("api:resume-download") + f"?token={resume_token}")
        assert response.status_code == 302

    def test_valid_token_notifies_owner(self, client, resume, resume_token, mailoutbox):
        client.get(reverse("api:resume-download") + f"?token={resume_token}")
        assert len(mailoutbox) == 1
        assert mailoutbox[0].subject == "Resume downloaded"
        assert mailoutbox[0].to == ["me@example.com"]
        assert "downloader@example.com" in mailoutbox[0].body

    def test_missing_token_returns_400(self, client, db):
        response = client.get(reverse("api:resume-download"))
        assert response.status_code == 400

    def test_invalid_token_returns_400(self, client, db):
        response = client.get(reverse("api:resume-download") + "?token=garbage")
        assert response.status_code == 400

    def test_unknown_resume_pk_returns_404(self, client, db):
        signer = signing.TimestampSigner()
        token = signer.sign_object({"pk": 999, "email": "downloader@example.com"})
        response = client.get(reverse("api:resume-download") + f"?token={token}")
        assert response.status_code == 404

mailoutbox is a pytest-django fixture — it's Django's test EmailBackend capturing every send in a list, no mocking required. Asserting on mailoutbox[0].to doubles as a regression check: if ADMINS ever gets edited back to a placeholder, this test fails immediately instead of silently emailing nobody.

Ran inside the project's Docker dev container, matching how every other management command in this repo gets run:

docker compose -f docker-compose.local.yml run --rm django pytest project/core/tests.py -k Resume -v

project/core/tests.py::TestResumeDownloadView::test_valid_token_redirects_to_pdf PASSED
project/core/tests.py::TestResumeDownloadView::test_valid_token_notifies_owner PASSED
project/core/tests.py::TestResumeDownloadView::test_missing_token_returns_400 PASSED
project/core/tests.py::TestResumeDownloadView::test_invalid_token_returns_400 PASSED
project/core/tests.py::TestResumeDownloadView::test_unknown_resume_pk_returns_404 PASSED

5 passed in 5.31s

What I'd Do Differently

Batch the notification if downloads spike. Right now every single download sends a separate email. Fine at current traffic; if this ever got linked from somewhere with real volume, I'd want a short debounce window rather than an inbox flood.

Move the send off the request path. Same tradeoff as the original gate's send_mail call — it's synchronous, so the redirect waits on the SMTP round trip to Mailgun. No Celery in this project yet, so for now it's a few hundred milliseconds tacked onto every download. Worth revisiting if Celery ever gets added for other reasons.

Double-check ADMINS before trusting it elsewhere. This whole feature nearly took a wrong turn because a real address happened to look exactly like unfinished scaffolding. Worth a settings comment noting me@example.com is a live catch-all, not a TODO.

DEV Community: Vicente G. Reyes

The CI/CD Pipeline That Was Lying to Us: A Deploy Debugging Story

Act 1: The Deploy Job That Never Ran

Act 2: Two Bugs Wearing One Trenchcoat

Act 3: The Debt That Was Always There

Act 4: The Flaky Cache and the Duplicate Runs

Act 5: CI Was Finally Green. Deploy Still Failed.

Act 6: Two SSH Gotchas

Act 7: Right Key, Wrong Directory

Act 8: The First Real Deploy Broke the Site

What Actually Was Wrong, All Together

Takeaway

Side project deployed https://www.gigglegigs.com/ tomorrow is devops and SEO day!

What do you think is better, a free period or a freemium?

Your App Center List Is Not a Security Audit

Reading the GUI correctly first

1. Snap publishers

2. Third-party APT repositories

3. Verifying the signing key

4. Binary integrity

5. Running services and persistence

What this audit does not cover

The runbook

Why I Couldn't Access My Own Site (But My Phone Could): A Cloudways Auto-Ban Story

The Setup

The Failed Attempts

The Clue That Cracked It

The Real Issue: Cloudways Had Auto-Banned My IP

The Fix

Takeaway

The Bug That Threw No Errors: How a Repeat-Trial Guard Silently Killed Our Free Trial Funnel

The setup

The symptom

The root cause

The fix

What Sentry taught me by not catching this

The WebP Migration That Wasn't About WebP

Always inventory before you optimize

Finding 1: 241MB of files nothing was serving

Finding 2: the size ladder had been demolished

Why this is worse than it sounds

Finding 3: the images weren't the disk hog

The fix: three filters, no new plugins

1. Restore the size ladder

2. WebP output for generated subsizes

3. Rewrite hardcoded URLs at render time

The -scaled trap

Running the regeneration

Rolling it out to production

Results

What's still wrong

What I'd tell past-me

How fast do you finish your usage on Claude Code?

The Case of the Disappearing Free Trial

The Symptom

First Theories (All Wrong)

Ruling Out an Entire Stack, One Piece at a Time

Following the Data, Not the Guesses

The Actual Bug

The Fix

What Made This One Hard

Takeaways

The Button That Sent People to a Blank Form

The Setup

The Fix: Carry the Intent in the URL

A Subtlety About When It Runs

Testing It for Real

The Takeaway

I Added Sentry to a WooCommerce Membership Site. It Caught a Real Bug Within the Hour.

Why the wp-sentry plugin and not the raw SDK snippets

Setup

1. Two Sentry projects, not one

2. Constants in wp-config.php

3. Verify

4. Turn on inbound filters immediately

The first catch

Reading the trace

The fix: delete the work, keep a guard

Takeaways

Closing the Loop: Emailing Myself When My Resume Gets Downloaded

The `-scaled` trap