alecmuffett

Awesome, thank you. Inspired by this confirmation I am testing a workaround of adding /author/ to the Rejected URL strings, and I’ll check out the behaviour now and over the next 24h to check.

While I am here: is my theory correct please that Expert mode basically falls-back to PHP-caching if a cached page is available and servicing the request has not been usurped by {Apache,NGINX}?

My reason for asking is to find out the best way to be certain that pages are being served by the webserver directly from the filesystem, without having to call into PHP; and that such a fallback apparently makes doing-so rather hard (false-positives) unless PHP sets a header that’s distinct from the raw webserver, perhaps?

To recap the two Github comments that I reference above:

1/ … 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.

2/

okay, so I did a var dump to check FPM:

…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.

Status update: I am still operating with minimum-size font and have added a few posts, and the problem is reoccurring. I’m wondering whether the fact that the page /blog is configured to be my home page is somehow affecting which CSS gets used/delivered?

Hi @properlypurple!

I’ve done as you requested, plus erased the supercache so I am getting clean data.

As an aside: my experience *was* that all pages were impacted.

Now the result is a bit mixed-bizarre: the home /blog page seems fixed but pages 2, 3, 4… etc all seem to be fixed, and when the page is being rendered there seems to a visible “rethink” when some text would try to overflow the RHS boundary. Page 6 is fixed.

I will avoid posting anything for a while so those numbers stay constant for you.

The current page 5 is still impacted, possibly due to the quoted text on those pages (article title: Fixing EXPKEYSIG 74A9... deb.torproject.org and other content/articles on that page.

This was tested and observed both in Chrome and Brave (because easier to wipe data) but not in Firefox – which is fixed but does very hard breaks on the RHS for some text – which suggests that it’s something to do with the Chrome codebase.

Is there anything more I can do to help triage this, please?