Having trouble getting this working on NGINX / Flywheel

[piperhaywood]

Thanks for this fantastic plugin @pfefferle! So excited to use it. :)

I’m reaching out to the community here to hopefully get some tips on how to get this working with NGINX, specifically on Flywheel (managed WordPress hosting).

I tried to install the ActivityPub and WebFinger plugins and they both appeared to install no problem. I adjusted the ActivityPub plugin settings so that author accounts were disabled and the blog-wide account was enabled, then set the blog profile ID to blog.

I then went to Mastodon to search for my blog username (@blog@piperhaywood.com), but it didn’t show up. Likewise for https://piperhaywood.com/@blog. I then tried forcing the issue by visiting https://vis.social/authorize_interaction?uri=@blog@piperhaywood.com (https://vis.social is the instance for my personal Mastodon account) and got the error “Unfortunately, there was an error looking up the remote account”.

I then checked the Site Health tool and saw the following two errors:

Author URL is not accessible

Your author URL https://piperhaywood.com/author/ph_admin/ does not return valid JSON for application/activity+json. Please check if your hosting supports alternate Accept headers.

WebFinger endpoint is not accessible

Your WebFinger endpoint https://piperhaywood.com/.well-known/webfinger?resource=acct:ph_admin@piperhaywood.com does not return valid JSON for application/jrd+json.

This was sort of understandable since I had author pages disabled via Yoast SEO. I would rather leave them disabled, but I went ahead and enabled them in order to see what would happen to these errors. The Site Health errors still didn’t go away.

I then visited https://piperhaywood.com/.well-known/webfinger?resource=acct:blog@piperhaywood.com to see if that would work, and that went directly to a default NGINX 404 page.

After some searching, I came across a few support forum threads that suggested altering the NGINX config. So I asked the Flywheel support team to add the following:

location ~* /.well-known {
        try_files $uri $uri/ /wordpress/index.php?$args;
}

(Which I’m hoping is correct. It seems like the majority of the WordPress install is in a directory above the public folder, in a folder called /wordpress)

After this change, if I run curl -i -H "Accept: application/jrd+json" https://piperhaywood.com/.well-known/webfinger?resource=acct:blog@piperhaywood.com I get the following response:

HTTP/2 301
referrer-policy: no-referrer-when-downgrade
cache-control: no-cache, must-revalidate, max-age=0
x-fw-version: 5.0.0
x-xss-protection: 1
x-fw-hash: 17f364r27j
x-fw-dynamic: TRUE
content-type: text/html; charset=UTF-8
x-content-type-options: nosniff
x-redirect-by: WordPress
location: https://piperhaywood.com/wordpress/?resource=acct:blog@piperhaywood.com
x-fw-server: Flywheel/5.1.0
server: Flywheel/5.1.0
accept-ranges: bytes
date: Mon, 18 Sep 2023 12:33:57 GMT
x-served-by: cache-lga21925-LGA, cache-lga21983-LGA
x-cache: MISS, MISS
x-cache-hits: 0, 0
x-timer: S1695040437.250995,VS0,VE228
vary: Authorization
x-fw-serve: TRUE
x-fw-static: NO
x-fw-type: FLYWHEEL_BOT
content-length: 0

Which doesn’t seem correct, since we need the content-type to be some sort of JSON.

This URL on the other hand (which I think that the other URL is supposed to redirect to?) does seem to return the correct JSON, I think:

https://piperhaywood.com/index.php?rest_route=/activitypub/1.0/webfinger&resource=acct:blog@piperhaywood.com

I tried flushing the cache and saving my permalink settings again, no change.

I then tried to add application/activity+json to the mime.types file since it wasn’t present, but it was unwritable. I got in touch with flywheel support, and they asked me to reach out here with further context on how they need to alter the config to support the ActivityPub and WebFinger plugins.

---

And that’s basically where I’m at now.

Should I ask them to add application/activity+json to the mime.types file? Is there anything else I would need to ask them to do, like the alternate Accept headers?

Do I need to ask them to disallow caching for any particular URLs? I know that pages and posts are cached for 1 hour, and I think other resources may be cached for up to 365 days.

Could the problem be related to the PHP modules that Flywheel does and doesn’t have enabled? More on those here: https://getflywheel.com/wordpress-support/php-on-flywheel/#php-modules

