DEV Community: Vicente G. Reyes

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.

TIL: identify. Check it out! man identify

Vicente G. Reyes — Wed, 15 Jul 2026 12:40:56 +0000

Automating Django `dumpdata` Backups to S3 (One Command, Zero SSH)

Vicente G. Reyes — Thu, 09 Jul 2026 12:03:27 +0000

If you're running a cookiecutter-django project on a droplet and still ssh-ing in every time you need a data snapshot, here's how I collapsed that into a single local command: dump → pull → upload to S3, no manual steps in between.

The Problem

My portfolio backend runs cookiecutter-django, containerized via Docker Compose, on a DigitalOcean droplet. Every time I wanted a fresh data snapshot — before a schema change, before a risky migration, or just as a periodic backup — the process looked like:

SSH into the droplet
cd into the project directory
Run dumpdata inside the Django container
Copy the resulting file out of the container
scp it down to my local machine
Manually upload it to S3 for offsite storage

Six steps, every time. That's the kind of manual toil that either doesn't happen often enough, or happens with copy-paste mistakes.

Step 1: Get `dumpdata` Right

The naive manage.py dumpdata > data.json works, but it dumps everything — including tables that don't need to be in a portable fixture and will actively cause problems if you ever loaddata this into a different environment:

python manage.py dumpdata \
  --natural-foreign --natural-primary \
  --exclude auth.permission \
  --exclude contenttypes \
  --exclude admin.logentry \
  --exclude sessions.session \
  --indent 2 \
  -o data.json

Why these flags matter:

--natural-foreign --natural-primary — replaces hardcoded primary keys with natural lookups where possible. Without this, reloading the fixture into an environment with different PK sequences (a fresh DB, a staging environment) can silently corrupt relationships.
Excluding contenttypes, auth.permission, admin.logentry, sessions.session — these are either auto-regenerated by Django on any fresh install or pure operational noise. Including them bloats the dump and can cause loaddata conflicts if content types are ever re-registered in a different order.
--indent 2 — makes the output diffable in git if you're versioning snapshots, instead of one giant unreadable line.

Step 2: Run It Inside Docker Correctly

If your project is containerized, the command has to run inside the django service, not on the host:

docker compose -f docker-compose.production.yml exec -T django python manage.py dumpdata \
  --natural-foreign --natural-primary \
  --exclude auth.permission \
  --exclude contenttypes \
  --exclude admin.logentry \
  --exclude sessions.session \
  --indent 2 > data.json

Two details that will bite you if skipped:

The -T flag disables TTY allocation. Without it, exec allocates a pseudo-terminal by default. Run this over a scripted or piped SSH session and you risk carriage returns (\r\n) getting injected into your output, silently corrupting the JSON. Always pass -T for non-interactive dumps.

Redirect happens on the right side of the pipe. Since docker compose exec streams its own stdout, running this directly on the host (or via ssh host "command") means the > redirect captures cleanly outsid# Automating Django dumpdata Backups to S3 (One Command, Zero SSH)

The Problem

SSH into the droplet
cd into the project directory
Run dumpdata inside the Django container
Copy the resulting file out of the container
scp it down to my local machine
Manually upload it to S3 for offsite storage

Six steps, every time. That's the kind of manual toil that either doesn't happen often enough, or happens with copy-paste mistakes.

Step 1: Get `dumpdata` Right

python manage.py dumpdata \
  --natural-foreign --natural-primary \
  --exclude auth.permission \
  --exclude contenttypes \
  --exclude admin.logentry \
  --exclude sessions.session \
  --indent 2 \
  -o data.json

Why these flags matter:

--natural-foreign --natural-primary — replaces hardcoded primary keys with natural lookups where possible. Without this, reloading the fixture into an environment with different PK sequences (a fresh DB, a staging environment) can silently corrupt relationships.
Excluding contenttypes, auth.permission, admin.logentry, sessions.session — these are either auto-regenerated by Django on any fresh install or pure operational noise. Including them bloats the dump and can cause loaddata conflicts if content types are ever re-registered in a different order.
--indent 2 — makes the output diffable in git if you're versioning snapshots, instead of one giant unreadable line.

Step 2: Run It Inside Docker Correctly

If your project is containerized, the command has to run inside the django service, not on the host:

docker compose -f docker-compose.production.yml exec -T django python manage.py dumpdata \
  --natural-foreign --natural-primary \
  --exclude auth.permission \
  --exclude contenttypes \
  --exclude admin.logentry \
  --exclude sessions.session \
  --indent 2 > data.json

Two details that will bite you if skipped:

Redirect happens on the right side of the pipe. Since docker compose exec streams its own stdout, running this directly on the host (or via ssh host "command") means the > redirect captures cleanly outside the container — no separate docker compose cp step needed, unlike if you'd used -o data.json inside the container itself.

Step 3: Collapse the Whole Thing Into One Alias

Here's the full pipeline — SSH in, dump, and stream the result straight to a local file — as a single shell alias:

alias dumpdata='ssh username@your-droplet-ip "cd ~/root/project && docker compose -f docker-compose.production.yml exec -T django python manage.py dumpdata --natural-foreign --natural-primary --exclude auth.permission --exclude contenttypes --exclude admin.logentry --exclude sessions.session --indent 2" > ~/Downloads/data.json'

Run dumpdata from your local machine, and the entire remote pipeline executes and lands a clean data.json in your Downloads folder. No manual SSH session, no intermediate files left behind on the server.

Step 4: Ship It to S3

With AWS CLI configured (aws configure, or a named profile if you juggle multiple client accounts):

aws s3 cp ~/Downloads/data.json s3://your-bucket/backups/data-$(date +%Y%m%d-%H%M%S).json

The timestamped key matters — without it, every backup silently overwrites the last one, and you lose the ability to roll back to an earlier snapshot.

If credentials aren't configured yet, aws s3 cp fails with Unable to locate credentials. Fix it with:

aws configure --profile your-profile

Using a named profile instead of the default is worth the extra keystroke if you handle backups for multiple clients or projects — it keeps credential scope explicit instead of relying on whatever happens to be the account's default.

The One-Liner, Fully Chained

alias dumpdata='ssh username@your-droplet-ip "cd ~/root/project && docker compose -f docker-compose.production.yml exec -T django python manage.py dumpdata --natural-foreign --natural-primary --exclude auth.permission --exclude contenttypes --exclude admin.logentry --exclude sessions.session --indent 2" > ~/Downloads/data.json && aws s3 cp ~/Downloads/data.json "s3://your-bucket/backups/data-$(date +%Y%m%d-%H%M%S).json" --profile your-profile'

One command. Dumps remotely, pulls locally, uploads to S3 with a timestamped key.

Where I'd Take It Next

An alias is fine for on-demand backups, but it has no failure handling — if the SSH connection drops mid-stream, or the dump comes back empty, you'll happily upload a corrupted or zero-byte file to S3 without noticing. The next iteration I'm planning is a small bash script with set -euo pipefail, a file-size sanity check before the S3 upload, and eventually a cron job on the droplet itself so backups happen on a schedule without me remembering to run anything at all.

*Originally documented as part of ongoing DevOps work on the ICVN Tech Studio portfolio infrastructure (cookiecutter-django on DigitalOcean, Cloudflare-fronted).*e the container — no separate docker compose cp step needed, unlike if you'd used -o data.json inside the container itself.

Step 3: Collapse the Whole Thing Into One Alias

Here's the full pipeline — SSH in, dump, and stream the result straight to a local file — as a single shell alias:

alias dumpdata='ssh username@your-droplet-ip "cd ~/root/project && docker compose -f docker-compose.production.yml exec -T django python manage.py dumpdata --natural-foreign --natural-primary --exclude auth.permission --exclude contenttypes --exclude admin.logentry --exclude sessions.session --indent 2" > ~/Downloads/data.json'

Step 4: Ship It to S3

With AWS CLI configured (aws configure, or a named profile if you juggle multiple client accounts):

aws s3 cp ~/Downloads/data.json s3://your-bucket/backups/data-$(date +%Y%m%d-%H%M%S).json

The timestamped key matters — without it, every backup silently overwrites the last one, and you lose the ability to roll back to an earlier snapshot.

If credentials aren't configured yet, aws s3 cp fails with Unable to locate credentials. Fix it with:

aws configure --profile your-profile

The One-Liner, Fully Chained

alias dumpdata='ssh username@your-droplet-ip "cd ~/root/project && docker compose -f docker-compose.production.yml exec -T django python manage.py dumpdata --natural-foreign --natural-primary --exclude auth.permission --exclude contenttypes --exclude admin.logentry --exclude sessions.session --indent 2" > ~/Downloads/data.json && aws s3 cp ~/Downloads/data.json "s3://your-bucket/backups/data-$(date +%Y%m%d-%H%M%S).json" --profile your-profile'

