Feature Request: Varnish support

[raamdev]

It would be nice to have support for running Varnish with Quick Cache, for those site owners who wish to do that (see this article that describes an example setup that includes Varnish + WordPress Caching plugin).

Presently, site owners who run Varnish with Quick Cache simply see a Quick Cache note in the source about Quick Cache not caching the page because $_SERVER['REMOTE_ADDR'] === $_SERVER['SERVER_ADDR'].

It would also be nice to support purging a local Varnish cache whenever the Quick Cache cache is purged. W3TC has this available in the 'Reverse Proxy' section:

---

Support threads mentioning this feature request

• https://websharks.zendesk.com/agent/#/tickets/3880

[raamdev]

Also referencing this page on WordPress.org where Varnish is recommended several times: http://codex.wordpress.org/WordPress_Optimization/Caching

[jaswrks]

Quick Cache note in the source about Quick Cache not caching the page because $_SERVER['REMOTE_ADDR'] === $_SERVER['SERVER_ADDR'].

This should already be resolved by the latest release, after improvements in our IP detection. We no longer rely solely upon $_SERVER['REMOTE_ADDR'] being configured properly. Varnish sends HTTP_X_FORWARDED_FOR which is now detected by ZenCache even if the web server configuration get's it wrong; i.e., does not propagate this to $_SERVER['REMOTE_ADDR']

It would also be nice to support purging a local Varnish cache whenever the Quick Cache cache is purged. W3TC has this available in the 'Reverse Proxy' section:

A short-term workaround (perhaps a better long-term solution) is for us to simply provide a set of instructions on how to do this. ZenCache already makes it possible to call upon other routines when the cache is cleared.

<?php
$varnish_ip = 'xxx.xxx.xxx.xxx'; // Configure this.

$purge_url = 'http://'.$varnish_ip.'/.*';
wp_remote_request($purge_url, array(
  'method' => 'PURGE',
  'headers' => array(
      'Host' => $_SERVER['HTTP_HOST'],
      'X-Purge-Method' => 'regex',
  )));
?>

[raamdev]

This should already be resolved by the latest release, after improvements in our IP detection

Oh, you're right! Thanks for pointing that out and updating this. :-)

A short-term workaround (perhaps a better long-term solution)

Are you opposed to me adding a new options panel called "Reverse Proxies" that allows a site owner to list one or more reverse proxy IP addresses to be purged when the cache is purged?

Having such a panel would give us the opportunity to explain a bit how ZenCache fits in with reverse proxies as well as link over to a KB Article for more information (which could explain that if they want even more control over what happens, they can use the "Process Other Custom PHP Code?" section). Having a new options panel for this would also be one more selling point for ZenCache Pro (with screenshots of that panel, etc.).

[jaswrks]

Sounds great! We should probably include the word "Opcache" in the title also, or mention it somewhere. In addition, we should update that code sample to include the new PHP 5.5+ Opcache extension. We currently have apc_clear_clear(), but there is also the newer/better opcache_reset() http://php.net/manual/en/function.opcache-reset.php

Maybe it's worth adding two new panels. One for each.

[jaswrks]

By each, I mean, one for Varnish (Reverse Proxies) and one for Opcode.

[raamdev]

one for Varnish (Reverse Proxies) and one for Opcode.

Great idea! Thanks for the suggestion. I think a separate option panel would be good for this. I'll open a separate GitHub issue.

[majik12345]

We Comet cache still doesnt work properly with varnish, it is still sending out no-cache headers. With W3 total cache, it just works out of the box with varnish, i'm not sure what the issue is with comet cache yet but it doesn't hit my cache... though I'm sure its because of these no-cache headers that appear, even when I see appropriate headers in nginx. Though looks like comet cache hits index.php?q= something. Probably can add rewrite rules in nginx to try /cache/comet-cache/something first before that, I havent looked into quite how the cache distribution works in comet cache yet.

[jaswrks]

@majik12345 writes..

it is still sending out no-cache headers

Have you seen this?

[majik12345]

Yes, changing that option had no effect. Still got no-cache headers and varnish wouldn't cache page...

[Helmi]

Hey there,

I'm just attaching this to this issue as support pointed me here. I have a similar issue with the Nginx Cache that is basically working great with comet cache until it comes to purging.

The nginx helper plugin currently is caring about purging the cache when new content is created but whenever comet cache decides to generate new compressed js/css files or something else happens in comet cache that changes the URL of compressed files the nging cache knows nothing about it the cache of Nginx doesn't get purged.

Here's the nging helper plugin that cares about purging https://de.wordpress.org/plugins/nginx-helper/ - all the stuff comes from EasyEngine (http://easyengine.io) - maybe it could be a good thing to talk to these guys to be one of the caching plugins to work with their setup. Currently they are offering ready made setups for W3TC and WPSC.

cheers. Frank

[raamdev]

@Helmi Is that Nginx Helper related to Varnish? This GitHub issue is specifically referring to Varnish, but when I looked at the plugin page you referenced it just says "fastcgi/proxy cache or redis-cache".

[Helmi]

@raamdev no it's not directly related to varnish but to purging other caches from comet cache - i guess that it's why i was directed to this issue by support. I could of course repost that as a separate issue if you prefer.

[raamdev]

@Helmi Ah, sorry for the confusion. It sounds like whoever directed you hear from support did not clearly understand the issue. I've opened a separate GitHub issue for Nginx Helper: https://github.com/websharks/comet-cache/issues/812

[netsystemas]

Hello! This discussion is here since 2014. When we will have compatibility with Varnish? What Comet Cache waiting for?

Varnish is a path of no return. Comet Cache needs to give attention to Varnish.

abs Josimar

[robert1112]

Hi @raamdev I bought the pro version a while ago. I lately set up Varnish working properly and also add varnish snippet in Evaluate Custom PHP Code when Clearing the Cache described above. Cache and purge works well until I have Cloudflare proxy. After having http proxy via Cloudflare, purge is not working anymore.

Can you help debugging this? I am thinking of CF blocking the purge request for some reason? Thank you so much.