Ok so I have found the cause of this problem and it seems to be a problem in core magento.
There is a new _construct method added to Mage_Cms_Block_Block in magento 1.14.2 which contains the following code.
/**
* Initialize cache
*
* @return null
*/
protected function _construct()
{
/*
* setting cache to save the cms block
*/
$this->setCacheTags(array(Mage_Cms_Model_Block::CACHE_TAG));
$this->setCacheLifetime(false);
}
This is effectively turning on caching for cms blocks. No cache key is set so it falls back to the Mage_Core_Block_Abstract::getCacheKeyInfo which uses the name of the block in layout. In this case we aren't actually using a layout xml file to add the block and there is no name set. Magento seems to try and handle this by setting something like ANONYMOUS_78 as the name. However for some reason this doesn't seem to be working 100% hence the duplicates I was seeing.
My solution was to override the Mage_Cms_Block_Block class in my own extension and add a new method to set the cache key explicitly to the block id rather than an assigned value. The class looks like this:
/**
* Override cms/block to add cache key. This started being a problem as of EE 1.14.2 when the _construct
* method was added which turns on caching for cms blocks
*/
class Mysite_Cms_Block_Block extends Mage_Cms_Block_Block
{
/**
* If this block has a block id, use that as the cache key.
*
* @return array
*/
public function getCacheKeyInfo()
{
if ($this->getBlockId()) {
return array(
Mage_Cms_Model_Block::CACHE_TAG,
Mage::app()->getStore()->getId(),
$this->getBlockId(),
(int) Mage::app()->getStore()->isCurrentlySecure()
);
} else {
return parent::getCacheKeyInfo();
}
}
}
This seems to have resolved the issue.
Update:
It looks like this same problem also exists in CE 1.9.2
Yikes lots of questions here. BTW, feel free to open issues on our github as well to get help. I know lots of folks there use nginx, while I personally have little experience with it.
Do I need to change .host IP to my site public IP and .port to 80 here?
The backend
should point to the IP and host where Magento is running with nginx.
do I also need to uncomment and change the VARNISH_LISTEN_ADDRESS=192.168.1.5 and VARNISH_LISTEN_PORT=6081 to public IP address of my website and port to 80?
Yes, I believe so.
and what about VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1 and VARNISH_ADMIN_LISTEN_PORT=6082 also just to make you aware I did configure DAEMON_OPTS= options according to as described in section 2 of https://github.com/nexcess/magento-turpentine/wiki/Installation
This will depend on how you're setting things up in your environment. These should be accessible to Turpentine, so that it can communicate with Varnish to do things like apply VCL changes and ban/purge items from the cache.
Admin > System > Cache Management: is this fine or do I need to make any change here?
We recommend that people turn off all other caches, and leave on the two Varnish related caches. Once things are working you can tweak these settings.
Admin > System > Configuration > Varnish Options > Servers : need to make any change here? i think I need to enter Varnish Authentication Key from /etc/varnish/secret file?
Yes, unless you've set up Varnish to not use a key.
Also, Config File Location & Custom VCL File Location are not there where path is defined. Will these be generated when I press Admin > System > Cache Management > Varnish Management > Apply Varnish Config.
No, when you click 'Apply Varnish Config' Turpentine will generate a VCL file and attempt to load it into the running Varnish instance. It will also save the generated VCL file in the location you specify under Config File Location
- which may not matter if your Varnish is not set up to read that file when starting up. Custom VCL File Location
is a way to add custom VCL code to the generated VCL file.
finally what to do with Admin > System > Configuration > Caching Options > Backend
This is where you tell Turpentine how to communicate with the Varnish admin interface (IP, port) so it can apply VCL, ban/purge content etc.
You may find our wiki configuration page helpful when setting things up.
Best Answer
Since this was EE, I was able to utilize Magento support but I also worked things out on my own to help focus the issue and get a solution as fast as possible. The code changes were provided by Magento so applying them to the actual app/code/core files is fine though you could always duplicate the files in your /app/code/local and apply the changes there.
The issue was that the block caching method that was added in 1.14.2 was not generating a unique cache key so when I had multiple blocks used in the category controller space, the generated cache key ended up being unique only for the first page hit, resulting in all of those pages to show duplicate content.
The fix was to add the following (displayed in diff file format to show the context surrounding the additions - just add in the lines with the + where they need to go):
In app/code/core/Mage/Cms/Block/Block.php at line 72:
In app/code/core/Mage/Cms/Block/Widget/Block.php at line 82:
I wouldn't think I'd be the only one to see this issue and if it shows up in CE 1.9.2, hopefully this will help resolve it for some people.