7

Not through Turpentine, but you can run this command (as root/sudo) to flush just the homepage (may need to adjust if Magento is not installed at the top level of your site): varnishadm ban.url '^/(?:index\.php/?)?$'


4

This could be caused by not correctly setting your cookie path. Try setting your cookie settings in Admin->Configuration->Web->Session Cookie Management if not already. Alternatively it may be a bug in varnish.


3

I'm one of the co-founders here at MageMojo and would be happy to help. Try changing your turpentine crawler ip from 127.0.0.1 to anything else. The reason is nginx is forwarding from 127.0.0.1 and turpentine will match regular requests: if (client.ip ~ crawler_acl || req.http.User-Agent ~ "^(?:ApacheBench/. *|.*Googlebot.*|JoeDog/.*Siege.*|magespeedtest\....


2

I once spent an hour trying to work out why pretty much same setup as yours was working on dev server, but not staging server. Use varnishadm's vcl.list and vcl.show to make sure the Turpentine VCL is actually loaded. Mine wasn't.


2

I would try it without the <method>ajax</method> And add a flush event. I copied this from a working customer's .../layout/local.xml: <reference name="cart_sidebar"> <action method="setEsiOptions"> <params> <access>private</access> <flush_events> ...


2

The VCL is saved to the path given by the turpentine_varnish/servers/config_file configuration option, which defaults to {{root_dir}}/var/default.vcl. See Nexcessnet_Turpentine_Model_Varnish_Configurator_Abstract::save(), which is called by Nexcessnet_Turpentine_Varnish_ManagementController::saveConfigAction().


2

My turpentine generates it to /var/www/WEBROOT/public_html/var/default.vcl To which I: ln -s /var/www/WEBROOT/public_html/var/default.vcl /etc/varnish/default.vcl You can change save file location under System -> Configuration -> Varnish Options -> Servers -> Config File Location under Default Scope Auto Apply will write the config file and ...


2

In the end, I needed to override (remove) the header block from turpentine_esi.xml in app/design/frontend/base/default/layout/local.xml. My local.xml: <?xml version="1.0"?> <layout version="0.1.0"> <default> <reference name="header"> <action method="setEsiOptions"> </action> <...


2

Thanks for sharing. I just installed the latest version from the devel branch to fix a very similar problem. To check if Varnish is caching you could use either of the following varnishtop commands, if you have access to the server. /usr/bin/varnishtop -i RxURL /usr/bin/varnishtop -i RxHeader -C -I \^HOST


1

Most likely the cause is SSL Termination or TLS Termination Proxy. I see your setting the SSL in Nginx itself, consider using Pound or if you are using a Load Balancer to terminate the SSL there instead of Nginx. If you are getting an exact 30 seconds delay then you are hitting a timeout most likely: https://github.com/nexcess/magento-turpentine/blob/...


1

It seems a problem with access parameter in your ESI block definition in layout file (assuming you've not edited more files, it should be app/design/frontend/base/default/layout/turpentine_esi.xml) The definition for this block should be something like this... <action method="setEsiOptions"> <params> <access>private</access&...


1

There is no way to invalidate the cache inside a cms page. So cache entire cms block or don't cache it at all..


1

you have probably only few options: use geoip mod and custom varnish config to pass proper geoip hash to backend. use "VCL Fix = on" in Turpentine settings, it will bypass request if no cookies or magento session. (caution: high load) set all geoip cookies and variables with javascript on client side. better to use option 1. but in different ...


1

Could it be because I am storing everything in RAM as VARNISH_STORAGE="malloc,12G" and there might be a default behavior of memory to just wipe out after every minute or second and I also need to save in SSD? or there could be another issue? No, if your Varnish is set up correctly this should not happen. If you say "First bite is always slow" than does ...


1

The issue is also intermittent. Many times, after fiddling with the settings, these extensions are again accessible, but given a day or so, the issue returns. The blacklist settings would be the ideal way to handle this scenario. This sounds quite strange - it sounds like your varnish settings (including the blacklist) are getting re-applied when you make a ...


1

I seem to have gotten this working by applying a fix I found of GitHub ticket 915. First off the fix I applied for my first error was misleading so I removed the file I created. rm app/code/community/Nexcessnet/Turpentine/misc/custom_include.vcl Then I merged the devel branch of the Magento-Turpintine repo with my Magento project as suggested in the ...


1

This could be related to external cache as initially formkey is not matching. Try to unset the product view block from cache. <reference name="content"> <block type="catalog/product_view" name="product.info" template="catalog/product/view.phtml"> <action method="unsetData"><key>cache_lifetime</key></action> ...


1

Having the same form key doesn't seem to cause me issues on chrome. (We're not using Turpentine but instead using some custom varnish configuration) Having said that we have a pass rule setup in varnish for anything on the checkout You could add something similar on a wilcard of checkout/cart/add which might do the trick.


1

<reference name="header"> <action method="setEsiOptions"> <params> <access>private</access> </params> </action> </reference> Also please refer this link https://rajeshganjeer.wordpress.com/2014/05/28/varnish-with-magento-terpentine/


1

I suspect your issue will have been resolved by a recent Turpentine update: https://github.com/nexcess/magento-turpentine/commit/66615b7cc987854e8671911ab6c3aa22afb808a2 Removed session generation Fixes issues #806, #345 and many others related to extra sessions, empty carts, etc. Causes Varnish to be bypassed on first page load for new sessions. ...


1

I've never used Turpentine, but I believe it uses hole punching. If the template in question is hole punched, it's likely unsafe to rely on data in the registry, since it might get rendered without the original action getting processed, and therefore there won't be anything in the registry. Update: As I say I'm not familiar with how exactly hole-punching ...


1

Mage::registry('current_category'); returns something only if you are on a category page. I see that you code is in the header. If you are on other pages than a category page $_category will be null so you cannot call different methods on it.


1

Varnishstat and Varnishlog will give you all the information you require. There are many plugins for Munin available that fully outline cache hits, purges/bans and ratios. Its very easier to monitor. What's more difficult is getting the content into the cache in the first place (if you've got a low traffic, or large catalogue site). If you are asking the ...


1

As you're not using a file based caching mechanism, Magento has no need to store files within the /var/cache/ folder - these are stored in Memcached and Database given you're configuration. If the solution previously gave you output in the /var/cache/ folder, then it's likely the configuration was cached from the previous set up.


1

There is no page in the module by default. Though, you could create your own page in the admin with a form to submit an URL. Within the controller you only need a few lines of code to actually ban a URL from the Varnish cache. $sockets = Mage::helper( 'turpentine/varnish' )->getSockets(); foreach($sockets as $socket) { $socket->ban( 'req.http....


Only top voted, non community-wiki answers of a minimum length are eligible