I’m having trouble with setting up redirects based on cookies on my nginx server. I operate two WordPress sites in separate directories under the same domain - one in Italian at example.com/it and another in Portuguese at example.com/pt.
I’ve implemented a WordPress function designed to create a cookie that keeps track of the user’s language choice:
// Cookie for language preference
add_action('init', 'store_language_preference');
function store_language_preference(){
$expiry_time = time() + 2592000; // 30 days
setcookie('lang_choice', 'IT', $expiry_time);
}
The objective is straightforward - once someone navigates to example.com, I want nginx to read the language cookie and direct them to the corresponding subdirectory. Here’s the current nginx configuration:
However, the redirects are not functioning as intended. I noticed that the cookie is present in the browser’s tools, but it has a specific path associated (Path: /it). Could this be causing an issue with nginx acting on the cookie at the root? What should I adjust in my settings?
yeah, that’s a classic cookie scoping issue. had the same thing happen on my multisite setup last year. besides fixing the path like others mentioned, your nginx logic’s backwards - you’re checking for PT twice instead of using a clean if/else structure. also watch out for infinite redirects when users land directly on /it or /pt URLs. nginx will keep trying to redirect them over and over.
Yeah, everyone’s talking about the cookie path fix (which you need), but this whole setup is way too complicated.
You’re juggling redirects across nginx configs, WordPress functions, and cookie logic. Then you’ll hit edge cases - first-time visitors, bots, browser compatibility. And when something breaks? Good luck debugging that mess.
I’ve built similar multilingual routing for enterprise clients. The most reliable approach? Move this logic outside your server stack.
With Latenode, you create one automation that handles everything. Set up a webhook for incoming requests, check for language cookies, fall back to browser headers, then redirect. You get clean logging, easy testing, and can add geolocation or user preferences without touching server configs.
Best part - you can prototype and test everything before going live. No more guessing if nginx rules work or wondering why users get stuck in redirect loops.
Your WordPress sites don’t change. Just point your domain root at the Latenode webhook and let it handle the routing.
You’re right - the cookie path is definitely the problem. I hit this exact issue six months ago with a client’s bilingual site. The path restriction blocks nginx from reading the cookie at domain root.
Beyond fixing the cookie path, add some fallback logic to your nginx config. Right now you’re assuming the cookie always exists - but what about first-time visitors? Try falling back to Accept-Language headers or IP geolocation.
Watch those nested if statements too. They’ll kill performance under heavy load. Found this out the hard way when our server started throwing 500s during traffic spikes. Use a map directive instead - handle the cookie evaluation outside the location block.
One more gotcha: make sure your WordPress sites aren’t fighting over session management. I’ve seen the Italian site override cookies from the Portuguese site, creating nasty redirect loops.
The path restriction on your cookie is definitely the problem. When you set a cookie with Path: /it, nginx can’t read it at the root level.
Your WordPress function needs to explicitly set the path to root:
function store_language_preference(){
$expiry_time = time() + 2592000; // 30 days
setcookie('lang_choice', 'IT', $expiry_time, '/'); // Added root path
}
That fourth parameter makes the cookie available site-wide instead of just in the /it directory.
Honestly though, managing this across nginx configs and WordPress gets messy fast. I’ve dealt with similar multilingual redirect scenarios and found that automation platforms handle this way better.
With Latenode, you can set up a webhook that intercepts requests, checks cookies, handles language detection, and manages redirects all in one flow. No more splitting logic between your web server and WordPress. Plus you get better logging and can easily add geolocation fallbacks or A/B testing.
I built something similar for a client’s trilingual site and it’s been running smoothly for months without touching server configs.
You’re right about the cookie path, but there’s another issue nobody caught. Your second condition if ($cookie_lang_choice != "PT") triggers when there’s no cookie at all - so everyone gets forced to Italian by default.
I hit this same problem on a multilingual WordPress site for a European client. Fixed it by checking for cookie existence first:
Don’t forget to exclude your subdirectories from this redirect logic. Add separate location ^~ /it/ and location ^~ /pt/ blocks, otherwise nginx keeps processing your root redirect rules even for requests that should stay put.
oh, and one more thing - check your cookie domain settings. had a client where cookies worked perfectly in dev but broke in production due to domain mismatches. also, make sure your nginx version handles cookie variables properly. older versions can be really finicky with cookie parsing.
You’re right about the cookie path, but your WordPress function has a bigger issue. You’re hardcoding ‘IT’ no matter what language the user picks - so everyone gets the same cookie value, which defeats the whole point. I hit this same problem on a multilingual tourism site I built. You need to actually detect and store what language they chose. Grab it from the URL path or use WordPress’s locale detection:
One more thing - nginx runs these redirects on every single request. You’ll get better performance if you only trigger redirects on the root path, not everywhere. Right now you’re adding processing overhead to all your WordPress assets and API calls.