One command. Dumps remotely, pulls locally, uploads to S3 with a timestamped key.

Where I'd Take It Next

Originally documented as part of ongoing DevOps work on the ICVN Tech Studio portfolio infrastructure (cookiecutter-django on DigitalOcean, Cloudflare-fronted).

Building a Plugin-Free Newsletter Popup on WordPress: Custom REST Endpoint Mailchimp API v3

Vicente G. Reyes — Tue, 07 Jul 2026 01:27:45 +0000

Building a Plugin-Free Newsletter Popup on WordPress: Custom REST Endpoint → Mailchimp API v3

A client wanted a newsletter popup on their WooCommerce/Divi site to hand out a lead-magnet PDF and grow their Mailchimp audience. The obvious paths — a popup plugin, or Mailchimp's own hosted popup — both lose on the things I actually care about: page weight, brand control, and not loading someone else's JavaScript on every pageview.

So I built it as a custom component: a modal that posts to my own WordPress REST endpoint, which talks to Mailchimp server-side. No plugin, no Mailchimp front-end script, no reCAPTCHA. Here's the whole thing, including a CSS bug that cost me ten confusing minutes.

Why not a plugin or the native Mailchimp popup

Three reasons I don't reach for either on a performance-sensitive site:

The hosted Mailchimp popup injects their JS and styles into every page. On a site already fighting for Core Web Vitals under Divi, that's one more render-blocking dependency and an off-brand UI I can't fully control.
Popup plugins carry the same weight problem plus a settings surface, update cadence, and attack surface I don't need for what is, fundamentally, one form and one API call.
I was going to own the API integration regardless — the site's footer signup wants the same endpoint eventually. Build it once, reuse it. The tradeoff is that you write the code. For a single form talking to a well-documented API, that's a few hours, and you get exactly the component you want.

Architecture

Three moving parts:

A REST endpoint (namespace/v1/subscribe) registered in the theme. It receives the email, validates it, and does the Mailchimp call server-side so the API key never touches the browser.
A modal rendered once in wp_footer, gated by page conditionals, with the API key handed to the front end as nothing — only the endpoint URL and a nonce.
A small vanilla-JS controller for triggers, the frequency cap, and the fetch. Everything lives in the child theme. No mu-plugin, no external assets beyond one CSS and one JS file.

The server side: a REST endpoint that owns the Mailchimp call

The key architectural decision: the browser never sees the API key. The front end posts an email to your endpoint; your endpoint authenticates to Mailchimp. This is the whole reason not to use Mailchimp's client-side embed.

Register the route and read your credentials from wp-config.php constants (never hard-code them in theme files that live in version control or the DB):

add_action( 'rest_api_init', function () {
    register_rest_route( 'namespace/v1', '/subscribe', array(
        'methods'             => 'POST',
        'permission_callback' => '__return_true', // public; guarded by nonce + honeypot
        'args' => array(
            'email' => array(
                'required'          => true,
                'sanitize_callback' => 'sanitize_email',
                'validate_callback' => 'is_email',
            ),
            'hp' => array( 'sanitize_callback' => 'sanitize_text_field' ),
        ),
        'callback' => 'np_subscribe',
    ) );
} );

The Mailchimp v3 subscribe is an upsert: PUT /lists/{list_id}/members/{subscriber_hash}, where the hash is the MD5 of the lowercased email. Using PUT (not POST) means re-submits don't error — they update the existing member instead of throwing "already subscribed."

function np_subscribe( WP_REST_Request $req ) {
    // Honeypot: any value means bot. Fake a success so it doesn't retry.
    if ( ! empty( $req->get_param( 'hp' ) ) ) {
        return new WP_REST_Response( array( 'ok' => true ), 200 );
    }

    if ( ! defined( 'MC_API_KEY' ) || ! defined( 'MC_SERVER' ) || ! defined( 'MC_LIST_ID' ) ) {
        return new WP_REST_Response(
            array( 'ok' => false, 'message' => 'Newsletter is not configured yet.' ),
            503
        );
    }

    $email  = sanitize_email( $req->get_param( 'email' ) );
    $hash   = md5( strtolower( $email ) );
    $auth   = 'Basic ' . base64_encode( 'user:' . MC_API_KEY );
    $status = 'subscribed'; // or 'pending' for double opt-in — see below

    $res = wp_remote_request(
        "https://" . MC_SERVER . ".api.mailchimp.com/3.0/lists/" . MC_LIST_ID . "/members/{$hash}",
        array(
            'method'  => 'PUT',
            'timeout' => 15,
            'headers' => array(
                'Authorization' => $auth,
                'Content-Type'  => 'application/json',
            ),
            'body' => wp_json_encode( array(
                'email_address' => $email,
                'status_if_new' => $status,
            ) ),
        )
    );

    if ( is_wp_error( $res ) ) {
        return new WP_REST_Response( array( 'ok' => false, 'message' => 'Try again shortly.' ), 502 );
    }

    $code = wp_remote_retrieve_response_code( $res );
    if ( $code >= 400 ) {
        // Log the real Mailchimp reason server-side; keep the user message clean.
        error_log( 'Mailchimp ' . $code . ': ' . wp_remote_retrieve_body( $res ) );
        return new WP_REST_Response( array( 'ok' => false, 'message' => 'Couldn\'t add you right now.' ), 502 );
    }

    // Tag for segmentation — fire-and-forget, don't block success on it.
    wp_remote_post(
        "https://" . MC_SERVER . ".api.mailchimp.com/3.0/lists/" . MC_LIST_ID . "/members/{$hash}/tags",
        array(
            'timeout' => 10,
            'headers' => array( 'Authorization' => $auth, 'Content-Type' => 'application/json' ),
            'body'    => wp_json_encode( array(
                'tags' => array( array( 'name' => 'homepage-popup', 'status' => 'active' ) ),
            ) ),
        )
    );

    return new WP_REST_Response( array( 'ok' => true ), 200 );
}

Two details worth calling out:

base64_encode('user:' . $key) — Mailchimp uses HTTP Basic auth where the username is literally any string and the password is the API key.
The server prefix (us8, us21, etc.) is the suffix on your API key after the dash, and it's part of the API host. Store it as its own constant so the base URL is composed, not hard-coded. The tag call is deliberately fire-and-forget. If tagging fails, the subscribe already succeeded — I don't want to fail the user's request over a segmentation nicety. Log it and move on.

Single vs double opt-in changes more than a status string

This is the detail that bites people. Mailchimp audiences are configured for single or double opt-in, and your status_if_new has to match:

Double opt-in → send status: pending. Mailchimp emails a confirmation link; the member isn't subscribed until they click. If you send pending on a single-opt-in audience, you strand contacts in limbo — no confirmation email is sent, so they sit pending forever.
Single opt-in → send status: subscribed. They're live immediately.
But it's not just the API value — it changes your success copy. My first success message said "check your inbox to confirm." On a single-opt-in audience, no confirmation email exists, so that copy is a lie. Match the message to the mode:
Double: "Almost there — confirm via the email we just sent."
Single: "You're on the list. Grab your guide below."
Check the audience setting before you write a single line of success-state copy. Single opt-in trades a confirmation step for higher capture at the cost of more typo/bot noise in your list — which is exactly why the next section matters.

Anti-spam: a honeypot, not reCAPTCHA

For a plain email capture, reCAPTCHA is the wrong tool. It adds a third-party script (CWV hit), a privacy footprint, and occasional user friction — all to guard a single input. A honeypot catches the bots that matter here with zero weight and zero UX cost.

Add a field that's invisible to humans and irresistible to naive bots:

<input class="np-hp" type="text" tabindex="-1" autocomplete="off"
       aria-hidden="true" data-np-hp>

.np-hp {
    position: absolute !important;
    left: -9999px !important;
    width: 1px; height: 1px;
    opacity: 0;
}

If it comes back filled, it's a bot — return a fake 200 so it doesn't retry against a real error path. Real users never see or touch it. tabindex="-1" and aria-hidden keep it out of keyboard and screen-reader flow.

This won't stop a determined targeted attack, but for newsletter spam it filters the overwhelming majority with none of reCAPTCHA's costs. If abuse ever escalates, you add rate-limiting server-side before you reach for a CAPTCHA.

The front end: triggers and a frequency cap

The modal renders once in wp_footer, gated to the surfaces that should show it and never to logged-in users:

function np_should_render() {
    if ( is_user_logged_in() ) return false; // members don't need the lead magnet
    return is_front_page() || is_home() || is_singular( 'post' );
}

The JS fires on whichever trigger hits first: exit-intent, scroll depth, or a time fallback. Exit-intent converts best and annoys least; the timer is just a ceiling.

