We have a pressflow6 site in acqua hosting service.we have varnish cache enabled.for clearing the cache on drupal views we used cache actions module. with rules.but after adding a content in to a category the view is updating for the logged in users.but not updating for anonymous users,i think the varnish cache is not getting cleared with my rule on cache actions. how to clear varnish cache for a perticular view in drupal/pressflow,and custom code is there to clear the cache, please help me.
Thanks,
Raghu
Many people use Purge and Expire.
See: http://www.acquia.com/blog/when-and-how-caching-can-save-your-drupal-site
and
http://drupal.org/project/purge
Related
I'm testing Varnish cache integration with Shopware6.
During Settings > Caches & Indexes > Clear caches Varnish is not involved at all.
Result: cache in Varnish is not purged and store continue to serve pages cached in Varnish.
Am I missing something or is Shopware lacking of this part of integration?
did you configure shopware, and set the path for the varnish?
https://developer.shopware.com/docs/guides/hosting/infrastructure/reverse-http-cache#configure-shopware
if shopware dosen't know the proxy, i't can't be purged.
I am using two application load balancers that are routing requests to 4 backend varnish servers. I got answers to configure the PHP file to purge the cache but I have no idea where to put it and how to execute.
For which type of PHP application are you trying to configure cache purging?
A custom application?
WordPress?
Drupal?
Magento?
Some other CMS or framework?
If you're using an existing platform, CMS, or framework, the documentation will probably state how to configure purging.
Varnish Configuration
Of course, the Varnish VCL code should also be tuned to process purges.
You can find more information about purging (and banning) in Varnish on http://varnish-cache.org/docs/6.0/users-guide/purging.html
Here are the questions you should ask yourself regarding purging. Maybe the documentation of your CMS or framework will answer these as well?
Are you trying to purge individual URLs?
Does your code have pattern matching in play to invalidate multiple URLs at once (uses bans in VCL)
If pattern matching is used, are you sending the invalidation pattern via an HTTP request header?
Does your invalidation code use the URL to identify objects in cache, or does it rely on tagged content?
Are you restricting access to the purging mechanism based on IP address or subnet. If so, please configure an ACL in VCL.
Many WordPress plugins rely on individual URL purging. Other WordPress plugins use bans through request header patterns.
Drupal uses bans, but has a system in place that tags content. The ban patterns don't match URLs, but tags.
Magento uses bans.
Conclusion
If you use a CMS or framework, the purging strategy is set in advance. It's just a matter of configuring your app and making sure the VCL can handle it.
If you have custom code, you have a choice, and you can implement purging or banning.
Please have a look at the user guide section about purging I mentioned above. It should help you understand the underlying mechanism.
Earlier today I asked a question on SO regarding a redirect in the htaccess file. The answer given to me was actually correct, but because I had failed to clear my cache, my browser was still using a cached version of the htaccess file without my update. After clearing my cache, the redirect worked as expected. I've just installed an SSL certificate for a different client and added some rules to redirect from HTTP to HTTPS. However, I'm thinking about the issue I had this morning. The customer, as well as their return visitors, would have cached the old htaccess file and therefore won't use the updated version. If this was a stylesheet or an image, I'd just add a version number, change the file name, or change the path, to "force" the update. I obviously can't do that here. Is there anything that can be done to force return users to use the updated htaccess file?
There is nothing you can do about other peoples cache I'm afraid. Eventually the cache will refresh and display the new changes. All it takes is a refresh of the page.
You can tell your website not to cache by using:
ExpiresActive On
ExpiresDefault A1
Header append Cache-Control must-revalidate
But I don't really see much point in doing that unless you're making constant changes to said page. If a client asks you to make a change that requires their cache to be reset, then just tell them to do so, so that they can see it.
On viviotech server - i am facing issue of cache the document. When i am adding new page like if i add page and dump test in it.
<cfdump var="test">
Then again changing the content of page. It is not showing updates to me. I have tried every option which i found to flush the cache or disable the cache. But nothing is helpful. I have also added headers and htaccess file with no cache code but that is also not helpful.
Cache can be turn off through blue dragon administrator link but that is also not working due to unknown reason and got no help from the support of vivio tech.
Can any one help me how i can flush the cache through code. I have bluedragon administrator code on server.
I have no experience with Varnish, so please bear with me.
We have inserted Google Tag Manager into a clients site. The Tag Manager injects Google Analytics tracking code (and nothing else) into the page. The clients technical service provider has now complained that the Tag Manager prevents the Varnish cache from working.
My guess is that this has nothing to do with the tag manager as such but is rather caused by the cookies from Google Analytics - apparently in the default configuration pages with cookies are not cached. However since I'm not very familiar with Varnish I cannot speak with any authority in the matter.
So my question is: is there any reason why Google Tag Manager itself (not any tags inside the tag manager) would invalidate a Varnish cache on each request ? A web search turned up nothing specific regarding Varnish and GTM.
Thank you for your time,
Eike
Google Tag Manager will not interfere with Varnish cache in any way. The reason being is that the requests for Google Tag Manager are sent to google-analytics.com, not your website.
The cookies are then set by google-analytics.com and are only sent between the clients browser and google-analytics.com.
This means that Google Tag Manager does not actually have any affect on your website apart from the initial Javascript being loaded from there.
In fact varnish does not validate any cookie that is created through javascript, only caches the "set-cookie header" of the http request.
The problem you may be having is, if the "DataLayer" is placed in the html code, the values of the variables do not change as they would be in cache.
To solve this problem, we must make another http call (ex. ajax) does not to cache, it returns the variables for DataLayer.