Back

And after poking around this area to see what the author page, #WebFinger plugin, the #Nodeinfo endpoint returns, a side-quest is now a deep-dive into an old-ish article from @Gargron to try start to piece things together
https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/

(while still it is just nerding out, not sure if it will have any specific effect)

Now further rabbit hole of looking at various instance's Instance endpoint https://docs.joinmastodon.org/methods/instance/#v2, e.g. this very instance's: https://fosstodon.org/api/v2/instance but also others like @grafana's
https://grafana.social/api/v2/instance and discovering Mastodon Glitch edition https://glitch-soc.github.io/docs/
and a reminder of how images are blurred here for loading using #blurhash https://blurha.sh/ that looks pretty cool and would love to understand the process / see if it can be used well in code I maintain.

So now:
1) my caching was pretty busted before this (not _really_ bypassing PHP)

2) making these two plugins to share the work (accept:json to ActivityPub, anything else to W3TC) is unlikely,

3) at this point disabling page cache seems the right thing to do (there's still object cache which seems to work correctly for both).

I'm maybe just missing a benchmark to see the effect of these settings...

The results of a deep dive, spending probably way too much time in this, but that's what we do when the stakes are low: #WordPress #ActivityPub and #caching, in particular #W3TotalCache. https://gergely.imreh.net/blog/2023/02/when-wordpress-caching-is-not-what-it-seems/

@evantd what sort of settings change this would be? I'm using #nginx and #W3TotalCache adds its own config to it (as a generated file that is imported by the main nginx setup). Looking at it, no headers or accepted file types related logic in there.
Any other hints about what do you mean?

@imrehg I haven't configured any of the software you're using, so I don't know. I think you'd probably want it set as close to the origin at possible.

@arnandegans so the plugin would need to tell somehow the whole #WordPress instance (or just #W3TotalCache?) not to cache the authors' about page. (when it receives a regular query, return the HTML version, if "application/activity+json" type the the plugin take care of it.

It's an interesting proposition whether that plugin could set up that behaviour. I wonder if it's something down this line: https://wordpress.org/support/topic/disable-caching-for-a-specific-page/ (and thanks for the hint, it seems promising!)

@imrehg w3tc supports a thing called fragmented caching, which lets you exclude bits of a page from caching, for example a specific function while the header and footer are cached.
Alternatively you can have any piece of PHP define a global called DONOTCACHE to not cache that page. I use those methods in my plugin to rotate specific ads in an otherwise cached page.
My guess is that the activitypub plugin doesn’t do either and thus gets stuck while generating those json files.

@arnandegans I've looked deeper, and it seems a bigger issue really: the ActivityPub plugin renders authors, posts, and homepage as a compatible JSON if the accept header is added. I tried and can indeed set "DONOTCACHEPAGE" for these and it works as intended - for ActivityPub, but in fact then the cache plugin is completely useless (almost nothing is cached).
I looked at fragment caching but that also seems different https://github.com/BoldGrid/w3-total-cache/wiki/FAQ%3A-Developers#how-do-i-implement-fragment-caching

@arnandegans given my understanding how the nginx rules and page cache works, I think W3TC having a "bypass page cache for these headers" would be more to the point? Since once page cache is generated once, ideally the web request doesn't even touch wordpress just loads from disk, so no amount of wordpress code can change it unless the redirect rules allow.

@imrehg No idea, I'm not familiar with Nginx. But if that header works, that'll be fine of-course.

@arnandegans yeah, it was indeed. It turned out though that the plugin's generated nginx settings were such that it didn't actually control caching after all (so changing it had no effect on the final outcome). Wild goose chase if I've ever seen one. Oh, well.