Multi-site settings

[jasonheffner]

I found this repository looking for the the most recent wp-varnish code. I really like some of the updates and in fact started using the code on our site.

I use the following config in wp-config.php

global $varnish_servers, $varnish_version;
$varnish_servers = array('127.0.0.1:80');
$varnish_version = "3";
define('VARNISH_HIDE_ADMINMENU',1);

I don't want any of the options to be viewable by users on the network. I guess this is a feature request, and would like to see these settings in network admin pages, rather than on the site admin pages. Another plugin I use for domain mapping does this very well and could be an example. Either way I like having the options above.

[zaphoyd]

I've been working on a bunch of changes related to better multi-site support in this fork: https://github.com/HumanitiesComputing/wp-varnish

This includes:

• Ability to set version, timeouts, and admin console vs PURGE toggle via the config file.
• Ability to set secrets for admin console mode via config file.
• Updated admin page to reflect the new values that are globally settable.
• Detailed documentation for all of the wp-config.php options.

I've been running this in a production setup for a few weeks now and it seems to work. The only known issues are that I am not particularly familiar with the WordPress localization setup and I am not sure how to confirm that I didn't break that. I'd appreciate any feedback & testing from other multi-site users and would definitely like to see these features merged back into the main project if folks find them useful.

So far I have been focusing on using the settings file for global multisite stuff rather than using a network admin page. This makes version controlling the config and re-deploying stuff a lot easier. I haven't looked to closely into what it takes to make a network admin page and whether or not the plugin can still have site-local admin pages at the same time.

[jasonheffner]

I installed it on a dev system and some of the changes do look nice. I haven't had a chance to test out some of the new features, but so far it is working after some quick tests. I put the changes above back in so I could lock down the site admin pages. If you are developing for multi-site a network admin page with an option to expose purging to users might be useful. You'd probably have to code for those not running multi-site as well.

Your sample wordpress.vcl file is nicely written, but not as aggressive as I was getting a very low stat rate when I tested it when I ran varnishstat and apachebench. I use the following config pieced together from several sources in conjunction with domain mapping.. I include it if it helps..

backend web1 {
    .host = "127.0.0.1";
    .port = "8080";
}

# Define the director that determines how to distribute incoming requests.
director default_director round-robin {
  { .backend = web1; }
}

acl purge {
  "localhost";
  "127.0.0.1";
}

sub vcl_recv {
   set req.backend = default_director;

  if (req.url ~ "wp-(login|admin)|login" || req.url ~ "preview=true" || req.url ~ "xmlrpc.php") {
    return (pass);
  }

  # Use anonymous, cached pages if all backends are down.
  if (!req.backend.healthy) {
    unset req.http.Cookie;
  }

  if (req.request == "PURGE") {
     if (!client.ip ~ purge) {
        error 405 "Not allowed.";
     }
        return (lookup);
  }

# Properly handle different encoding types
if (req.http.Accept-Encoding) {
  if (req.url ~ "\.(jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf)$") {
    # No point in compressing these
    remove req.http.Accept-Encoding;
  } elsif (req.http.Accept-Encoding ~ "gzip") {
    set req.http.Accept-Encoding = "gzip";
  } elsif (req.http.Accept-Encoding ~ "deflate") {
    set req.http.Accept-Encoding = "deflate";
  } else {
    # unkown algorithm
    remove req.http.Accept-Encoding;
  }
}

# Force lookup if the request is a no-cache request from the client
if (req.http.Cache-Control ~ "no-cache") {
return (pass);
}

## Default request checks
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "TRACE" &&
req.request != "OPTIONS" &&
req.request != "DELETE" &&
req.request != "PURGE") {
# Non-RFC2616 or CONNECT which is weird.
return (pipe);
}
if (req.request != "GET" && req.request != "HEAD" && req.request != "PURGE") {
# We only deal with GET, PURGE and HEAD by default
return (pass);
}

  if (req.url ~ "\?(utm_(campaign|medium|source|term)|adParams|client|cx|eid|fbid|feed|ref(id|src)?|v(er|iew))=") {
    set req.url = regsub(req.url, "\?.*$", "");
  }
  if (req.http.cookie) {
    if (req.http.cookie ~ "(wordpress_|wp-settings-)") {
      return(pass);
    } else {
      unset req.http.cookie;
    }
  }

  # Allow the backend to serve up stale content if it is responding slowly.
  set req.grace = 10m;

  # Use anonymous, cached pages if all backends are down.
  if (!req.backend.healthy) {
    unset req.http.Cookie;
  }

}

sub vcl_hit {
        if (req.request == "PURGE") {
                purge;
                error 200 "Purged.";
return (deliver);
        }
}

sub vcl_miss {
        if (req.request == "PURGE") {
                purge;
                error 200 "Purged.";
return (fetch);
        }
}

sub vcl_fetch {
  if (req.url ~ "wp-(login|admin)|login" || req.url ~ "preview=true" || req.url ~ "xmlrpc.php") {
    return (hit_for_pass);
  }
  if ( (!(req.url ~ "(wp-(login|admin)|login)")) || (req.request == "GET") ) {
    unset beresp.http.set-cookie;
   set beresp.ttl = 1h;
  }
  if (req.url ~ "\.(gif|jpg|jpeg|swf|css|js|flv|mp3|mp4|pdf|ico|png)(\?.*|)$") {
    set beresp.ttl = 365d;
  }
  # Allow items to be stale if needed.
  set beresp.grace = 10m;
}

sub vcl_deliver {
# multi-server webfarm? set a variable here so you can check
# the headers to see which frontend served the request
#   set resp.http.X-Server = "server-01";
   if (obj.hits > 0) {
     set resp.http.X-Cache = "HIT";
   } else {
     set resp.http.X-Cache = "MISS";
   }
}

[jasonheffner]

btw.. thanks for all the hard work. I'll keep testing and hope to go production next week. Any chance of a consolidated release back to WordPress.org?

[pkhamre]

I have that on my todo-list, but I don't have much time for this project as I wish. My plan is to set up automatic synchronization from GitHub to the wordpress.org subversion repository.

I can provide credentials if anyone is interested in helping out.