DEV Community: Vicente G. Reyes

GiggleGigs: A Job Board That Actually Uses AI Where It Helps

Vicente G. Reyes — Tue, 22 Sep 2026 16:57:43 +0000

Most job boards are glorified spreadsheets with a search bar. GiggleGigs isn't. It's a two-sided marketplace — "Find Work. Hire Talent." — built to close the gap between "I posted a job" and "I hired someone good," using AI at exactly the three points where it saves real time: writing the posting, writing the application, and screening the results.

Here's what's actually under the hood, and why it's worth a look.

The Problem It Solves

Job boards fail in a predictable way: employers post vague listings because writing a good one is tedious, candidates send generic applications because tailoring one is tedious, and then the employer drowns in a stack of applications that all look the same. Nobody's time gets saved — the tedium just moves downstream.

GiggleGigs attacks all three steps at once:

Companies write a two-sentence prompt and GiggleGigs' AI job-description writer expands it into a full posting with requirements, budget framing, and structure.
Seekers get an AI-drafted, job-specific cover letter instead of copy-pasting the same one everywhere — and can even upload a resume during onboarding and have Gemini auto-fill their entire profile (name, bio, skills, headline, links, experience) in seconds.
Companies then use an AI application screener that match-scores and summarizes every applicant against the job's actual requirements, so reviewing 40 applications doesn't mean reading 40 applications.

That's the pitch: less busywork on both sides of the transaction, and a marketplace that gets more useful the more people use it.

What's Actually Built

This isn't a prototype — it's a full production-shaped Django + React application with a genuinely deep feature set:

For job seekers

Skill/location/budget/timeline-filtered job search
One-click applications with optional resume upload (PDF/DOC/DOCX, validated server-side)
AI cover letter generation and AI resume-parsing onboarding
Real-time application tracking across a five-stage pipeline (Pending → Reviewing → Interviewed → Hired/Rejected/Withdrawn)
Application withdrawal, favorited jobs, and a daily digest email of new jobs matching your skills

For companies

Full job posting management (hourly or fixed price, detailed requirements)
A filterable, sortable applicant dashboard with live hiring-pipeline stats
AI-powered candidate search and AI match-scoring per applicant
Star-rating feedback to candidates, resume downloads, and team invitations for multi-seat company accounts
Credit-based billing via PayPal to unlock posting and candidate contact

Platform-wide

Real-time notifications over WebSockets (Django Channels + Daphne ASGI) — no polling, no refresh
JWT auth plus django-allauth for email/social login
Celery + Redis background processing with Celery Beat and Flower for monitoring
Content moderation tooling for jobs, companies, and users
A full analytics dashboard for staff on jobs and user activity
An API-first backend (Django REST Framework, OpenAPI schema via drf-spectacular) behind a React 18 + Vite SPA

Every one of these shipped incrementally and is live in the codebase today — this is a v1.7 product with a real changelog, not a feature wishlist.

The Business Model Is Already Wired In

GiggleGigs isn't just feature-complete — it's monetization-complete. Companies post their first two jobs a month for free (liquidity first, revenue second), and then convert through one of:

$29 single-post unlock — the low-commitment first purchase, for a company that just got applicants and wants to actually contact them
Starter ($49/mo) — for companies hiring regularly
Growth ($99/mo) — adds full candidate search
Annual plans at two months free

That progression — free listing → paid contact unlock → subscription — is a deliberate sequencing choice: liquidity (seekers applying) has to exist before employers will ever pay, so the free tier isn't a loss leader, it's the engine that makes the paid tier valuable at all.

Why the Engineering Choices Matter

A few decisions stand out as the kind that pay off later rather than look impressive now:

Services layer, not fat views — business logic lives outside the DRF views, which keeps the API surface thin and testable.
Proxy user model (Company / Seeker / Employee subtypes) instead of bolting role flags onto a single User table — cleaner permissions, cleaner queries.
Consistent { data, message, errors } API envelope across every endpoint, which makes the frontend's error handling and loading states uniform instead of ad hoc per-page.
Docker-only local workflow — Postgres, Redis, Django, Celery, Channels, and MailHog all come up together with one command, so "works on my machine" isn't a category of bug here.
Real-time built on Channels from day one, not retrofitted — notifications, status changes, and messaging all ride the same WebSocket infrastructure.

None of this shows up in a demo GIF, but it's the difference between a project that can take on its next ten features and one that needs a rewrite to get there.

Try It

GiggleGigs is a working, self-hostable job board and marketplace — clone it, docker compose -f local.yml up, and you have Postgres, Redis, Celery, Channels, and MailHog running together in one shot. If you're evaluating job-board platforms, building a niche talent marketplace, or just want to see AI applied to hiring in a way that removes tedium instead of adding a chatbot nobody asked for, it's worth a look.

Find work. Hire talent. Skip the busywork.

I'm the dev who messes shit up on Figma. I'm sorry. I do not do it on purpose.

Vicente G. Reyes — Mon, 21 Sep 2026 14:40:16 +0000

12 sections, 3.5 hours. Thank God for Claude MCP, Shopify MCP and Figma MCP. 👆

Vicente G. Reyes — Mon, 21 Sep 2026 11:49:38 +0000

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.

DEV Community: Vicente G. Reyes

GiggleGigs: A Job Board That Actually Uses AI Where It Helps

The Problem It Solves

What's Actually Built

The Business Model Is Already Wired In

Why the Engineering Choices Matter

Try It

I'm the dev who messes shit up on Figma. I'm sorry. I do not do it on purpose.

12 sections, 3.5 hours. Thank God for Claude MCP, Shopify MCP and Figma MCP. 👆

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 `-scaled` trap