Closed m-overlund closed 9 years ago
Odd... Is the homepage-specific content contained within a block that has an ESI policy? If you turn on the debug logging, is there anything showing up in the logs?
Thanks for getting back - Finally got time to test a bit again:
Yeah, it's in the header block, with ESI set to private (because it also contains the cart). The cart in header updates as it should.
Can't really find anything in the logs.
2015-08-24T06:36:08+00:00 DEBUG (7): TURPENTINE: Matched router: default
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: header
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: store_language
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: top.links
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: wishlist_link
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: top.search
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: ANONYMOUS_12
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: top.container
2015-08-24T06:36:08+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: bml.center.logo
2015-08-24T06:36:08+00:00 DEBUG (7): TURPENTINE: Set Varnish cache flag header to: 1
2015-08-24T06:36:08+00:00 DEBUG (7): TURPENTINE: Set ESI flag header to: 0
2015-08-24T06:36:08+00:00 DEBUG (7): TURPENTINE: Generated form_key: 8hthLVorjPkmWQq0
2015-08-24T06:36:08+00:00 DEBUG (7): TURPENTINE: Set Varnish cache flag header to: 1
2015-08-24T06:36:08+00:00 DEBUG (7): TURPENTINE: Set ESI flag header to: 0
2015-08-24T06:36:14+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: root
2015-08-24T06:36:14+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: content
2015-08-24T06:36:14+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: messages
2015-08-24T06:36:14+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: form.additional.info
2015-08-24T06:36:14+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: captcha
2015-08-24T06:36:14+00:00 INFO (6): TURPENTINE: Checking ESI block candidate: ANONYMOUS_29
Headers:
Age:1039
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Mon, 24 Aug 2015 06:35:28 GMT
Server:nginx
Transfer-Encoding:chunked
Via:1.1 varnish
X-Content-Type-Options:nosniff
X-Frame-Options:sameorigin
X-Frame-Options:SAMEORIGIN
X-Turpentine-Cache:1
X-Turpentine-Esi:1
X-Varnish:1572897879 1572897797
X-Varnish-Currency:
X-Varnish-Esi-Access:
X-Varnish-Esi-Method:
X-Varnish-Hits:22
X-Varnish-Host:www.fyr-selv.dk
X-Varnish-Set-Cookie:frontend=0d612455a00140018e001e464c0099a4; expires=Tue, 25-Aug-2015 06:18:08 GMT; Max-Age=86400; path=/; domain=fyr-selv.dk; httponly
X-Varnish-Store:
X-Varnish-URL:/
Additional info: We're running multistore, and the issue is the same on the other websites, using different templates etc.
The issue is that the identifier is empty when using varnish:
Mage::getSingleton('cms/page')->getIdentifier();
@m-overlund have you tried using $this->getIsHomePage()? It can be also Mage::getBlockSingleton('page/html_header')->getIsHomePage(). See http://stackoverflow.com/questions/12403675/detect-home-page-in-magento-phtml-that-will-work-with-block-html-cache-enabled for some more info.
Can't get the mentioned solutions working with turpentine enabled. As mentioned it works just fine without turpentine enabled too - shouldn't be an error in Magento per se.
This issue is very strange. Been looking through the base code of CMS page handling, and the getRequest seems to be the way to identify - thats the way Magento does it too.
print_r(Mage::app()->getRequest()->getControllerName());
Will output:
Without varnish: Frontpage: index CMS page: cms
Varnish enabled: Frontpage, : cms CMS page: index
Works opposite as expected with varnish enabled.
Temporary solution could be to check for ControllerName not to be frontpage and it would work as expected.
But could be nice to fix the actual issue :-)
I'm getting way out of my area of expertise, but my best guess would be that Magento changed some of the identifier/router code, which makes turpentine alter the identifier to always be null.
The only bits i can grep on anything like this is from Model/Dummy/Request.php, Line: 767 Maybe it could be helpful?
protected function _cmsRouterMatch() {
$router = Mage::app()->getFrontController()->getRouter( 'cms' );
$identifier = trim($this->getPathInfo(), '/');
$condition = new Varien_Object(array(
'identifier' => $identifier,
'continue' => true
));
Mage::dispatchEvent('cms_controller_router_match_before', array(
'router' => $router,
'condition' => $condition
));
$identifier = $condition->getIdentifier();
if ($condition->getRedirectUrl()) {
Mage::app()->getFrontController()->getResponse()
->setRedirect($condition->getRedirectUrl())
->sendResponse();
$this->setDispatched(true);
return true;
}
if (!$condition->getContinue()) {
return false;
}
$page = Mage::getModel('cms/page');
$pageId = $page->checkIdentifier($identifier, Mage::app()->getStore()->getId());
if (!$pageId) {
return false;
}
$this->setModuleName('cms')
->setControllerName('page')
->setActionName('view')
->setParam('page_id', $pageId);
$this->setAlias(
Mage_Core_Model_Url_Rewrite::REWRITE_REQUEST_PATH_ALIAS,
$identifier
);
return true;
}
This also returns 1 on every page except the frontpage:
Mage::getBlockSingleton('page/html_header')->getIsHomePage();
Will try a clinical test when i have time...
Tested on blank rwd theme on same installation, with same results. Need to test on clean Magento installation, to rule out any other modules etc.
Any news on this @m-overlund?
Not really. Still need time to do a clean test, to get any further...
And still the same after updating to latest turpentine version.
—
On Mon, Aug 31, 2015 at 4:45 PM, Miguel Balparda notifications@github.com wrote:
Any news on this @m-overlund?
Reply to this email directly or view it on GitHub: https://github.com/nexcess/magento-turpentine/issues/886#issuecomment-136394782
Hmm...
Works in Firefox now, on my computer at least. (using inverted logic for the isHomepage check though)
But both Google Chrome and IE11 doesn't work as expected.
The "Billigt brændsel på nettet"
heading doesn't get outputted in the HTML of www.fyr-selv.dk neither on frontpage nor on other pages.
Emptying cache and cookies doesn't change a thing.
@m-overlund that's odd, I can't think of a reason why it would work in Firefox but not other browsers... And this on a clean Magento install with the sample data? Can you give steps to replicate in that scenario?
https://github.com/nexcess/magento-turpentine/issues/965#issuecomment-144739007 Fixed my issues by disabling block cache (and others).
I have the same issue . As per our theme (SM Market) the slider has to come only in the home page which is not happening after Varnish implementation. This is code below we have in our theme file to make the slider visible on home page. `$routeName = Mage::app()->getRequest()->getRouteName(); $identifier = Mage::getSingleton('cms/page')->getIdentifier();
if($routeName == 'cms' && $identifier == 'home'):
We are using SM Market theme. Our theme also using slider under the header block. To manage this I tried a different header
Please advise me. Your quickest help is appreciated.
Our site = http://dev.tresbizz.com
After upgrading to Magento 1.9.2.1 my cms home specific content doesn't show, when varnish is enabled. When using the varnish bypass cookie the content shows just fine.
I use route and identifier to check for the homepage:
Check www.fyr-selv.dk with and without varnish_bypass cookie for an example.