pull down to refresh

0 sats \ 7 replies \ @Kontext OP 29 Aug \ parent \ on: WooCommerce Referral Links Only Trigger on 2nd Visit Fix (25k sats bounty) devs
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.
write
preview
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 17h
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 17h
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 17h
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.
reply
0 sats \ 0 replies \ @guerratotal 16h
https://drive.google.com/file/d/1wd0RvT-8h3IaxeL4CaCu83FpAVWejKiP/view?usp=sharing
The other plugin doesn't really work, I got this other one, I already tried it and it opened for me, I don't know if it's what you're looking for, but you can try it if you want.
reply