{"id":2762,"date":"2023-02-12T12:20:21","date_gmt":"2023-02-12T04:20:21","guid":{"rendered":"https:\/\/gergely.imreh.net\/blog\/?p=2762"},"modified":"2023-02-12T18:49:51","modified_gmt":"2023-02-12T10:49:51","slug":"when-wordpress-caching-is-not-what-it-seems","status":"publish","type":"post","link":"https:\/\/gergely.imreh.net\/blog\/2023\/02\/when-wordpress-caching-is-not-what-it-seems\/","title":{"rendered":"When WordPress caching is not what it seems"},"content":{"rendered":"\n

When parts of a system are strongly interconnected, one can discover latent issues while debugging something completely different. This is what happened with this blog’s caching and integrating with the Fediverse.<\/p>\n\n\n\n

Fediverse adventures<\/h2>\n\n\n\n

I was part of The Great Twitter Exodus of 2022, and like many I’ve landed on Mastodon<\/a> (hey, hello, https:\/\/fosstodon.org\/@imrehg<\/a>). Mastodon and the whole Fediverse<\/a> and its build around the ActivityPub<\/a> protocol is technically very interesting and brings back a bit of retro-joy to me (which needs some reflections on why and how is retro joyful, but another time). This current blog is running WordPress<\/a>, and soon found that there’s a plugin to turn a WordPress blog into a my own ActivityPub node<\/a>. That seemed some excellent way to connect up tools and make a more inter-connected Internet (besides nerding out, if I’m fully honest).<\/p>\n\n\n\n\n\n\n\n

ActivityPub plugin<\/h3>\n\n\n\n

It was super easy to set up, and seemed to have worked well: take my author URL<\/a>, put it your Mastodon instance’s search, and voila, there’s a compatible profile which one can follow and interact with (to an extent, but still):<\/p>\n\n\n\n

\"Screenshot
How does my author profile look when searched on a Mastodon instance, this time on Fosstodon<\/a>. One can use either the author URL or the shortened address shown under the profile picture to find a person.<\/figcaption><\/figure>\n\n\n\n

It all seemed to have worked, but coming back after a while, but Site Health<\/a> popped up a critical issue. \ud83d\ude40 <\/p>\n\n\n\n

\"Critical
Critical problem showin in the WordPress Site Health page.<\/figcaption><\/figure>\n\n\n\n

Digging in into what the endpoint actually returned when setting what response format the client want to accept:<\/p>\n\n\n\n

curl --silent -H \"Accept: application\/activity+json\" https:\/\/gergely.imreh.net\/blog\/author\/gergely\/<\/code><\/pre>\n\n\n\n
I can see that it indeed doesn’t look like a JSON<\/a> file, instead the cached web content:<\/p>\n\n\n\n
\"Terminal
Terminal view of of the response to request to the JSON author page, showing cached HTML instead.<\/figcaption><\/figure>\n\n\n\n
Hot on your trail, W3 Total Cache<\/a> (W3TC)! I use this plugin to make this site (hopefully) more performant, but it’s not looking great in this instance. Fortunately I got some interesting pointers by asking none other the Fediverse<\/a> about this issue, and got some helpful pointers.<\/p>\n\n\n\n
W3 Total Cache<\/h3>\n\n\n\n
The way I understood how the W3TC plugin and my configuration worked was the following:<\/p>\n\n\n\n
    \n
  1. The plugin does some internal caching (opcode, objects,…) using  PHP, and something I don’t worry about much.<\/li>\n\n\n\n
  2. The main performance benefit is coming from generating page caches on disk that can be loaded quicker then regenerating the page.<\/li>\n\n\n\n
  3. Routing to those cached files is mostly through my nginx<\/a> web server’s configuration: the caching plugin creates an nginx configuration file with the relevant logic and redirects, so on the “happy path”  when the target page is cached, the request doesn’t even touch WordPress’ backend at all.<\/li>\n<\/ol>\n\n\n\n
    Disabling Caching for an Endpoint<\/h4>\n\n\n\n
    Based on the above (especially point 2), my train of thought started at “Can I tell W3TC not to cache that author endpoint if a specific header is received?” Looking at the W3TC FAQs<\/a>, there’s indeed a way to signal that, by disabling e.g. page caching when the plugin (ActivityPub in this case), by setting this inside the code path of the relevant page:<\/p>\n\n\n\n
    define('DONOTCACHEPAGE', true);<\/code><\/pre>\n\n\n\n
    Looking at the source code of the ActivityPub plugin<\/a>, I could find where in the data flow<\/a> one would set this, before the author template is returned. I tried it out and seemed to have worked. I’ve even opened a GitHub issue<\/a> so that hopefully a fix can be developed for everyone!<\/p>\n\n\n\n
    Looking further in the code (to do that fix), though, it’s not only the “author” page, but silently also all the posts and the front page has the same issue (of getting cached HTML when asking for JSON). \ud83d\ude40 If one disables caching on author + blogposts + frontpage, what else of note is left cached? Nothing really. And the plugin owner agrees<\/a>.<\/p>\n\n\n\n
    Route Request Based on Headers<\/h4>\n\n\n\n
    Let’s try instead routing the request based on headers: if a compatible “Accept” header is received, bypass the cache, and use what he endpoint returns. Here comes the issue about the 3rd point above: the nginx configuration and its use.<\/p>\n\n\n\n
    Ideally I would be able to add to the config a tests for this header, a check, roughly along the lines of this in nginx config::<\/p>\n\n\n\n
    if ( $http_accept = 'application\/activity+json' ) {\n # switch vars not to cache\n}<\/code><\/pre>\n\n\n\n
    Following the installation steps<\/a>, when Page Caching is enabled in W3TC generates<\/a> an extra nginx.conf<\/code> file that governs what happens. There are a lot of various checks (e.g. do not cache on POST<\/code> requests, do not rewrite paths if the predicted cache file location is empty….) I’ve been following the generated file, and tried to adjust the caching behaviour. To debug, I turned to adding various headers<\/a> to the response, as it was easier than messing with the nginx logging rules. For example adding this just before the last rewrite rule kicks in would show the variable’s value that would decide if a rewrite happens:<\/p>\n\n\n\n
    add_header X-gergely-debug \"rewrite-$w3tr_rewrite\";<\/code><\/pre>\n\n\n\n
    Looking at this, in every situation I was getting “no rewrite to do” outcomes, and it wasn’t in the end too much a surprise, as the logic in that file seems to be flawed: generating on disk file locations from the request incorrectly and thus never finding anything (and\/or some of my misconfiguration? But there are definitely things which look plain wrong).<\/p>\n\n\n\n
    But while the nginx rules shrugged, in the same time my web requests were returning the files from disk! If I rewrote the generated files, I got the modified version back. Then, frustrated, even emptied out nginx.conf<\/code> to try to “break” caching – and it continued to work! \ud83d\ude43<\/p>\n\n\n\n
    So I guess the actual behaviour was different from the above 3. point, and rather:<\/p>\n\n\n\n