Introduce varnish_hosts_list and hook_varnish_hosts_alter() for purging host aliases

Critical feature for me as well. I'll probably try this out in the next few weeks.

I'd posted #981420: Cache clearing via expire module fails when using https on a separate subdomain which I've now marked as duplicate. This approach works well enough for that too.

There's another issue with the configuration I'm working with at the moment - when you have a www-secure domain for authenticated users, then you don't actually need to purge for the current host, only for the non-https site - since https content is never going to get into varnish anyway.

Not sure if that means we should change this to a hook_varnish_hosts_alter() (with the current host the initial value of the array), or add an alter on top of hook_varnish_hosts(), probably the former but leaving at CNR, will follow up with a patch in the next couple of days.

Here's a patch for hook_varnish_hosts_alter().

This patch is (at least partly) incorrect. The correct approach IMO is:
1) Alter pressflow to add a specific HTTP header on each page generated (not sure if this is actually needed), ie X-Pressflow: true
2) Alter _varnish_get_hosts() to look at basename(conf_path()), and use that as a base to initialize $hosts:
a) if it's "default" or "all" (*brrr*), initialize with ".*"
b) initialize with "(.*\.)*" . basename(conf_path())
3) Doing just 2 will expire more than you want to expire (for example if your site is example.com, and you store images on media.example.com, media.example.com shouldn't be cleared), so change _varnish_terminal_run calls along these lines:
_varnish_terminal_run("purge req.http.host ~ $host ...") -> _varnish_terminal_run("purge req.http.host ~ $host && req.http.x-pressflow == 'true' ...")

I like the approach in #4, but I think it would be a good idea to be able to specify the domains we want to use through the UI. If we don't it's pretty inflexible to add more domains, since you would need to alter your code to actually get it working. We could get this in however, and add the UI components as a separate patch?

I agree with @fabsor at #4

In effect, I would prefer this #981420: Cache clearing via expire module fails when using https on a separate subdomain

+1 on the approach - sites using Domain Access could really use this.

This patch needs a reroll. Also, I think both the initial patch and the patch in #4 needs to be merged so that we have both an alter and a real hook that can be implemented.

I recently ran into this issue with a client using Domain Access to manage multiple "microsites." I made the following changes:

• I re-rolled the patch from #4 against the latest 6.x-1.x-dev (master branch)
• Includes the new alter hook: hook_varnish_hosts_alter()
• I added an admin interface (mentioned in #6, also needed by client) to specify additional hosts
• Also added checkbox to optionally disable including the base host

Hope this helps!

Re-rolled for the current 7.x-1.x branch. Also, updating the issue description to better reflect the direction that this issue has taken.
Can I get someone to test this and (hopefully) RTBC it, so we can have a shot at seeing it included in the 7.x-1.0 release?

Note:
VARNISH_SELECTIVE_CLEAR has a dependency on EXPIRE module at the moment in varnish.admin.inc.

Any other module currently using hook_expire_cache will no longer function. I think we may need to look at removing the EXPIRE module check in varnish.admin.inc.

Normally I would say breaking a feature's compatibility would consider a 'block' but considering the way the GUI is laid out and written and that Expire is the normal module used I would more agree with the ticket author that this is a 'bug' that should be fixed up and that is probably worth letting it pass and open another issue to deal with the EXIPRE dependency if the need comes up.

Code Readability:
7x cleaned up a lot of code that 6x had slightly less readable. Patch #11 would remove some of that cleanup

+    $purge = implode('$|^'. $base, $paths);
+    $purge = '^'. $base . $purge .'$';

change to

+    $purge = implode('$|^' . $base, $paths);
+    $purge = '^' . $base . $purge .'$';

On both Patch #10 and Patch #11 would make for more readable code

Otherwise minus the code cleanup, and comment I have above both patches work as described in my labs.

If we could clean at least #11 (but preferably both) I would be willing to RTBC.

Hello All,

Someone else just mentioned to me:

https://drupal.org/node/1323418#comment-5753202

Apparently varnish_purge wasn't added untill some time after varnish_expire_cache() and fabsor has expressed a displeasure in the past about breaking the chain.

I still think it it is a bug as carlos8f said but it might be good to split the patch into two issues (remove the IF check) and then RTBC the multi-hosts, and create a new issue of not checking so that fabsor can freely commit this one and then we can debate the selective clear.

Re-rolled the 6.x-1.x patch from http://drupal.org/node/859998#comment-6325386 against the 6.x-1.x branch HEAD.

Patch in #11 works like a charm for me when using the selective option. Tested with Varnish 2.1.x and the purges come in just fine!

If you don't use expire.module and you clear a cache with cid and without wildcard (for instance with cache_actions module in combination with rules, see http://www.wunderkraut.com/blog/caching-with-varnish-drupal-7-and-cache-...), you need this modification of the #11 patch, using the selected list of varnish hosts in varnish.cache.inc too.

Patch no longer applies.

Rerolled #16.

Rerolled patch against latest dev (currently 1.1).

Rerolled.

I'm not sure this is currently needed, given that there's already the varnish_front_domains variable? Maybe just add a hook_alter() to it in varnish_purge()?

Changing this to "needs work" because it needs to be changed to work with the existing variable.

This adds hook_varnish_front_domains_alter().

Thanks, added to latest dev.