Site health check: Page cache not detected

trellis
1

Trellis has always used nginx microcaching, basically page caching.

The WordPress site health check fails the page caching test on Trellis though,
as it expects one or more caching-specific HTTP headers and values for page caching being considered working.
cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status

The response header for the frontend front page is Cache-Control: no-cache, must-revalidate, max-age=0. This would not satisfy the page caching test in WordPress site health.

Although this is less of an issue with agency sites, I would still want to see all health checks pass.
Can the header checks be modified to detect a Trellis-specific page caching header or behavior for example?

2

Follow up:

Those are the HTTP response headers that a test PHP loopback request receives:

HTTP/2 200 
server: nginx
date: Fri, 15 Mar 2024 12:00:00 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: <https://example.com/>; rel=shortlink
fastcgi-cache: MISS
strict-transport-security: max-age=31536000; ;
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-ua-compatible: IE=Edge
content-security-policy: frame-ancestors 'self'
x-frame-options: SAMEORIGIN
<?php $url = "https://example.com/";

$curl = curl_init($url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_HEADER, true);
curl_setopt($curl, CURLOPT_NOBODY, true);

$response = curl_exec($curl);
curl_close($curl);

echo $response;

So I have to correct my assumption that Cache-Control: no-cache, must-revalidate, max-age=0 is added as HTTP response header, as this is set for outside requests, not for internal requests from nginx to PHP FPM.

A related Fastcgi-Cache HTTP header is added by Trellis, but not used by the WordPress site health check.

IMHO, the currently best approach (IMHO) would add the x-cache-enabled: true HTTP header to requests from nginx to PHP (fpm):

map $upstream_cache_status $header_x_cache_enabled {
  default true;
  BYPASS  "";
}

  # Extra header for WordPress (notably its Site Health check)
  add_header X-Cache-Enabled $header_x_cache_enabled;

(A fitting place can be after the aforementioned Fastcgi-Cache header directive, the map would be set before the server block).

For extending the configuration template:
(nginx-includes/wordpress-site.conf.child):

{% extends 'roles/wordpress-setup/templates/wordpress-site.conf.j2' %}

{% block server_before -%}
{{ super() }}
map $upstream_cache_status $header_x_cache_enabled {
  default true;
  BYPASS  "";
}

{%- endblock %}

{% block server_basic %}
  {{ super() }}
  # Extra header for WordPress (notably its Site Health check)
  add_header X-Cache-Enabled $header_x_cache_enabled;

{% endblock -%}

(group_vars/all/main.yml or environment-specific main.yml):

nginx_wordpress_site_conf: nginx-includes/wordpress-site.conf.child

Adding this to Trellis by default appears to be a good idea (no obvious side-effects, improving compatibility with WordPress core (site health check)).

Would this be also worth a WordPress core trac issue, that the Fastcgi-Cache HTTP response header is also used as page cache indication in the WordPress site health check?

1 Like