pull down to refresh

WooCommerce Referral Links Only Trigger on 2nd Visit Fix (25k sats bounty)
187 sats \ 16 comments \ @Kontext 27 Aug devs
25k sats + lifetime Gold membership on SATOSH.EE and my eternal gratitude to whoever helps me solve the issue (did not set up a bounty here since I'll be posting this also on nostr and X).
I’m running into an issue with referral links on a WooCommerce site (WordPress + WooRewards paid version + Referral Codes (WooRewards and Referral Codes are LongWatchStudio plugins); also tested with the Affiliates plugin - the issue also occurred with that one). The goal is to establish referral bonds between users for a loyalty/affiliate program.
The problem:
  • Referral logic only triggers on the second visit to a referral URL.
  • On first visit, cookies for tracking (e.g., lwsadmsession…) either don’t appear or the plugin code never runs.
  • Reloading the same link triggers the referral logic as expected.
  • This behavior occurs with multiple referral plugins, not just WooRewards.
What I’ve tried:
  • Disabled all other plugins, switched to default theme
  • Cloudflare + Rocket.net: disabled query string caching
  • .htaccess rules to bypass server caching
  • Early hook code to force session/logic execution (relied on ChatGPT to come up with those codes, would not be surprised if they were faulty in and of themselves)
  • Verified no Varnish or server-level caching interference
Developer insight from WooRewards: “Our code is never called. Something else takes charge before WordPress, and (even if unintentional) fakes our redirection.”
Looking for ideas why referral plugin code isn’t executing on first visit, even when cookies or sessions should be available.
Happy to provide more details, just drop a comment or email me kontext@satosh.ee
Thanks!
write
preview
related posts
0 replies \ @Kontext OP 14h
The issue seems to be that referral cookie attempts to set too late, after WooCommerce sessions have started or headers have been sent. On first visit, no session exists → cookie cannot be set → referral only works on second visit.
What I've tried to do is - launch referral logic at the earliest hooks - many times (even before posting this problem here) with different code snippets from ChatGPT, Claude, now also Lumo and Duck.ai (which, admittedly, also uses ChatGPT) but none of the solutions work. The end result is still the same.
reply
10 sats \ 8 replies \ @guerratotal 29 Aug
Test this: open DevTools → Network tab → look at the header of the first response (cf-cache-status, x-rocket-cache, etc.).
If you see HIT → you're serving cached HTML, which explains why the plugin code never runs on the first visit.

The second visit usually returns a MISS or BYPASS because the cookie/session already exists, and then WordPress responds dynamically.

Exclude referring URLs from all caching (Cloudflare + Rocket.net).
Example in Cloudflare Page Rules / Transform Rules:
*satoshi.com/ref Cache Level: Bypass
Or if the plugin uses ?ref=CODE:
satoshi.com/?ref=* Cache Level: Bypass
For example, you can also add something like this to your .htaccess if the URL includes a ?ref=
RewriteCond %{QUERY_STRING} (^|&)ref= [NC] RewriteRule .* - [E=Cache-Control:no-cache]
If you can't solve it you can find a highly recommended plugin here. (paid)
Or you can download this other plugin that I got you
reply
0 sats \ 7 replies \ @Kontext OP 29 Aug
Thanks for the input. I gave the information you presented to ChatGPT and Claude. So we have 3 first headers related to the referral link:
  1. Request URL http://satosh.ee/ref_code Request Method GET Status Code 301 Moved Permanently Remote Address 104.19.155.92:80 Referrer Policy strict-origin-when-cross-origin No HIT or MISS or any other of those, but we have: cache-control max-age=3600
  2. Request URL https://satosh.ee/ref_code Request Method GET Status Code 302 Found Remote Address 104.19.154.92:443 Referrer Policy strict-origin-when-cross-origin And we have this: cache-control public, max-age=0, s-maxage=2592000, stale-if-error=86400 cf-cache-status DYNAMIC
The third entry is related to the URL to which the original satosh.ee/ref_code redirects:
  1. Request URL https://satosh.ee/?lrc_code=ref_code Request Method GET Status Code 200 OK Remote Address 104.19.154.92:443 Referrer Policy strict-origin-when-cross-origin Again, we can find the DYNAMIC tag: cache-control public, max-age=0, s-maxage=2592000, stale-if-error=86400 cf-cache-status DYNAMIC
So no MISS or BYPASS headers. Nevertheless, ChatGPT and Claude intepreted those results differently:
CLAUDE:
Perfect! This is very revealing. The person who helped you was spot-on about caching being the issue, and your network analysis confirms it. Here's what's happening: The Problem:
First request (http://satosh.ee/ref_code) gets a 301 redirect with cache-control: max-age=3600 - this redirect is being cached for 1 hour Second request (https://satosh.ee/ref_code) gets a 302 redirect with cf-cache-status: DYNAMIC Final request (https://satosh.ee/?lrc_code=ref_code) shows cf-cache-status: DYNAMIC
The Issue: That first 301 redirect with max-age=3600 is the culprit. Cloudflare is caching the redirect response, so on the first visit, it serves the cached redirect without ever hitting your WordPress server where the plugin code would run. The Solution: You need to exclude your referral URLs from caching at both levels: In Cloudflare: Create a Page Rule or Transform Rule for:
satosh.ee/ref_code → Cache Level: Bypass satosh.ee/?lrc_code=* → Cache Level: Bypass
In your .htaccess (for the WordPress level): apache# Bypass cache for referral codes RewriteCond %{REQUEST_URI} ^/ref_code [NC,OR] RewriteCond %{QUERY_STRING} (^|&)lrc_code= [NC] RewriteRule .* - [E=Cache-Control:no-cache] The key insight is that redirect caching was the hidden issue - not just page caching, but the redirect itself being cached before WordPress could process the referral logic.
This solution did not work. Not even after contacting Rocket.net and asking them to turn off Cloudflare caching for the specific URL's (unfortunately I don't have direct access to Cloudlfare via my Rocket.net hosting admin panel)
CHATGPT:
Do these 3 quick checks
Who is doing the 302? Open the 302 entry (https://satosh.ee/ref_code) → Headers → Response Headers. Look for x-redirect-by:
WordPress → WP is doing it (theme/plugin/htaccess inside WP).
Missing → Likely Cloudflare rule or server (Rocket.net/NGINX/.htaccess) is doing it before WP.
Direct-hit test (rules bypassed) Open a fresh Incognito window. Paste https://satosh.ee/?lrc_code=ref_code directly as your first page load.
If the plugin cookie (e.g. lwsadmsession...) sets on this first load, the problem is that the pretty URL /ref_code is being redirected before WP, blocking the plugin on first visit.
If the cookie still doesn’t set, it’s more likely a session/cookie timing issue inside WP/WooCommerce.
Look for a non-WP redirect rule
Cloudflare: check Rules → Redirect Rules / Transform Rules / Page Rules for anything mapping /ref_code* → /?lrc_code=*.
Server/htaccess: search .htaccess for ref_code or lrc_code rewrites.
What to do based on results
If the 302 is from Cloudflare or server:
Remove/disable that redirect and let the plugin handle /ref_code itself, or
Keep the redirect but ensure the very first URL the user hits already includes the query (/?lrc_code=...) so the plugin sees it on first load.
If the direct-hit test also fails:
Check in the final 200 response’s Cookies tab whether WooCommerce session (wp_woocommerce_session_*) appears on first load.
If not, it’s a session start order issue—your plugin may rely on WC session that only exists from the second pageview. (Fix: start WC session earlier or adjust plugin hooks.)
If you paste what you see for x-redirect-by on that 302 (or confirm it’s missing), I can tell you exactly where to change the rule.
ME:
  1. x-redirect-by WordPress
  2. No lwsadmsession... cookie
  3. No access to Cloudflare directly (only through Rocket.net support)
ChatGPT said:
Perfect — thanks, this clarifies a lot. Since we now know:
The 302 redirect from /ref_code → /?lrc_code=ref_code is triggered by WordPress (x-redirect-by: WordPress).
Cloudflare is not serving cached HTML (cf-cache-status: DYNAMIC).
On a direct hit to /?lrc_code=ref_code, the WooRewards referral cookie (lwsadmsession...) still doesn’t set on first visit.
You can’t bypass Cloudflare directly, only through Rocket.net support.
This means the problem is not Cloudflare caching — the issue is that WordPress/WooCommerce sessions and plugin hooks are firing too late on the first pageview, so the referral code isn’t processed until the second visit.
Let me explain what’s happening and what to test next.
What’s Happening
User clicks referral link → /ref_code.
WordPress instantly redirects them to /?lrc_code=ref_code.
On that redirected page, WooCommerce should start a session and WooRewards should set the lwsadmsession cookie.
But on first load, WC session doesn’t exist yet → plugin never gets triggered → no cookie.
On second load, WC session already exists → plugin sees it → referral works.
This matches exactly what WooRewards devs told you:
“Our code is never called on first visit.”
How to Fix or Confirm the Root Cause Step 1 — Check if WooCommerce Sessions Start on First Visit
In DevTools → Application → Storage → Cookies, look for this cookie on the first load of /?lrc_code=ref_code:
wp_woocommerce_session_<hash>
If missing → WC session isn’t created soon enough.
If present but empty → session starts but plugin fails anyway.
Step 2 — Force WooCommerce Session to Start Earlier
If sessions are missing on first load, add this snippet to your functions.php or Code Snippets plugin:
add_action( 'init', function() { if ( class_exists( 'WooCommerce' ) ) { if ( null === WC()->session ) { WC()->session = new WC_Session_Handler(); WC()->session->init(); } } }, 1 );
Why this works:
By default, WooCommerce delays session creation until after WordPress init (priority 10+).
Some plugins, like WooRewards, rely on an active session to set referral cookies.
Forcing WC sessions to start at priority 1 ensures the plugin sees it on first visit.
Step 1: Woocommerce session does not start on the first load. Step 2: The Code Snippet (as usual), did not solve the issue. The plugin still behaves the same way
I have considered other plugins but can't really switch on Satoshee since I have a whole loyalty system built upon LongWatchStudio plugins and most other plugins don't have half of the capabilities that LWS has. I even had them develop a custom solution for me in which gift cards also double as referral links (one of the unique features of Satoshee).
I could use another plugin on the new site, theoretically, but nevertheless I need to get the system working on Satoshee first. The Drive link you provided requires access, btw, I sent a request.
reply
10 sats \ 6 replies \ @guerratotal 1 Sep
Good morning, my friend. On Fridays, I completely disconnect here at home (I spend the whole week on this computer working, so I spend the weekends with my family; I'm hardly ever online). On Friday, I gave you access to the drive. Let me know if it worked for you. Maybe you can try that plugin in a WordPress test and see what it offers.
Really, when you have multiple intermediaries like Cloudflare or caching plugins, life sometimes gets a little complicated...!!
reply
23 sats \ 5 replies \ @Kontext OP 1 Sep
Hey, all good, I took some time off work over the weekend as well! I did get the access to the plugin you shared via Drive, haven't tested it out yet though. Will let you know how it goes :)
reply
0 sats \ 4 replies \ @guerratotal 1 Sep
Perfect, you tell me, I'm here online.
reply
0 sats \ 3 replies \ @Kontext OP 14h
Hey, just letting you know I tried to install the plugin you linked to on the Staging site, but it failed: The package could not be installed. No valid plugins were found. Plugin installation failed.
I did try another free plugin, and the issue is exactly the same as with WooRewards & Referral Codes plugins. And in general, I'd prefer to stick with those 2 plugins anyway for reasons talked about before. In any case, the root of the problem seems to be this: #1205203
If you have any further suggestions, I'm all ears!
reply
0 sats \ 2 replies \ @guerratotal 14h
Do you have any extra caching plugins? Any plugins to improve site speed? If you have any, disable them and try again. I'll check the plugin...!!
reply
0 sats \ 1 reply \ @Kontext OP 14h
No. I've even reverted it back to only Woocommerce + loyalty plugins and default template, and the issue was still there. I do have Cloudflare CDN (Rocket.net hosting), but I also asked them to disable caching for referral URL's and asked Rocket support if they have any other caching / redirects / something happening that could be interfering with the links, but they said no. It's a bit shit that I don't have direct access to the Cloudflare admin panel, but then again, Rocket seems to be quite a professional company so if there was something fundamentally flawed in their setup, I'm quite sure they would know it by now.
view all 1 replies
0 sats \ 1 reply \ @rapunzel_where_are_your_hair 12h
The problem occurs when referral plugin code doesn't execute on first page load due to caching, server-level redirects, or WordPress initialization timing issues.

Step by Step solution

Phase 1: Quick Wins (Start Here - 70% Success Rate)

Step 1: Test in Incognito Mode
  1. Open private/incognito browser window
  2. Test your referral link
  3. If it works → Clear all browser cache and cookies
  4. If still broken → Continue to Step 2
Step 2: Disable All Caching For Cloudflare users:
  • Log into Cloudflare dashboard
  • Create page rule: yoursite.com/*ref* → Cache Level: Bypass
  • Go to Caching → Configuration → Set "Caching Level" to "No Query String"[3][4]
For WordPress caching plugins:
  • Deactivate WP Rocket, W3 Total Cache, etc.
  • Test referral links
  • If working, configure exclusions for referral URLs[5][6]

Phase 2: Server-Level Issues (25% Success Rate)

Step 3: Check .htaccess File
  1. Backup your .htaccess file first
  2. Via FTP/cPanel, rename .htaccess to .htaccess-backup
  3. Test referral links
  4. If working, the issue is redirect order in .htaccess[7][8]
Fix .htaccess redirect order:
# Custom redirects MUST come BEFORE WordPress section
RewriteCond %{QUERY_STRING} ^(.*)ref=(.*)$ [NC]
RewriteRule ^(.*)$ /$1?%1ref=%2 [L]

# BEGIN WordPress
<IfModule mod_rewrite.c>
# WordPress rules here
</IfModule>
# END WordPress

Phase 3: WordPress Code Solutions (30% Success Rate)

Step 4: Force Early Plugin Execution Add this code to your theme's functions.php file:
// Force early referral tracking
function force_early_referral_tracking() {
    if (isset($_GET['ref']) || isset($_GET['referral']) || isset($_GET['affiliate'])) {
        // Force WooCommerce session start
        if (class_exists('WooCommerce')) {
            WC()->session->init();
        }
        // Force session start
        if (!session_id()) {
            session_start();
        }
    }
}
add_action('init', 'force_early_referral_tracking', 1);
Step 5: Server-Level Cache Bypass Add before WordPress rules in .htaccess:
# Bypass caching for referral URLs
<IfModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} (ref=|referral=|affiliate=) [NC]
RewriteRule .* - [E=no-cache:1]
Header set Cache-Control "no-cache, no-store, must-revalidate" env=no-cache
</IfModule>

Note Hosting-Specific Quick Fixes

The success rate varies significantly by hosting environment. Cloudflare users should start with CDN configuration, while shared hosting users often need to address server-level restrictions.
Why This Happens??
This issue occurs because
  • server level caching serves cached pages before WordPress loads
  • CDN/Cloudflare caches URLs with query parameters
  • .htaccess redirects interfere with referral parameters
  • WordPress hook timing - plugins load after other systems intercept requests
  • Session management issues on shared hosting with limited PHP session timeouts

Advanced Solutions (If above Steps Fail)

Create Must-Use Plugin:
  1. Create folder /wp-content/mu-plugins/
  2. Add file force-referral-early.php:
<?php
function force_referral_plugins_early() {
    if (isset($_GET['ref']) || isset($_GET['referral'])) {
        while (ob_get_level()) {
            ob_end_clean();
        }
        if (!headers_sent()) {
            header('Cache-Control: no-cache');
        }
    }
}
add_action('muplugins_loaded', 'force_referral_plugins_early', 1);

To make sure this never happens again

  1. Always backup files before making changes
  2. Test on staging site first if possible
  3. Document changes so you can reverse them
  4. Contact plugin support with diagnostic data if nothing works
The key insight is that "something else takes charge before WordPress" meaning the issue occurs at the server/CDN level before your WordPress plugins can execute. Start with the highest success rate solutions first, and work systematically through the troubleshooting matrix.
reply
10 sats \ 0 replies \ @Kontext OP 11h
Thank you for the detailed & step-by-step response! Phase 1 I have tried, although I will make a note to the plugin devs that it would be good to have an option to have specific referral links i.e. site.com/ref/code. Currently the Referral Codes plugin creates them simply as site.com/code which is the same format as any other page. However, I did have Rocket.net support turn off Cloudflare for the specific URL's and it didn't work, so that's probably not the issue anyway. Phase 2 & 3 I have also tried in different formats (and solutions via different LLM's - I'm not a dev myself, unfortunately), but I'll definitely give your specific instructions a go.
One thing that I didn't mention - ChatGPT said it shouldn't make a difference in how the links act - was that there was also a PHP error that came up in debugging:
PHP Deprecated: Creation of dynamic property WC_Coupon::$lws_referralcode
Chat: Not critical for functionality yet, but in PHP 8.2+ dynamically adding properties to objects is deprecated. The plugin is trying to attach $lws_referralcode directly to the WC_Coupon object. This should ideally be stored in meta instead:
php Copy code $coupon->update_meta_data('lws_referralcode', $code);
Chat: This doesn’t directly break the cookie behavior, but it’s good to fix for future PHP compatibility.
In any case, I'll follow your instructions and see where it takes me. Can't guarantee I'll get to it tonight (has been a long day), but tomorrow at the latest!
reply
0 sats \ 3 replies \ @ek 27 Aug
  • On first visit, cookies for tracking (e.g., lwsadmsession…) either don’t appear or the plugin code never runs.
  • Reloading the same link triggers the referral logic as expected.
Does the referral logic depend on cookies present? Are your cookies using SameSite=Lax?
Is there a way for us to reproduce the issue?
reply
55 sats \ 2 replies \ @Kontext OP 27 Aug
  • On first visit, cookies for tracking (e.g., lwsadmsession…) either don’t appear or the plugin code never runs.
  • Reloading the same link triggers the referral logic as expected.
Does the referral logic depend on cookies present? Are your cookies using SameSite=Lax?
Is there a way for us to reproduce the issue?
The SameSite column is empty on all cookies, so from what I understand: Blank SameSite = defaults to SameSite=Lax
I recently launched another website and installed the Referral Codes plugin again to test the behavior. The same issue persists. Initially I was certain that the issue was related to the LongWatchStudio plugins themselves, so I was in a lengthy correspondence with them, they claimed they weren't able to reproduce the issue on their end. I am thinking of emailing them again due to the fact that the same problem is present on a new site, but nevertheless, the fact that another plugin behaved the same way (at least on the older site, haven't tested on the new one yet), seems to indicate that it's not just a plugin issue.
The way the referral codes work does not seem to be dependent on whether the cookies are present from the get-go or not. I tested this yesterday:
On the new site, the plugin's cookie lwsadmsession... was present on the first visit, however the referral logic didn't trigger until the 2nd visit.
On the older site, the cookie wasn't present on the first visit, referral logic acted the same (only triggered on the 2nd visit)
reply
10 sats \ 1 reply \ @ek 27 Aug
The SameSite column is empty on all cookies, so from what I understand: Blank SameSite = defaults to SameSite=Lax
This depends on the browser, see 'default to Lax' row here.
Did your referrals work before?
reply
0 sats \ 0 replies \ @Kontext OP 27 Aug
The referrals worked at some point when the original site (satosh.ee) was a WIP... can't tell you the exact time when I tested the system, but based on my notes it seems initial tests were done already back in October 2023. But by the time I launched it, more than a year later in November 2024, the links weren't working properly and I haven't gotten them to work since.
reply