WordPress tips and tricks

If Tempesta FW serves a WordPress backend with caching enabled, make sure you’ve added

cache 2;
cache_fulfill * *;
cache_methods GET HEAD;

cache_purge;
# Allow purging from the container (upstream), localhost (VM) and the host.
cache_purge_acl 192.168.122.1 127.0.0.1 192.168.122.1;

The last two lines allow to PURGE invalid cache content on CMS updates (requires an extension on the WordPress side).

Web standards disallow "separator" symbols in cookie names, but WordPress may produce cookies with square braces in their names.

In default configuration tempesta-fw will reject requests with such cookie names with HTTP 400 Bad Request response. However this can be adjusted by setting custom cookie name character set.

Here is an example of cookie names with RFC-compliant token character set extended by [] symbols (Note: this would also affect other places that rely on "token" symbol set like including HTTP method name, header values and many more that are referred as token in HTTP specification):

http_token_brange 0x21 0x23-0x27 0x2a-0x2b 0x2d-0x2e 0x30-0x39 0x41-0x5b 0x5d-0x7a 0x7c 0x7e

To avoid problem with mixed content you need to force WP work over https protocol. To ensure WP will work over https just line to the Tempesta FW configuration file:

req_hdr_add X-Forwarded-Proto "https";

and

SetEnvIf X-Forwarded-Proto "https" HTTPS=on

to the Apache configuration file for the website (see an appropriate StackOverflow reply).

To allow overriding HTTP methods for WordPress must be used http_method_override_allowed directive (can be found on HTTP-security wiki page):

frang_limits {
    http_method_override_allowed true;
    http_methods POST GET PUT;
}

Website staging is mostly about handling 2 or more copies of your website, typically one production and one testing (staging) instances. While your production instance services your clients, you can safely do any enhancements, amendments and testing on your staging instance.

Being a web accelerator, Tempesta FW helps you to distribute your client requests between the staging and production instances. Besides a local staging instance, when you deploy a website staging instance on your workstation, there are 2 basic ways to deploy a staging instances.

Traditional way to deploy a staging instance for mywebsite.com is to use a 3rd-level domain like staging.mywebsite.com. This approach is taken by the most public WordPress hostings. The drawback of the approach is that you need to rewrite ALL links the whole website database (e.g. in case of WordPress) or even probably in static files from mywebsite.com to staging.mywebsite.com and back, when your deploy the changes on staging website to the production. For this case routing between the staging and production instances can be done on Tempesta FW side as:

srv_group default {
    server 192.168.100.4:8001;
}
srv_group staging {
    server 192.168.100.4:8002;
}

vhost mywebsite.com {
    proxy_pass default;
}
vhost staging.mywebsite.com {
    proxy_pass staging;
}

http_chain {
    host == staging.mywebsite.com -> staging.mywebsite.com;
    -> mywebsite.com;
}

I.e. all the requests having staging.mywebsite.com in the Host or :authority HTTP headers are routed to the staging instance. Here we use separate containers accepting requests on 8001 and 8002 ports.

The second approach, which doesn’t require URL rewrites, is to use different IP addresses for both the instance and just add the staging IP address to a local DNS resolver for all the people working with the staging instance. Obviously, the drawback for the approach is that we need additional IP address. The good news even for massive hostings could be that we don’t need a separate IP for the each of hosted website – we can just put all the staging instances on the same IP as we put all production websites on the original IP. In this case Tempesta FW can be configured as:

srv_group default {
    server 192.168.100.4:8001;
}
srv_group staging {
    server 192.168.100.4:8002;
}

vhost mywebsite.com {
    proxy_pass default;
}
vhost staging.mywebsite.com {
    proxy_pass staging;
}

http_chain {
    mark == 1 -> staging.mywebsite.com;
    -> mywebsite.com;
}

The difference from the previous example is just that now in http_chain we route requests based on mark value received from the Linux Netfilter instead of HTTP headers. Now we only need to set the mark value based on the IP address for a client connection, you can do this with:

iptables -t mangle -A PREROUTING -p tcp -d x.x.x.x -j MARK --set-mark 1