Any suggestions are very welcome!!

[pfefferle]

Hey @piperhaywood nice, that you are playing around with the plugin :) Let's see if we can get it to work!

WebFinger

It seems that /wordpress is the wrong path. The example settings from the FAQ are meant for users that have their blogs in subdirectories, not in the root folder.

If I call https://piperhaywood.com/wordpress in the browser I will be redirected to https://piperhaywood.com/wordpress-function-for-images-with-srcset/ (I think this is a WordPress feature thingy) and I end up on the same URL, when trying to call the WebFinger endpoint.

So maybe try using

location ~* /.well-known {
        try_files $uri $uri/ /index.php?$args;
}

instead?

Accept header/Content negotiation

The second thing is the content negotiation. If your caching mechanism does support content negotiation, it is fine. Then your cache will cache the files based on the Accept header. If not, you should ask for disallowing (at least) the author URLs for the cache.

You can check it with

curl "https://piperhaywood.com/author/ph_admin/" \
     -H 'Accept: application/activity+json'

These are the two main requirements to get found on Mastodon. WebFinger and Content Negotiation for profile/author URLs.

I am sorry, that it is so complicated!

[pfefferle]

Yes, sorry I was a bit busy (https://wordpress.com/blog/2023/10/11/activitypub/ 😉 ) and had some conferences over the last weeks. I will block some more time for support questions in november and hopefully we get your issue fixed then!

[piperhaywood]

No worries at all! Yeah the wordpress.com support is so amazing, kudos!

I’m hopeful that I’ll get it sorted myself before then, will keep you posted here. And if you don’t have time to take a look it is absolutely no problem, protect your personal time!

[piperhaywood]

A further update on this, for posterity more than anything.

We tried forcing the content type on the homepage (text/html; charset=UTF-8) and WebFinger endpoints (application/activity+json). Though we seemed to be getting somewhere with the endpoints, we were still seeing a blob of JSON returned when the Accept header was set to application/activity+json. This meant that there was still a risk of that JSON being cached on the homepage since Flywheel doesn’t support content negotiation with their full-page caching mechanism.

Since I need to keep caching for performance reasons, it seems like I can’t realistically use the Webfinger plugin on my site unless there is some way to prevent the plugin from spitting out JSON on the homepage.

@pfefferle No rush on this at all, truly. But if you have any tips at some point then I’d love to follow up with Flywheel (I’ve kind of hinted that it would be pretty cool to support this more broadly on their platform!). For now, I’ll put it down and enjoy following others’ WP sites on Mastodon.

[piperhaywood]

Another update for posterity:

We got it working, I think!

Ultimately, it seemed like the crux of the issue was the full-page caching.

Flywheel dug a bit further in to Fastly’s documentation (they use Fastly for caching) and found that they could add a Vary header to the NGINX config for content negotiation. They did that, and it seemed to start working immediately! Searching for @blog@piperhaywood.com on Mastodon surfaces my blog ActivityPub account (no user accounts because I have those turned off).

For future reference, this is the NGINX config tweak that got ActivityPub and Webfinger working on Flywheel with their Fastly caching setup:

location ~* /.well-known/webfinger {
    default_type application/activity+json;
    add_header Vary Accept;
    include internal-proxy.conf;
}

location ~* / {
    add_header Vary Accept;
    include internal-proxy.conf;
}

The internal-proxy.conf file is an internal file with platform-specific rules, some of which are sensitive so they can’t share it in full.

I have a feeling that you could probably just get away with the second location block, but everything is working smoothly now on my site so I’m not going to ask the kind folks at Flywheel to edit the config yet again. But if anyone else is doing the same, maybe keep that in mind!

[pfefferle]

We thought about adding the Vary header as opt-in feature! At the latest now this seems to be a good idea!

Thanks for not giving up and sharing the solution with us!

[piperhaywood]

Aha, interesting! Cool, will keep an eye out for that as a feature.

Thank you for your tips on things to tweak, got there in the end!

[alecmuffett]

Pardon me sticking my nose in here, but I'm just rebuilding my wordpress and I am having HTML returned by curl -v -sS -H 'Accept: application/activity+json' https://alecmuffett.com/article/author/alecm ...too, and for me I have identified the problem as WP-SuperCache (I nuked the cache and did the above request, and it returned JSON) so I am trying to work out a way to get SuperCache to ignore "application/activity+json" requests. Any ideas? - alec

[alecmuffett]

okay, so I did a var dump to check FPM: <?php var_export($_SERVER)?> ...and I can guarantee the result includes: 'HTTP_ACCEPT' => 'application/activity+json', ...so I can be certain that the Accept header is making it to the PHP stack; it seems like WP-SuperCache is ignoring it and treating "all the world's an HTML object?" For the moment I have disabled supercache and run my test suite, and with WPSC off everything now appears to be working OK (although it's not a fully comprehensive test) There are various pages online about enabling certain vars in certain code to disable WPSC; that may or may not be relevant. Another approach might be to adopt "Advanced" rather than "Simple" caching and use NGINX to avoid ever returning cached content for other than the appropriate content accept-types. But it would be nice to make WPSC a little smarter, if indeed that is where the problem rests. - alec

[alecmuffett]

@pfefferle what I am suffering isn't (from what I can see) an issue with WP-ActivityPub, but is apparently more with WP-SuperCache not honouring the "Accept" header.

Before I go and log an issue with WP-SuperCache, I was wondering if you had had any experience of this issue with WP-SuperCache elsewhere, that I could cite to them, please?

[pfefferle]

I pinged @donnchawp maybe he can help here.

[jeherve]

WP Super Cache should support it, it was added to the plugin earlier this year:
Automattic/jetpack#29456

Could this be caused by your plugin settings maybe? It may be worth posting them here, so Donncha can take a closer look.

[pfefferle]

@jeherve do you know if the standalone plugin will be updated from the monorepo?

[jeherve]

It has been, yes. That change made it to WP Super Cache on August 16:
https://wordpress.org/plugins/wp-super-cache/#developers

You can see the changes here:
https://plugins.trac.wordpress.org/browser/wp-super-cache/tags/1.10.0/wp-cache-phase2.php#L43

[alecmuffett]

Hi Jeremy! I have switched off WPSC for the moment, but I can fairly straightforwardly re-enable it if you would like to get the results of some tests. I was running WPSC in simple mode (ie: PHP-based caching) I think pretty much with defaults for everything else. I'm happy to go back and reset it to defaults and try once more, but what else would you want to see in terms of evidence and settings? Screenshots? Curl dumps?

…

On Wed, 25 Oct 2023, 16:27 Jeremy Herve, ***@***.***> wrote: It has been, yes. That change made it to WP Super Cache on August 16: https://wordpress.org/plugins/wp-super-cache/#developers — Reply to this email directly, view it on GitHub <#446 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGC4ECNMQWR3QIZQ6Q4AVLYBEVVJAVCNFSM6AAAAAA44Y7J2WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TGOBSHAYTA> . You are receiving this because you commented.Message ID: <Automattic/wordpress-activitypub/repo-discussions/446/comments/7382810@ github.com>

[jeherve]

I'm not WPSC expert, so I think screenshots of the settings page may already be useful. @donnchawp will know best. It may be that for the "Accept" header to be supported, you may have to be using expert caching.

[alecmuffett]

Hi @jeherve - I've shifted this thread over to https://wordpress.org/support/topic/wp-supercache-seems-to-ignore-non-default-accept-header/#post-17177317 and posted a link to settings there, too. As mentioned over there:

I’ve tried it with Supercache in Simple mode, and with it in Expert mode although with the latter I have, of course, had to manually tune NGINX to tune the accelerated page fetches; this has been complicated by the apparent behaviour that even in Expert mode, Supercache seems to fall back to PHP/Simple caching in the event that the request was not served directly out of NGINX? If so, it seems like even a move to “Expert” caching and making NGINX ignore the static-cached page for that URL when Accept is not text/html, is doomed as a potential solution.

I came to this conclusion because I switched on NGINX without modifying the NGINX config to serve cached pages direct from the filesystem... and I was astonished to find that I was still serving cached content. I've not tried debugging this before, but I presume that this means "when expert mode is enabled, simple/php-caching is still enabled as a fallback?" ; if so this makes it very hard to determine which mechanism is serving the cached content without (as I did) enabling NGINX low-level debugging.

[pfefferle]

@donnchawp just opened an issue and is working on a fix Automattic/jetpack#33968

See also https://wordpress.org/support/topic/wp-supercache-seems-to-ignore-non-default-accept-header/