DEV Community: Vicente G. Reyes

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

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

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

The setup

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

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

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

The symptom

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

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

The funnel was just quietly bleeding out.

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

The root cause

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

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

The right logic is:

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

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

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

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

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

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

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

    return $trial_length;
}, 10, 2 );

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

The fix

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

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

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

return $trial_length;

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

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

What Sentry taught me by not catching this

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

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

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

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

My takeaways for that class of bug:

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

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

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

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

The WebP Migration That Wasn't About WebP

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

Nobody asked me to do this.

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

I almost installed ShortPixel and called it a day.

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

Always inventory before you optimize

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

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

The output stopped me cold:

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

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

Finding 1: 241MB of files nothing was serving

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

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

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

Verified they were genuinely unreferenced before deleting:

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

Three zeros. Deleted, 241MB back.

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

Finding 2: the size ladder had been demolished

This is the one that mattered.

wp eval 'print_r( get_intermediate_image_sizes() );'

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

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

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

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

Why this is worse than it sounds

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

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

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

I counted actual coverage:

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

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

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

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

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

Finding 3: the images weren't the disk hog

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

Where was the other gigabyte?

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

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

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

The fix: three filters, no new plugins

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

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

1. Restore the size ladder

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

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

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

2. WebP output for generated subsizes

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

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

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

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

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

3. Rewrite hardcoded URLs at render time

This is the gotcha that nearly shipped broken.

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

I measured the exposure:

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

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

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

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

    $dir = wp_get_upload_dir();

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

    static $cache = [];

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

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

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

The `-scaled` trap

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

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

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

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

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

Why render-time over wp search-replace:

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

Running the regeneration

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

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

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

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

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

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

add_filter( 'woocommerce_background_image_regeneration', '__return_false' );

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

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

Rolling it out to production

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

Nearly. One thing bit me.

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

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

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

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

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

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

Results

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

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

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

What's still wrong

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

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

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

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

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

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

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

What I'd tell past-me

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

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

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

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

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

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

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

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

How fast do you finish your usage on Claude Code?

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

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

The Case of the Disappearing Free Trial

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

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

The Symptom

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

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

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

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

First Theories (All Wrong)

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

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

This felt promising enough to chase hard:

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

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

Ruling Out an Entire Stack, One Piece at a Time

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

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

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

Following the Data, Not the Guesses

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

WP-CLI made this possible:

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

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

That function's actual implementation was almost embarrassingly simple:

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

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

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

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

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

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

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

The Actual Bug

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

But nested inside it was this:

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

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

The Fix

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

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

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

What Made This One Hard

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

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

Takeaways

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

The Button That Sent People to a Blank Form

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

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

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

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

The Setup

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

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

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

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

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

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

And ContactPage always initialized its form with an empty service:

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

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

The Fix: Carry the Intent in the URL

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

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

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

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

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

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

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

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

const [searchParams] = useSearchParams();

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

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

A Subtlety About When It Runs

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

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

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

Testing It for Real

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

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

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

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

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

The Takeaway

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

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

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

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

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

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

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

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

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

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

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

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

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

Setup

1. Two Sentry projects, not one

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

2. Constants in wp-config.php

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

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

define( 'WP_SENTRY_ENV', 'production' );

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

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

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

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

A few decisions worth explaining:

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

3. Verify

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

4. Turn on inbound filters immediately

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

The first catch

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

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

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

Reading the trace

The exception came from Action Scheduler's safety check:

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

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

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

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

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

The fix: delete the work, keep a guard

Two parts.

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

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

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

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

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

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

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

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

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

Takeaways

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

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

Closing the Loop: Emailing Myself When My Resume Gets Downloaded

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

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

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

Where to Hook It

The gate has two views:

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

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

Finding the Right Recipient

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

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

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

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

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

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

The Change

project/core/views.py — inside ResumeDownloadView:

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

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

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

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

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

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

Tests

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

import datetime

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

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

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


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


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


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


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

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

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

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

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

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

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

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

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

5 passed in 5.31s

What I'd Do Differently

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

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

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

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.

DEV Community: Vicente G. Reyes

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

The setup

The symptom

The root cause

The fix

What Sentry taught me by not catching this

The WebP Migration That Wasn't About WebP

Always inventory before you optimize

Finding 1: 241MB of files nothing was serving

Finding 2: the size ladder had been demolished

Why this is worse than it sounds

Finding 3: the images weren't the disk hog

The fix: three filters, no new plugins

1. Restore the size ladder

2. WebP output for generated subsizes

3. Rewrite hardcoded URLs at render time

The -scaled trap

Running the regeneration

Rolling it out to production

Results

What's still wrong

What I'd tell past-me

How fast do you finish your usage on Claude Code?

The Case of the Disappearing Free Trial

The Symptom

First Theories (All Wrong)

Ruling Out an Entire Stack, One Piece at a Time

Following the Data, Not the Guesses

The Actual Bug

The Fix

What Made This One Hard

Takeaways

The Button That Sent People to a Blank Form

The Setup

The Fix: Carry the Intent in the URL

A Subtlety About When It Runs

Testing It for Real

The Takeaway

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

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

Setup

1. Two Sentry projects, not one

2. Constants in wp-config.php

3. Verify

4. Turn on inbound filters immediately

The first catch

Reading the trace

The fix: delete the work, keep a guard

Takeaways

Closing the Loop: Emailing Myself When My Resume Gets Downloaded

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

The `-scaled` trap

Step 1: Get `dumpdata` Right

Step 1: Get `dumpdata` Right

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