var timer = setTimeout(open, cfg.delayMs);          // e.g. 15000
document.addEventListener('mouseout', function (e) {  // exit-intent
    if (e.clientY <= 0) open();
});
window.addEventListener('scroll', function () {       // scroll depth
    var h = document.documentElement;
    if ((h.scrollTop) / (h.scrollHeight - h.clientHeight) * 100 >= cfg.scrollPct) open();
}, { passive: true });

The frequency cap uses localStorage — once someone sees or submits, don't show it again for N days:

var CAP_MS = cfg.capDays * 864e5;
function recentlySeen() {
    try {
        var t = parseInt(localStorage.getItem('np_seen'), 10);
        return t && (Date.now() - t) < CAP_MS;
    } catch (e) { return false; }
}

Wrap storage access in try/catch — private-mode and storage-disabled browsers throw, and a newsletter popup should never take down the page.

Mobile: dodge the intrusive-interstitial penalty

Google penalizes intrusive interstitials on mobile that block content on load. A full-screen modal that fires immediately is exactly what they target. Two mitigations:

Don't fire instantly — the delay/scroll/exit triggers already push the popup past the initial load.
On mobile, render a bottom sheet, not a full-screen takeover. It's dismissible, doesn't obscure the whole viewport, and reads as a native mobile pattern.

@media (max-width: 600px) {
    .np { align-items: flex-end; padding: 0; }
    .np__card {
        max-width: 100%;
        max-height: 92vh;      /* never taller than the viewport */
        overflow-y: auto;      /* scroll instead of clipping the CTA */
        border-radius: 12px 12px 0 0;
    }
}

I also dropped the guide-cover image entirely on mobile. In a bottom sheet it fought for vertical space it didn't earn, and a text-only sheet converts fine. Desktop keeps the two-column layout with the cover.

The bug that made it look broken: `[hidden]` vs `display`

Here's the one that cost me. On submit, the controller hides the form view and shows the success view:

root.querySelector('[data-np-view="form"]').hidden = true;
root.querySelector('[data-np-view="success"]').hidden = false;

After wiring everything up, submitting showed the success message and the form at the same time, with the button stuck on "Sending…". The API had returned 200 — the integration was fine. The bug was pure CSS.

The form view was a two-column flex container:

.np__body--split { display: flex; }

The hidden attribute works by applying display: none — but at the user-agent stylesheet's specificity, which is effectively zero. My .np__body--split { display: flex } rule outranks it. So setting .hidden = true added the attribute, but display: flex kept winning and the element stayed visible.

The fix is a one-liner that lets [hidden] beat the flex rule:

.np__body--split[hidden] { display: none; }

The lesson: any time you set an explicit display on an element you also toggle with the hidden attribute (or a hidden class), you have to re-assert display: none at matching-or-higher specificity. This is a silent, common trap with flex/grid components that get shown and hidden in JS.

Deploy notes

A few things specific to shipping this on managed WordPress hosting:

File-only deploys. The popup is entirely code + one image asset — no database rows. So promotion from staging to production is a file push plus two hand-edits (functions.php include line, wp-config.php constants). Never push the staging DB for a change like this; you'll clobber live orders and comments.
Config per environment. The Mailchimp constants live in each environment's wp-config.php separately. They don't ride along on a file push, and that's correct — you may point staging at a test audience.
Purge the cache. The modal markup is in wp_footer, so a full-page cache (Varnish/Breeze/Cloudflare) will serve a stale page without it. Purge after deploy and test in a private window.

Takeaways
Keep the API key server-side. A custom REST endpoint is a few lines more than the hosted embed and removes an entire class of exposure and page-weight problems.
Match status_if_new to the audience's opt-in mode — and match your success copy to it too.
Honeypot over reCAPTCHA for simple captures. Add rate-limiting before you ever add a CAPTCHA.
[hidden] loses to any explicit display. Re-assert display: none on the hidden state of flex/grid components.
Design mobile as a bottom sheet to stay clear of Google's interstitial penalty.
The whole thing is one PHP file, one CSS file, and one JS file in the child theme. No plugin, no third-party script, full brand control — and the data lands in the same Mailchimp audience it would have anyway.

Building a Search Modal for a Membership-Gated WordPress Site

Vicente G. Reyes — Thu, 02 Jul 2026 02:36:34 +0000

Most "add search to WordPress" tutorials stop at dropping a widget in the header. That's fine until the site has gated content — membership videos, paid courses — and you realize the default search will happily leak the titles of member-only material to logged-out visitors. That's the interesting part of this build, and the part the tutorials skip.

This is a walkthrough of a live search feature I built for a fitness-membership platform running WordPress, WooCommerce, Divi, LearnDash, and WishList Member. The stack matters, because every one of those plugins had an opinion about how search should behave. The final result: an icon-triggered modal with debounced live results, grouped by content type, access-aware, styled to the brand, and working on mobile.

The shape of the problem

The site had four distinct content types worth searching, each with different access rules:

Blog posts — public
On-Demand videos — membership-gated
Courses and lessons — gated via LearnDash + WishList Member
Store products — public WooCommerce

So the real architectural decision wasn't the UI. It was whether to run one unified index with access-aware filtering, or scope search per content type. I went with unified, enforcing gating at query time so a logged-out user never sees the title or excerpt of member-only content bleeding through results. That single decision drove most of the backend design.

The UI decision was quicker. The navbar was already dense, so an inline expanding input would have felt cramped at the breakpoint where the menu collapses. An icon that opens a full-screen overlay with live results sidesteps the space problem entirely and reads as more polished.

The backend: one REST endpoint

Everything runs through a single custom REST route. This lives in the child theme's functions.php — deliberately not in a snippets plugin, because search is a hot path and shouldn't depend on a plugin's eval loader staying healthy.

add_action('rest_api_init', function () {
    register_rest_route('rev6/v1', '/search', [
        'methods'             => 'GET',
        'permission_callback' => '__return_true',
        'args' => [
            's' => ['sanitize_callback' => 'sanitize_text_field', 'required' => true],
        ],
        'callback' => function (WP_REST_Request $req) {
            $term = $req->get_param('s');
            if (mb_strlen($term) < 2) return rest_ensure_response([]);

            $args = [
                's'              => $term,
                'post_type'      => ['post', 'product', 'sfwd-courses'],
                'posts_per_page' => 8,
                'no_found_rows'  => true,
            ];

            if (function_exists('relevanssi_do_query')) {
                $args['relevanssi'] = true;
                $q = new WP_Query($args);
                relevanssi_do_query($q);
            } else {
                $q = new WP_Query($args); // fallback: core search
            }

            $out = array_map(fn($p) => [
                'title' => get_the_title($p),
                'url'   => get_permalink($p),
                'type'  => get_post_type($p),
                'thumb' => get_the_post_thumbnail_url($p, 'thumbnail'),
            ], $q->posts);

            return rest_ensure_response($out);
        },
    ]);
});

The function_exists('relevanssi_do_query') guard is doing more than it looks. Relevanssi is the search plugin that replaces WordPress's weak default search with a proper relevance-ranked index that respects membership access. But wrapping the call in a capability check means the feature degrades gracefully to core WP search if the plugin is inactive, missing, or not yet loaded in a given request context. During the build, an unguarded relevanssi_do_query() call was fataling the endpoint with a white screen — the guard turns that into a working (if less clever) fallback instead of a broken site.

That's the general principle: a search endpoint should never be able to take down the page. Degrade, don't die.

The access-leak problem

Here's the part worth dwelling on. Relevanssi indexes what you tell it to, and by default it will index gated content and return it in results. On a membership site, that means a logged-out visitor searching for a topic covered only in a paid course sees that course's title and excerpt in the results. That's a content leak — you're advertising exactly what's behind the paywall, with the specifics.

The fix is enforced server-side, in two layers:

Configure Relevanssi's index so protected post types respect the membership plugin's visibility rules.
Where the plugin's filtering isn't clean, add a relevanssi_post_ok filter to drop posts the current user can't access before they ever reach the response.

The critical rule: never filter this in JavaScript. The overlay hiding a result client-side means the data already left the server — it's in the network response, visible to anyone who opens devtools. Access control that lives in the frontend isn't access control. It has to happen before rest_ensure_response.

This also interacts with caching, which I'll come back to.

The frontend: debounced, aborted, escaped

The client is vanilla JS — no framework needed for this. It's enqueued from the child theme with the endpoint URL localized in, rather than hardcoded, so it survives sites where the REST root isn't at the default path.

let ctrl;
const search = debounce(async (term) => {
  if (term.length < 2) return (results.innerHTML = '');
  ctrl?.abort(); ctrl = new AbortController();
  results.innerHTML = '<div class="rev6-loading"><span class="rev6-spinner"></span>Searching…</div>';
  try {
    const res = await fetch(`${REV6_SEARCH.endpoint}?s=${encodeURIComponent(term)}`,
      { signal: ctrl.signal });
    render(await res.json());
  } catch (e) {
    if (e.name !== 'AbortError') {
      console.error(e);
      results.innerHTML = '<p class="rev6-empty">Something went wrong. Try again.</p>';
    }
  }
}, 250);

