Header ESI block and store_switcher

[BerndKammlott]

Hey,

i found a bug with the header esi cache and the store_switch. On the first view of the page, the header esi block will be generated. If you than click on another category and change the language in that page, you will be redirected back to the first page.

Reproducible in the turpentine demo store:

Visit: http://turpentine-master.devsupport.nexcess.net/men.html click on another category line women and change the language -> results in men.html?store=french&from_store=german

Do you have any idea how to fix this? Thank you!

[addison74]

Visiting that link I confirm the issue. Select any category link in navigation then switch the language from selector. Instead of reloading the same page content but in other language, you will get other category. I guess the ESI policy for the selector is set to public instead of private.

[aricwatson]

I've confirmed this bug. What's happening is the language selection block is getting cached as part of the header block (which is cached privately per user). Since the language selector use's the current page URL in the drop-down form, the current page URL when the header block was first cached stays in that header block - meaning that when you change the language, it's directing the browser back to that original URL.

This is a very theme-specific issue. I suppose we could override that block's template to fix it, but I don't think that's wise.

[crasx]

Is there an example of how to fix this? I also have this issue and need to find a solution asap. I was thinking I could add a flush event to the block for an event like controller_action_layout_generate_blocks_before but that doesn't sound wise when you consider multiple varnish instances that need to be flushed each page load for 10k users.

I also noticed the currency selector is controlled via JS. Maybe another option is to move that js to its own block in a non-cached part of the page...

Any thoughts on that?

[BerndKammlott]

on option is to set the scope to "page" - but not a good one the chance for a hit goes to zero :)

[aricwatson]

I think what I'd consider is customizing the vcl_hash option to add the current store cookie value to the hash. This would have the effect of creating separate cache "buckets" for each language - which may or may not work/be efficient depending on your particular requirements.