Three things are load-bearing here:

Debounce (250ms). Without it, every keystroke fires a request. On a slow query that's a pile-up of in-flight fetches racing each other.

AbortController. When the user keeps typing, the previous request is cancelled. This prevents the classic race where an earlier, slower query resolves after a later one and overwrites the correct results with stale ones. The if (e.name !== 'AbortError') check keeps those intentional cancellations out of the error path.

Explicit error state. A failed fetch used to leave the spinner spinning forever. On a search that can take a couple of seconds, timeouts and dropped requests are likely enough that silent failure is a real UX hole. Now it shows a message and stops.

The render step groups results by content type so "Articles / Store / Courses" read as sections rather than a flat, confusing list. And the titles get escaped before injection:

const escapeHtml = s => s.replace(/[&<>"']/g, c =>
  ({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[c]));

This is not optional. The response strings go into innerHTML, so an unescaped post titled with an <img onerror=...> payload would be stored XSS. Escape anything from the API before it touches the DOM as HTML.

The loading state, and the thing it was hiding

Adding a spinner was a requested UX fix — the modal sat blank for a beat on slower queries and read as broken. But a spinner treats the symptom. The real question was why the query took seconds.

A properly indexed Relevanssi query across a few post types should return in well under 200ms. Multi-second responses almost always mean one of:

The index needs rebuilding — a stale or partial index is the number-one cause.
The query is silently falling through to the core WP fallback, which does an unindexed LIKE across the post table. On a large table, that genuinely is slow.

So the spinner shipped, but the actual fix was confirming Relevanssi was active and its index freshly built. Worth checking the endpoint's response time in the network tab before accepting "a bit slow" as normal — the spinner should be covering a 150ms gap, not a 3-second one.

Caching: the membership leak, again

The site sits behind a Varnish + page-cache stack. This creates a subtle and serious failure mode: if the search endpoint gets cached, one user's access-filtered results can be served to a different user. A logged-in member's search, cached, then served to a logged-out visitor — leaking exactly the gated content the server-side filtering was designed to protect.

The fix is to exclude the REST route from the page cache entirely. The access filtering only works if every request is evaluated fresh against the current user. This is the same leak from the backend section, wearing a different hat — and it's why the whole "never trust the client, evaluate server-side" principle has to extend to the cache layer too.

Mobile, and a lesson about fighting the theme

Desktop was straightforward. Mobile was a grind, and the lesson is more useful than the code.

The trigger started life injected into the nav menu via wp_nav_menu_items. On desktop, fine. But when Divi collapsed the menu into a hamburger, the injected button got swallowed into the dropdown and — worse — became unclickable. Divi binds its own touch handlers to the collapsed menu items, and they intercepted the tap before the button's handler could run. I tried stopPropagation, z-index bumps, scoped CSS. Each one was a patch on a symptom.

The actual fix was to stop fighting the theme's menu. Instead of living inside the hamburger, the mobile trigger gets injected as a standalone icon in the header, outside the menu entirely:

function mountMobileTrigger() {
  if (document.querySelector('#rev6-search-mobile')) return;
  const header =
    document.querySelector('#main-header .container') ||
    document.querySelector('#main-header') ||
    document.querySelector('.et-l--header .container') ||
    document.querySelector('header');
  if (!header) { console.warn('[search] header not found'); return; }
  const btn = document.createElement('button');
  btn.id = 'rev6-search-mobile';
  btn.setAttribute('aria-label', 'Search');
  btn.innerHTML = '<svg viewBox="0 0 24 24" width="22" height="22" ...></svg>';
  btn.addEventListener('click', openOverlay);
  header.appendChild(btn);
}

Because it's no longer a child of the menu, none of Divi's collapsed-menu handlers can eat the tap. It also fixed the real UX problem — search was one tap from any page instead of buried at the bottom of an expanded menu.

The general takeaway: when a page builder's component keeps resisting your changes, the move is usually to stop modifying its component and place your own element beside it, not inside it. Chained patches against a theme's behavior are a signal you're solving the problem at the wrong layer.

A couple of smaller mobile details that mattered: the input font-size is set to 16px, because anything smaller triggers iOS Safari's auto-zoom on focus. And the modal is a contained card with side margins and a capped height rather than a full-bleed sheet — a preference call, but it reads as a modal rather than a takeover.

What I'd tell someone building this

Decide your gated-content policy first. Fully invisible to non-members, or visible-but-locked? That one answer drives the entire index configuration. Everything else is downstream of it.
Access control is server-side or it doesn't exist. Filter before the response, exclude the endpoint from cache, and never rely on the UI to hide anything sensitive.
Make search un-crashable. Guard optional dependencies, fall back to core, and give it an explicit error state.
Debounce and abort. They're four lines that eliminate whole categories of race conditions and wasted requests.
Escape everything from the API. innerHTML plus unescaped strings is stored XSS waiting to happen.
Stop fighting the page builder. If you're on your third patch against a theme's component, put your element next to it instead of inside it.

The feature itself is small — an icon, an overlay, an endpoint. But most of the engineering was in the parts you can't see: the access filtering, the cache exclusion, the race handling, the graceful degradation. That's usually where the real work is.

The Paywall That Wasn't: Debugging a 919-Video Leak on WordPress

Vicente G. Reyes — Tue, 30 Jun 2026 07:31:56 +0000

The ticket was three sentences long: "Some paid members can't play the on-demand videos. They log in, click a video, and still get told they need a membership. Can you fix it tonight?"

I fixed it tonight. But the bug I was asked to fix turned out to be the smaller of two problems sitting on the same page — and the bigger one was that the paywall wasn't protecting anything at all.

This is a write-up of how a routine "members can't log in" ticket unravelled into a full rebuild of the access layer on a WordPress / WooCommerce / WishList Member / Vimeo stack, and the handful of debugging lessons that fell out of it.

The stack

The site is a fitness membership platform. The relevant pieces:

WordPress + Divi (child theme, Theme Builder for templates)
WooCommerce Subscriptions for billing — this is where members actually pay
WishList Member for membership levels and content protection
All-in-One Video Gallery (AIOVG) for the on-demand library — videos live in a custom post type, aiovg_videos, with their own taxonomy
Vimeo for the actual video hosting (private embeds)
Cloudways / DigitalOcean with Varnish full-page cache
Code Snippets for small PHP additions

Nine hundred and nineteen videos. Hold that number; it matters later.

Symptom one: the reported bug

The complaint was straightforward to reproduce. Log in as a real paying member, navigate to a video, and the page shows:

You must have a Membership to access this video.

Annoying, but it reads like a simple access-check bug. My first instinct was the membership level. The site had recently renamed a membership tier, and that's a classic trap: WishList Member level IDs are stable across renames, but level names are not. Any code or protection rule that matches a level by name silently breaks the moment someone renames it in the admin.

So the working theory was: the video gate checks for a level by name, the name changed, every member now fails the check. Reasonable. Wrong, as it turned out — but reasonable.

Symptom two: the bug nobody reported

Before writing a fix, I checked the obvious counterfactual: what does a non-member see? I opened the same video in an incognito window, fully logged out.

The "you must have a membership" notice showed up — and then the video played anyway.

That reframed everything. The two symptoms were:

Logged-in members saw the membership notice (the reported bug).
Logged-out visitors also saw the notice — but the player rendered and played regardless (the unreported bug).

Scrolling down on the member's page confirmed it: the "paywall" was a block of text sitting above a video that rendered unconditionally for everyone. It wasn't a gate. It was a sign that said "members only" taped to an unlocked door.

The real situation: all 919 videos were publicly accessible. Anyone with a link could watch the entire paid library, logged in or not. The membership notice was decorative, and its own broken logic happened to display it to members too — which is the only reason anyone noticed something was wrong.

This is the first lesson, and it's the one I keep relearning:

Always check the inverse of the reported symptom. "Members are blocked" and "non-members get in" can be the same root cause wearing two masks. The reported half is rarely the dangerous half.

Why it was wide open

The videos are an AIOVG custom post type. WishList Member's content protection was configured on the parent On-Demand page, with "automatically apply protection to child content" enabled.

But WLM's cascade follows the WordPress page/post hierarchy. The AIOVG videos are a separate custom post type — not children of that page in any way WLM understands. So the cascade never reached them. The parent page looked protected in the admin; the 919 videos under it were never touched.

Two systems, each assuming the other had it handled, and the content fell through the gap between them.

The fix: one gate, server-side, before render

The instinct with a Divi site is to reach for the template and conditionally hide the player. Don't. Hiding markup client-side still ships the source URL in the response — the player's gone visually, the video link isn't. And template-level conditionals are fragile across the half-dozen ways a CPT can get rendered (archive autoplay, shortcodes, REST).

The correct interception point is template_redirect, early, before AIOVG or Divi build anything. If the visitor isn't entitled, you redirect and exit — the player HTML never enters the response at all.

add_action( 'template_redirect', function () {
    if ( ! is_singular( 'aiovg_videos' ) ) {
        return;
    }
    $uid = get_current_user_id();

    if ( $uid && user_can( $uid, 'manage_options' ) ) {
        return; // admins always pass
    }

    $can_view = $uid
        && function_exists( 'wcs_user_has_subscription' )
        && wcs_user_has_subscription( $uid, '', 'active' );

    if ( $can_view ) {
        return;
    }

    if ( is_user_logged_in() ) {
        wp_safe_redirect( home_url( '/membership/' ) ); // logged in, no sub
    } else {
        wp_safe_redirect( add_query_arg(
            'redirect_to', urlencode( get_permalink() ), home_url( '/login/' )
        ) ); // logged out — return to the video after sign-in
    }
    exit;
}, 1 );

Because the gate keys on the post type (is_singular('aiovg_videos')), it covers all 919 videos at once. New uploads are gated on publish. There's no per-video work, ever.

The decision that fixed the reported bug: stop trusting the level

Notice what the gate checks: wcs_user_has_subscription(), not a WishList Member level.

This is the actual fix for "paid members can't play." The original setup gated on WLM levels, and the allowed-level list didn't include every level paying members were actually on. A member subscribed and paying — but sitting on a level that wasn't in the approved list — got rejected. The rename made it worse, but the deeper problem was architectural:

Your billing truth and your access truth were two different systems. Members pay in WooCommerce. Access was checked in WishList Member. Those only stay in sync if every Woo→WLM hook fires perfectly, forever. They don't.

Gating on the source of truth — does this person have an active subscription? — sidesteps the entire sync problem. It also matched the business rule once I confirmed it with the client: no tier should be blocked from videos. "Has an active subscription" is exactly that rule, expressed in code, and it's immune to level renames because it never looks at levels.

Once the snippet was the sole authority, I disabled WLM's content protection on the video CPT and the On-Demand pages. Two gates fighting each other is how you get a member blocked by one while the other tries to let them in. Pick one source of truth and delete the other.

The 500 that wasn't in the log I was reading

Mid-debugging, the video pages started throwing There has been a critical error on this website — a PHP fatal, while I was logged in as admin.

I pulled the Cloudways logs and found... nothing useful. Pages of the log buffer is full (1024) truncation warnings (cosmetic, caused by my own long admin-search URLs) and directory index forbidden 403s (Googlebot hitting locked directories — security working as intended). Noise.

The lesson here is unglamorous but cost me time:

A "critical error" is a PHP fatal, and PHP fatals go to the PHP error log — not the Nginx access/error log. I was reading the web-server log looking for an application error. Wrong file. WP_DEBUG_LOG writing to wp-content/debug.log is the fast path to the actual fatal line.

The fatal was a WishList Member function that existed (so my function_exists() guard passed) but threw when invoked on that version. The clean resolution was to remove the WLM call from the gate entirely — which I wanted to do anyway, since I'd already moved access onto WooCommerce. The fatal disappeared because the code that could fatal was gone, not because I patched around it.

The edge cases that "done" hid

With the gate live and three test accounts passing (admin, a paying member, a logged-out visitor correctly bounced), it looked finished. It wasn't. The membership model had more shape than the ticket implied, and each wrinkle was a chance to wrongly lock out a paying customer.

Multiple subscription tiers, one rule. All-Access, On-Demand, and Vitality Individual are all WooCommerce subscriptions. Gating on "any active subscription" covered all three without enumerating them — which is the point of gating on the source of truth rather than a list you have to maintain.
A legacy label. A member on an old "Gold Membership" level got redirected. The client clarified that "Gold" was simply the old name for the All-Access membership — these are current, paying members. The redirect was a bug, not correct behavior.
A non-"active" status. When I checked that member in WooCommerce → Subscriptions, the subscription existed but its status was on-hold (a failed or retrying payment), not active. My gate counted only active, so it bounced her. Given the client's explicit priority — "first make sure members have access, then worry about locking others out" — I widened the accepted statuses to include on-hold and pending-cancel, the grace-period states where someone is reasonably still a paying member:

$can_view =
       wcs_user_has_subscription( $uid, '', 'active' )
    || wcs_user_has_subscription( $uid, '', 'on-hold' )
    || wcs_user_has_subscription( $uid, '', 'pending-cancel' );

That last one is worth flagging as a product decision, not just a code one: including on-hold means a member whose card permanently fails keeps access until the subscription fully cancels. That's a deliberate "members-first" trade, and the kind of thing you surface to the client rather than bury as a silent default.

"It works for my three test accounts" is not "it works." The accounts that break your assumptions are the ones with unusual status, not unusual identity — the on-hold member, the legacy tier, the trialing user. Go find those specifically.

The part the page gate doesn't solve

There's a difference between a UX paywall and a security paywall. The template_redirect gate stops the player from rendering — but it protects the page, not the file. If the underlying video URL is public, a leaked direct link still plays, gate or no gate.

Here the videos are on Vimeo as private embeds, with a privacy hash in the URL. That's meaningfully better than raw public MP4s: the gate already stops non-members from reaching the page and grabbing the link in the first place. To fully close it — so a copied link won't play anywhere else — the remaining step is Vimeo's domain-level privacy: restrict embedding to the site's own domain. Then even a leaked URL refuses to play off-site.

That's a settings change, not a build — but it requires access to the Vimeo account, which is the client's to grant. The honest version of "done" names what's closed and what's pending, rather than letting "the player is hidden" be mistaken for "the content is secure."

What I'd take to the next one

Check the inverse of the reported symptom before writing any fix. The reported half is rarely the dangerous half.
Gate on the source of truth. Bill in one system, check access in that same system. Downstream copies drift.
One gate, not two. Two access systems on the same content will eventually disagree, and the disagreement is always a blocked customer or a leaked file.
Read the right log. PHP fatals are in the PHP log, not the web-server log.
Intercept before render, and exit. Hiding markup isn't protection if the source URL still ships.
Test by status, not by identity. On-hold, legacy, trialing — the weird states are where paying members get wrongly locked out.
Distinguish the UX paywall from the security paywall, and tell the client which one they actually have.

The ticket said "some members can't play videos." What it meant was "our entire paid catalog has been free for anyone with a link, and the only reason we noticed is that the broken sign was also annoying the people who paid." Both true. The second framing is the one worth fixing for.

Rebuilding a Divi Blog with Custom Shortcodes: A Field Report

Vicente G. Reyes — Sat, 20 Jun 2026 02:34:30 +0000

A redesign of the blog list and post detail pages for Rev6, a fitness and wellness platform running WordPress + Divi on Cloudways. This is less a "look at the pretty result" piece and more an honest account of the architecture decisions and the bugs that taught me something — including the one that cost a chunk of a Saturday and had nothing to do with code at all.

The starting point

Rev6's blog needed a full visual and structural overhaul: a proper editorial list page with a category sidebar, sorting, and a card grid, plus a clean reading-focused detail page with an author bar, author bio, and related posts. The site is built on a Divi child theme, so the obvious first question was whether to lean on Divi's built-in Blog module.

I didn't. The Blog module is fine for generic listings, but it falls down on the things this project actually needed: URL-based category routing, custom card markup, and membership-aware post handling. Fighting a page builder to produce non-default markup is a losing game — you end up with a tangle of overrides that breaks on the next Divi update. So the list and detail pages are driven by a small system of custom shortcodes living in the child theme's inc/rev6-blog-functions.php, styled by a single assets/rev6-blog.css, and assembled inside Divi's Theme Builder.

The shortcode system

The whole front end is composed from a handful of focused shortcodes:

[rev6_blog_sidebar] — category navigation, search, branding
[rev6_sort_dropdown] — sort control
[rev6_post_grid] — the card grid
[rev6_author_bar] — byline on the detail page
[rev6_author_bio] — author block at the foot of a post
[rev6_related_posts] — "Keep reading" section

Keeping each piece as its own shortcode means the Theme Builder template is just a thin assembly layer — a Code module with the shortcodes in the order they should render — and all the logic stays in versioned PHP rather than locked inside the page builder's database.

One template for every category

The neat trick on the list side is that a single Theme Builder template serves both the main blog index and every category archive. The post grid reads the query context and filters itself:

$current_id = is_category() ? (int) get_queried_object_id() : null;
// ...
if (is_category()) {
    $args['cat'] = (int) get_queried_object_id();
}

Assign the template to Pages → Blog and Categories → All Category Pages, and the same markup produces the right results everywhere. On the index you get all posts; on /category/longevity/ the grid scopes itself to Longevity. No per-category templates, no duplication.

The editorial layout — and a 27,000-pixel bug

The list page uses a named-area CSS grid: a sticky sidebar spanning the full height, with the sort control, card grid, and pagination stacked in the main column.

.rev6-blog-layout {
    display: grid;
    grid-template-columns: var(--rev6-sidebar-w) 1fr;
    grid-template-rows: auto 1fr auto;
    grid-template-areas:
        "sidebar sort"
        "sidebar grid"
        "sidebar pagination";
    column-gap: var(--rev6-gutter);
    row-gap: 28px;
}

This is the v2.2 layout. v2.1 had a genuinely fun bug. To make the sidebar span the full content height, I'd reached for grid-row: 1 / span 999 — the lazy "just span everything" move. The problem: span 999 doesn't clamp to the number of real rows. It generates ~996 phantom implicit rows below the content, and every one of them inherited the 28px row-gap. The result was roughly 27,888px of dead whitespace hanging below the pagination. The fix was to stop being lazy and define an explicit three-row grid with named areas, letting the sidebar occupy a named region that spans the rows that actually exist. Lesson: span <big number> is a code smell in grid layouts; name your areas.

The detail page

The post detail template is four stacked pieces: the post title, an author bar, the post content (carrying a rev6-single-content class for typography), the author bio, and related posts.

Typography is the usual editorial setup — Roboto Serif headings in a deep blue (#1d5280), a navy body color (#232a43), generous line-height, a constrained measure for readability. The author system is custom: rather than rely on WordPress's native bio field, the theme registers a "Rev6 Author Profile" section on the user edit screen with dedicated Role and bio fields, and the author photo comes from Simple Local Avatars.

The related-posts block is small but worth showing, because it became the centerpiece of a debugging session that had nothing to do with the code:

function rev6_related_posts($atts) {
    $atts = shortcode_atts(['count' => 3], $atts);
    if (!is_single()) return '';
    $cat = rev6_primary_category();
    if (!$cat) return '';
    $q = new WP_Query([
        'post_type'           => 'post',
        'posts_per_page'      => (int) $atts['count'],
        'post_status'         => 'publish',
        'cat'                 => (int) $cat->term_id,
        'post__not_in'        => [get_the_ID()],
        'ignore_sticky_posts' => 1,
        'orderby'             => 'date',
        'order'               => 'DESC',
    ]);
    if (!$q->have_posts()) return '';
    // ...render cards...
}

It pulls up to three posts from the current post's primary category, excluding the current one. Primary category resolution is defensive — it prefers Yoast's designated primary term but falls back gracefully if that term no longer exists:

function rev6_primary_category($post_id = null) {
    $post_id = $post_id ?: get_the_ID();
    if (function_exists('yoast_get_primary_term_id')) {
        $term_id = yoast_get_primary_term_id('category', $post_id);
        if ($term_id) {
            $term = get_term($term_id, 'category');
            if (!is_wp_error($term) && $term) return $term;
        }
    }
    $cats = get_the_category($post_id);
    return !empty($cats) ? $cats[0] : null;
}

The "bug" that wasn't

On the live site, the related-posts section refused to render on the flagship post. The code looked correct. I'd already confirmed the categories existed. So where was the bug?

There wasn't one. The category existed but was empty — the only post assigned to "Longevity" was the very post being viewed. post__not_in excluded it, the query returned zero results, and the function did exactly what it should: returned an empty string. The moment I assigned a second post to the category, "Keep reading" appeared instantly.

This is a recurring trap with content-driven features: the function is correct, the data is incomplete, and the symptom looks like a code failure. Before debugging a query, check whether it has anything to query.

The cutover: code and layout move, content doesn't

The single most expensive lesson came during the staging-to-live migration, and it's the one I'd most want a past version of myself to internalize.

I'd pushed the theme files to live and imported the Divi Theme Builder templates from staging. Everything should have matched. It didn't — the detail page body sat in the wrong place, related posts were missing, the sidebar looked thin. My instinct was to keep editing CSS on live to force a match. That instinct was wrong, and it cost several round-trips.

The actual issue: imports move code and layout. They do not move content.

Theme files (.css, .php) carry presentation and logic.
A Divi Theme Builder export carries template structure — sections, modules, CSS classes.
Neither one carries posts, categories, or which post belongs to which category. Those are database rows.

So a body-width difference between staging and live wasn't a CSS problem at all — the width was set on a Divi module's Design tab, which lives in the database, not the stylesheet. The empty related-posts blocks weren't a code problem — the category-to-post assignments had never been recreated on live. I'd copied the stylesheet byte-for-byte and the two environments still diverged, which is the clearest possible signal that the difference lives somewhere a stylesheet can't reach.

Once you internalize the split — files and templates are the shell; the database is the contents — the whole class of "I imported it but it's different" problems becomes diagnosable in seconds instead of debugged in CSS for an hour.

A corollary, learned the hard way and stated here as a warning: never resolve a staging/live difference with a blanket database push to production. A full DB sync overwrites live's real data — orders, registrations, everything users created since the snapshot. Use targeted file copies and, where data genuinely must move, scoped table-level operations. The convenience of a one-click "push everything" is not worth what it can erase.

Caching will lie to you

One more environmental gremlin worth naming: aggressive CSS optimization. Cloudways' Breeze with "Used CSS" (RUCSS) strips selectors it doesn't detect as used when it generates its optimized stylesheet. If a template wasn't live when the cache was built, perfectly correct rules — list-style: none on pagination, container widths, an icon font — get pruned, and you get partial styling: some rules apply, others vanish. Partial application is the tell. A fully missing stylesheet looks different from a half-applied one.

The fix isn't to touch the CSS; it's to purge and regenerate the Used CSS after any template change, and to exclude the relevant selectors from optimization if they keep getting stripped. When debugging CSS on an optimized WordPress site, clearing cache is step zero, not step ten.

Takeaways

Don't fight the page builder. If you need non-default markup or custom query logic, own it in versioned PHP and let the builder assemble.
Name your grid areas. span 999 will find a way to embarrass you.
A correct function over empty data looks identical to a broken function. Check the data first.
Files and templates are the shell; the database is the contents. Most "I migrated it but it's different" bugs live in the gap between those two.
Never blanket-push a database to production.
On an optimized WordPress stack, purge the cache before you believe anything you see.

The redesign shipped: editorial list page with context-aware category routing, a clean reading-focused detail page, a working author system, and related posts that populate themselves from category data. The code was the easy part. The environment was the teacher.

Meta is down. Are you ok? lol

Vicente G. Reyes — Fri, 12 Jun 2026 14:18:29 +0000

How I Shaved 10 MB Off My Portfolio in One Command

Vicente G. Reyes — Wed, 03 Jun 2026 03:41:29 +0000

PageSpeed Insights had been staring at me for weeks. Desktop was holding at 91. Mobile was stuck at 63. I'd already fixed the obvious stuff — non-blocking fonts, preconnects, fetchpriority on the hero image. But there it was, every single run:

Improve image delivery — Est savings of 985 KiB

Nearly a megabyte of wasted transfer, just from six project screenshots. And that was just the images visible above the fold. The full list across all projects was worse.

The culprit: every image I'd ever uploaded through the Django admin was a PNG. Some of them were over 1 MB. WebP would have cut most of them by 80%. I knew this. I just hadn't done anything about it.

So I wrote a management command to fix the backlog, and then made the model auto-convert on every future upload so I'd never have to think about it again.

The Problem With PNGs in a Portfolio

When you're building a portfolio, you screenshot your work and drag it into the admin. That screenshot is usually a PNG — lossless, full-size, straight from your display. Nobody optimises it because the admin accepts it and it shows up fine in the browser.

But "shows up fine" isn't the same as "loads fast." A 1.4 MB PNG of a law firm homepage does not need to be 1.4 MB. Served as WebP at quality 85, it's 175 KB. Same visual result. Eight times smaller.

Multiply that across 28 projects and you're looking at tens of megabytes that mobile users on slow 4G are downloading just to scroll past thumbnails.

The One-Time Backlog Fix: A Management Command

First, I needed a way to convert everything that was already in S3. A management command was the right tool — it runs in the production container with full access to the Django ORM and the configured storage backend, so it can read and rewrite files without needing to know whether they're on S3, local disk, or anywhere else.

# backend/projects/management/commands/convert_images_to_webp.py

from io import BytesIO

from django.core.files.base import ContentFile
from django.core.management.base import BaseCommand
from PIL import Image

from backend.projects.models import AudioWork, Project


def _to_webp(field_file, quality: int = 85) -> tuple[ContentFile, str] | None:
    try:
        with field_file.open("rb") as f:
            img = Image.open(f)
            img.load()
    except OSError as exc:
        return None, str(exc)

    mode = "RGBA" if img.mode in ("RGBA", "LA", "P") else "RGB"
    img = img.convert(mode)

    buf = BytesIO()
    img.save(buf, format="WEBP", quality=quality, method=6)
    buf.seek(0)

    old_name = field_file.name
    new_name = old_name.rsplit(".", 1)[0] + ".webp"
    return ContentFile(buf.read(), name=new_name), new_name


class Command(BaseCommand):
    help = "Convert project and audio work images stored in S3 to WebP format."

    def add_arguments(self, parser):
        parser.add_argument("--quality", type=int, default=85)
        parser.add_argument("--dry-run", action="store_true")
        parser.add_argument("--skip-existing", action="store_true", default=True)

    def _convert_field(self, obj, field_name, quality, dry_run, skip_existing):
        field = getattr(obj, field_name)
        if not field:
            return "skip-empty"

        name = field.name or ""
        if skip_existing and name.lower().endswith(".webp"):
            return "skip-webp"

        webp_file, new_name = _to_webp(field, quality)
        if webp_file is None:
            self.stderr.write(f"    ERROR: {name}: {new_name}")
            return "error"

        old_size = field.size
        new_size = webp_file.size

        if dry_run:
            savings = old_size - new_size
            self.stdout.write(
                f"    [dry-run] {name} → {new_name} "
                f"({old_size // 1024} KiB → {new_size // 1024} KiB, "
                f"saves {savings // 1024} KiB)"
            )
            return "would-convert"

        field.delete(save=False)
        getattr(obj, field_name).save(new_name.split("/")[-1], webp_file, save=True)
        self.stdout.write(
            self.style.SUCCESS(f"    ✓ {name} → {new_name}")
        )
        return "converted"

    def handle(self, *args, **options):
        quality = options["quality"]
        dry_run = options["dry_run"]
        skip_existing = options["skip_existing"]

        for project in Project.objects.exclude(image="").exclude(image__isnull=True):
            self.stdout.write(f"  {project.title}")
            self._convert_field(project, "image", quality, dry_run, skip_existing)

        for work in AudioWork.objects.exclude(cover_image="").exclude(cover_image__isnull=True):
            self.stdout.write(f"  {work.title}")
            self._convert_field(work, "cover_image", quality, dry_run, skip_existing)

The logic is straightforward: open the file from storage, convert to WebP with Pillow, delete the original, save the new one. The --dry-run flag prints what would happen without touching anything — which I always run first in production.

The Pillow mode handling is worth noting

WebP supports transparency, so if the source image is RGBA (PNG with alpha channel) or has a palette with transparency, I keep it in RGBA mode. Everything else gets converted to RGB first. Trying to save a palette-mode image directly to WebP will throw an error.

mode = "RGBA" if img.mode in ("RGBA", "LA", "P") else "RGB"
img = img.convert(mode)

Running it

# See what will happen without writing anything
docker compose -f docker-compose.production.yml run --rm django \
  python manage.py convert_images_to_webp --dry-run

# Run for real
docker compose -f docker-compose.production.yml run --rm django \
  python manage.py convert_images_to_webp

The dry run output on my portfolio:

Project: Leagogo Law Firm
  [dry-run] projects/LAA_Law.png → projects/LAA_Law.webp (1423 KiB → 175 KiB, saves 1247 KiB)
Project: Flower Head Events
  [dry-run] projects/Flower_Head_Events.png → projects/Flower_Head_Events.webp (1187 KiB → 83 KiB, saves 1103 KiB)
Project: HSM Homes
  [dry-run] projects/HSM_Homes.png → projects/HSM_Homes.webp (1117 KiB → 92 KiB, saves 1024 KiB)
Project: Big Boy Shawarma
  [dry-run] projects/BigBoyShawarma.png → projects/BigBoyShawarma.webp (898 KiB → 43 KiB, saves 855 KiB)
...
Would convert: 30

30 images. Thousands of KiB saved. One command.

The Permanent Fix: Auto-Convert on Upload

The command handles the backlog. But what about the next project I add? I don't want to run the command manually every time I upload a screenshot.

The fix is in the model's save() method. After the original file is written to storage, detect if it needs conversion and replace it in place:

# backend/projects/models.py

from io import BytesIO
from django.core.files.base import ContentFile
from django.db import models
from PIL import Image


def _convert_to_webp(field_file, quality: int = 85) -> ContentFile | None:
    try:
        with field_file.open("rb") as fh:
            img = Image.open(fh)
            img.load()
    except OSError:
        return None

    mode = "RGBA" if img.mode in ("RGBA", "LA", "P") else "RGB"
    img = img.convert(mode)

    buf = BytesIO()
    img.save(buf, format="WEBP", quality=quality, method=6)
    buf.seek(0)

    filename = field_file.name.rsplit("/", 1)[-1].rsplit(".", 1)[0] + ".webp"
    return ContentFile(buf.read(), name=filename)


def _save_as_webp(instance, field_name: str) -> None:
    field = getattr(instance, field_name)
    if not field or str(field.name).lower().endswith(".webp"):
        return
    webp = _convert_to_webp(field)
    if webp is None:
        return
    field.delete(save=False)
    getattr(instance, field_name).save(webp.name, webp, save=True)


class Project(models.Model):
    image = models.ImageField(upload_to="projects/", blank=True, null=True)
    # ... other fields

    def save(self, *args, **kwargs):
        updating_image = not kwargs.get("update_fields") or "image" in (
            kwargs.get("update_fields") or []
        )
        super().save(*args, **kwargs)
        if updating_image:
            _save_as_webp(self, "image")

The important detail: super().save() runs first. That writes the original file to storage. Then _save_as_webp opens it, converts it, deletes the original, and saves the WebP. Yes, this means two writes to S3 per upload — but uploads happen rarely and through the admin, so the overhead is irrelevant. The read path, which runs on every page load, now always gets WebP.

The update_fields check prevents unnecessary conversion when saving unrelated fields. If someone updates just the project title from the admin, the image field is left alone.

The Result

After running the command and deploying the model change:

30 existing images converted from PNG to WebP
Average reduction: ~80% per image
Largest single saving: 1,247 KiB (a 1.4 MB PNG → 175 KB WebP)
PageSpeed Insights no longer flags "Improve image delivery" for S3-hosted images
Every future upload auto-converts — no manual intervention needed

The mobile performance score still has room to improve (the mobile LCP is dominated by React's JS parse time, which is a different problem). But knocking nearly 10 MB of unnecessary image weight off the page is a clean, permanent win.

What I'd Do Differently

If I were starting fresh, I'd use an ImageField subclass that intercepts the file before it's written — cleaner than the post-save dance. But overriding save() is pragmatic and works perfectly fine with Django admin, DRF serializers, and anything else that goes through the ORM.

I'd also consider storing images at display dimensions rather than full screenshot resolution. Even as WebP, a 1137×651 image served at 399×190 is wasting pixels. A future create_thumbnail step alongside the WebP conversion would push things further. That's next.

Building an RSS Feed for a Django + React Portfolio (With a Styled Browser View)

Vicente G. Reyes — Tue, 02 Jun 2026 07:33:42 +0000

RSS isn't dead. Developers still use feed readers, and having a proper /rss.xml or /blog/rss URL is a small but meaningful signal that your site is a real publication. My portfolio runs on a split stack — a React SPA on Vercel and a Django REST API on a separate domain — so adding RSS turned out to be more interesting than I expected. Here's exactly what I built, the bugs I hit along the way, and the final result.

The Setup

Frontend: React + Vite, deployed on Vercel at vicentereyes.org
Backend: Django (cookiecutter-django), deployed at backend.vicentereyes.org
Goal: RSS feed available at two URLs:
- vicentereyes.org/rss.xml — the classic URL people expect
- vicentereyes.org/blog/rss — the canonical feed linked from the blog page

The Django Feed

Django ships with a syndication framework that makes building RSS feeds straightforward. I created blogs/feeds.py:

from io import StringIO

from django.contrib.syndication.views import Feed
from django.utils.feedgenerator import Rss201rev2Feed

from .models import BlogPost

_SITE = "https://www.vicentereyes.org"
_FEED_URL = f"{_SITE}/blog/rss"
_XSL_URL = f"{_SITE}/rss.xsl"


class StyledRssFeed(Rss201rev2Feed):
    def write(self, outfile, encoding):
        buf = StringIO()
        super().write(buf, encoding)
        xml = buf.getvalue()
        # Insert XSL PI after the <?xml ...?> declaration line
        split = xml.index("\n") + 1
        outfile.write(xml[:split])
        outfile.write(f'<?xml-stylesheet type="text/xsl" href="{_XSL_URL}"?>\n')
        outfile.write(xml[split:])


class LatestBlogPostsFeed(Feed):
    feed_type = StyledRssFeed
    title = "Vicente Reyes - Blog"
    link = f"{_SITE}/blog"
    description = "Latest posts from Vicente Reyes"

    def feed_url(self):
        return _FEED_URL

    def items(self):
        return BlogPost.objects.order_by("-date_published")

    def item_title(self, item):
        return item.title

    def item_description(self, item):
        return item.brief

    def item_link(self, item):
        return f"{_SITE}/blog/{item.slug}-{item.uid}"

    def item_pubdate(self, item):
        return item.date_published

    def item_author_name(self, item):
        return item.author_name

Why My Analytics Was Logging Every Page Visit Twice (And How I Fixed It)

Vicente G. Reyes — Mon, 01 Jun 2026 01:40:14 +0000

I built a custom analytics system into my portfolio backend — a Django REST API that records page visits — and wired the React frontend to call it whenever someone lands on a project or blog post detail page. It worked, except for one problem: every visit was logged twice.

This is the story of chasing the wrong root cause, wasting time on a fix that didn't work, and landing on a dead-simple solution that lives outside React entirely.

The Setup

The backend is a Django REST API with a PageVisit model. The frontend calls a single endpoint whenever a user lands on a detail page:

// POST /api/analytics/track/
{ "page_type": "project", "object_id": 33 }

On the React side, the call lives in a useEffect inside ProjectPage:

useEffect(() => {
  if (project?.id) api.trackPageView('project', Number(project.id));
}, [project?.id]);

The project data comes from a useProject hook that reads from localStorage cache first, then fetches from the API.

The Symptom

After visiting two project pages, the admin showed this:

637  Project  33
636  Project  33
635  Personal Projects  -
634  Project  30
633  Project  30

Two records per project visit, every single time.

First Suspect: React StrictMode

My first instinct was React StrictMode. In development, <React.StrictMode> intentionally double-invokes effects to surface side effects — it mounts the component, runs cleanup, then remounts it. If the effect fired on both the original mount and the simulated remount, that would explain exactly two records per visit.

The standard fix is a useRef guard: store the last tracked ID in a ref, and skip the call if it matches.

const trackedProjectId = useRef<string | null>(null);

useEffect(() => {
  if (project?.id && trackedProjectId.current !== String(project.id)) {
    trackedProjectId.current = String(project.id);
    api.trackPageView('project', Number(project.id));
  }
}, [project?.id]);

The logic: on the first run, the ref is null, so we track and set it to "33". On StrictMode's simulated remount, React preserves state and refs, so the ref is still "33" — the condition is false, and the second call is skipped.

I pushed this fix. The visits still doubled.

The Real Cause: A Full Remount, Not a Preserved One

React StrictMode's "double-invoke effects" behavior comes in two flavors. In the version I was thinking of, state and refs are preserved between the simulated unmount and remount — so a ref guard works perfectly. But if the component is fully remounting (fresh component instance, all state and refs reset to initial values), the ref starts as null again on every mount, and the guard is useless.

That's what was happening here. The component wasn't getting StrictMode's gentle "simulate and preserve" treatment — it was being torn down and recreated. Each fresh mount started with trackedProjectId.current = null, saw a project with id = 33, passed the guard, and fired the tracking call.

I confirmed this by looking at the hook. The useProject hook initializes from localStorage cache:

function useFetchSingle<T>(fetcher: () => Promise<T>, cacheKey: string) {
  const [data, setData] = useState<T | null>(() => readCacheSingle<T>(cacheKey));
  // ...
  useEffect(() => {
    fetcher().then((res) => { setData(res); /* write cache */ });
  }, []);
}

On a full remount, useState runs its initializer again. If the project is cached, data starts as the cached project immediately — project.id is available on the very first render, so the tracking effect fires right away. Then the component remounts again from scratch, the same initializer runs, the same project loads from cache, and the effect fires again.

A ref-based guard can't survive a full remount. By definition, refs reset to their initial value on a new component instance.

The Fix: Move Deduplication Outside React

If the component lifecycle can't be trusted to hold state across mounts, the guard needs to live somewhere that can: a module-level variable. In JavaScript, module-level variables are initialized once per page load and persist for the lifetime of the session, completely independent of component mount/unmount cycles.

I added a Set at the top of api.ts, outside the api object:

const _tracked = new Set<string>();

export const api = {
  // ...
  trackPageView: (
    pageType: 'professional_projects' | 'personal_projects' | 'audio_works' | 'blog_post' | 'project',
    objectId?: number,
  ) => {
    const key = `${pageType}:${objectId ?? ''}`;
    if (_tracked.has(key)) return Promise.resolve();
    _tracked.add(key);
    setTimeout(() => _tracked.delete(key), 3000);
    return fetch(`${BASE_URL}/analytics/track/`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ page_type: pageType, ...(objectId != null && { object_id: objectId }) }),
    }).catch(() => {});
  },
};

How it works:

On first call with "project:33", the key isn't in the set — we add it and fire the request.
Any duplicate call within the next 3 seconds hits _tracked.has(key) and returns immediately without a network request.
After 3 seconds, the key is removed, so legitimate return visits (user navigates away and comes back) are recorded correctly.

The 3-second window is long enough to absorb any double-mount behavior (which happens within milliseconds), and short enough that it doesn't suppress real repeat visits.

Component Code Stays Clean

Because the deduplication now lives in api.ts, the component code doesn't need any guard logic:

// ProjectPage.tsx
useEffect(() => {
  if (project?.id) api.trackPageView('project', Number(project.id));
}, [project?.id]);

// BlogPostPage.tsx
api.blogPost(lookup).then((data) => {
  setPost(data);
  if (data.id) api.trackPageView('blog_post', Number(data.id));
  // ...
});

Clean call sites, no leaking implementation details into components.

Takeaway

When a useRef guard doesn't fix a double-invocation problem, the component is fully remounting — not doing React StrictMode's state-preserving remount. In that case, any component-level guard will be reset on every mount and is useless.

The fix is to move the deduplication to a layer that outlives the component: a module-level variable. It's outside React's rendering model entirely, so no mount/unmount cycle can touch it.

DEV Community: Vicente G. Reyes

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

Where to Hook It

Finding the Right Recipient

The Change

Tests

What I'd Do Differently

TIL: identify. Check it out! man identify

Automating Django `dumpdata` Backups to S3 (One Command, Zero SSH)

The Problem

Step 1: Get dumpdata Right

Step 2: Run It Inside Docker Correctly

The Problem

Step 1: Get dumpdata Right

Step 2: Run It Inside Docker Correctly

Step 3: Collapse the Whole Thing Into One Alias

Step 4: Ship It to S3

The One-Liner, Fully Chained

Where I'd Take It Next

Step 3: Collapse the Whole Thing Into One Alias

Step 4: Ship It to S3

The One-Liner, Fully Chained

Where I'd Take It Next

Building a Plugin-Free Newsletter Popup on WordPress: Custom REST Endpoint Mailchimp API v3

Building a Plugin-Free Newsletter Popup on WordPress: Custom REST Endpoint → Mailchimp API v3

Why not a plugin or the native Mailchimp popup

Architecture

The server side: a REST endpoint that owns the Mailchimp call

Single vs double opt-in changes more than a status string

Anti-spam: a honeypot, not reCAPTCHA

The front end: triggers and a frequency cap

Mobile: dodge the intrusive-interstitial penalty

The bug that made it look broken: [hidden] vs display

Deploy notes

Takeaways

Building a Search Modal for a Membership-Gated WordPress Site

The shape of the problem

The backend: one REST endpoint

The access-leak problem

The frontend: debounced, aborted, escaped

The loading state, and the thing it was hiding

Caching: the membership leak, again

Mobile, and a lesson about fighting the theme

What I'd tell someone building this

The Paywall That Wasn't: Debugging a 919-Video Leak on WordPress

The stack

Symptom one: the reported bug

Symptom two: the bug nobody reported

Why it was wide open

The fix: one gate, server-side, before render

The decision that fixed the reported bug: stop trusting the level

The 500 that wasn't in the log I was reading

The edge cases that "done" hid

The part the page gate doesn't solve

What I'd take to the next one

Rebuilding a Divi Blog with Custom Shortcodes: A Field Report

The starting point

The shortcode system

One template for every category

The editorial layout — and a 27,000-pixel bug

The detail page

The "bug" that wasn't

The cutover: code and layout move, content doesn't

Caching will lie to you

Takeaways

Meta is down. Are you ok? lol

How I Shaved 10 MB Off My Portfolio in One Command

The Problem With PNGs in a Portfolio

The One-Time Backlog Fix: A Management Command

Step 1: Get `dumpdata` Right

Step 1: Get `dumpdata` Right

The bug that made it look broken: `[hidden]` vs `display`