Sigh The latest version of my go-to caching plugin, WP Super Cache, is marked as requiring WordPress 6.6 or later -- which means it won't install on ClassicPress (which is forked from WP 6.3) anymore.

TBH I've been worried about it ever since it started trying to upsell Jetpack features in the admin UI.

I guess I can try relabeling my copy as backward-compatible to see if the actual functionality still works, but even if it does, it's probably another sign I should look for an alternative that's committed to maintaining compatibility.

#ClassicPress #WordPress #WPSuperCache

Wygląda na to, że wtyczka ActivityPub dla WordPress działa z WP Super Cache bez kombinacji.

#ActivityPub #WordPress #cache #WPSuperCache

Today saw the release of updates to two plugins I work on. The first, unsurprisingly, is WP Super Cache, and it’s a bug fix release. It fixed a PHP8.2 warning, adjusted some labels on the settings page, solved a problem with “late init” and POST requests, and some other changes, but the major news I want to share is not about that plugin at all.

I’m on the Jetpack Boost team in Automattic, and for the last month or so, we’ve been working on adding a full-page cache to the plugin!

Jetpack Boost is already a pretty remarkable plugin, with what it does to CSS, JavaScript and images, so a page cache was an obvious next step.

If you’re already using WP Super Cache, but you’re not using any of the advanced features, I think you should give Jetpack Boost a go. It works really well at serving cached pages fast. Jetpack Boost will be a drop-in replacement if you have these features enabled in WP Super Cache:

You’ll have to disable WP Super Cache first before trying Boost Cache, as they both rely on the same mechanism to load. Disable Jetpack Boost to go back to WP Super Cache. You can enable Boost again, without using the Cache module, and the two plugins will happily co-exist.

I’ve been using it here for the last two weeks, and it has worked flawlessly. I post images daily on my photoblog, and they get shared to Mastodon, where the expected deluge of requests from hundreds of servers happens each time. Between Jetpack Boost and WP Rest Cache, my server barely noticed. Just like with WP Super Cache.

“If it performs just like WP Super Cache, why should I use Boost?” I hear you asking. For some, you’ll need the extra features of WP Super Cache, but otherwise, Boost may be just what you need. Apart from the cache, it also has remarkable features that will squash your CSS and JavaScript in various ways that load super quick. Give it a go, and let WP Super Cache handle the cache if you need to.

If you’re still here, read on, and I’ll give you a whirlwind tour.

Boost supports an exception list like WP Super Cache does, and logging of activities in a similar, but easier to use way.

To simplify caching, only requests by logged out visitors are cached now, but that’s the recommended way of using WP Super Cache too.

Developers: like WP Super Cache, it also supports the “DONOTCACHEPAGE” constant. If you define that while a page is being created, then Jetpack Boost won’t cache it. If you can enable it before the page loads, then the plugin won’t serve a cached page either, but that will be difficult since the cache system loads so early.

To learn more, there’s a fine manual to read. It explains in detail how to enable the cache and how to use it. Yes, I’m biased, but I think you should give Jetpack Boost a go! Caching helps a lot, but the extra CSS and JavaScript features help render the page quickly once loaded.

https://odd.blog/2024/03/11/gimme-all-your-cache/

#cache #Jetpack #JetpackBoost #WordPress #WPSuperCache

Når en bruker WP Super Cache så vil ikke nødvendigvis HTTP-felt taes vare på. Kanskje spesielt viktig hvis en ønsker å styre Cache-Control ved hjelp av f.eks. innstikksmodulen Cache-Control.

Når en da kjører f.eks.:

Så vil en før WSC (WP Super Cache) slår inn få følgende:

Når WSC har gjort jobben sin vil web-tjeneren svare:

En mangler da diverse Link-felt og får en Cache-Control som er satt noe kort av WSC. For å omgå dette kan en slå på:

Cache HTTP headers with page content.

(eller sette wpsc_save_headers i wp-cache-config.php til 1).

En skal da få noe slikt som dette:

https://aslakr.folk.ntnu.no/2024/01/hindre-wp-super-cache-a-endre-http-felt/

#HTTP #WordPress #WPSuperCache

Når en bruker WP Super Cache så vil ikke nødvendigvis HTTP-felt taes vare på. Kanskje spesielt viktig hvis en ønsker å styre Cache-Control ved hjelp av f.eks. innstikksmodulen Cache-Control.

Når en da kjører f.eks.:

Så vil en før WSC (WP Super Cache) slår inn få følgende:

Når WSC har gjort jobben sin vil web-tjeneren svare:

En mangler da diverse Link-felt og får en Cache-Control som er satt noe kort av WSC. For å omgå dette kan en slå på:

Cache HTTP headers with page content.

(eller sette wpsc_save_headers i wp-cache-config.php til 1).

En skal da få noe slikt som dette:

https://aslakr.folk.ntnu.no/2024/01/hindre-wp-super-cache-a-endre-http-felt/

#HTTP #WordPress #WPSuperCache

You might not be on Mastodon yet, but your blog could get a torrent of traffic from Mastodon, or other Fediverse network if it’s shared there.

If your website is mentioned there, it might be the “victim” of an inadvertent denial of service attack, as hundreds or thousands of servers request the URL in the 60 seconds or so afterwards. That is precisely what JWZ blogged about last month when his site was taken down by Mastodon servers.

Every time I do a new blog post, within a second I have over a thousand simultaneous hits of that URL on my web server from unique IPs. Load goes over 100, and mariadb stops responding.

JWZ on Mastodon Stampede.

JWZ has over 8,000 followers. Every time he shares a post on Mastodon, the instances (servers) where those followers live will send a request to his blog to generate a preview. Actually, two requests will be sent:

• A request for the wp-json embed for the page.
• A request for the page that was shared.

Eventually, he blocked the Mastodon user agent. That stops previews of his website showing up on Mastodon posts, but resolves the problem for his website.

Yesterday morning, I decided to see what effect sharing a link on my Mastodon account would have on my server. My Mastodon account has 1.8K followers. A far cry from the number of followers JWZ has, but still enough to test my server.

I wanted to test several scenarios:

• Caching the post before sharing.
• Changing Apache configuration.
• Sharing without caching on my server.

My server is at Linode. I pay an average of $24/month to run this site and my photoblog is on it too where I share a daily photo + link on Mastodon. It’s not a heavy-duty server that can withstand a huge amount of traffic.

If you’d like to skip the details, my server coped fine with sharing a URL from here to Mastodon. The load average went up for about 20 seconds, topping out at the max for about 5 seconds before things calmed down. It was responsive the whole time. Install a full-page caching plugin like WP Super Cache, Jetpack Boost and WP Rest Cache and your site will probably be fine. Jetpack Boost and the Jetpack Image Accelerator will help when human visitors arrive.

The first test resulted in:

• 261 requests for the page embed.
• 359 requests for the page itself.
• 1 minute load average topped out at 1.34 for 5 seconds.

The page was cached by WP Super Cache, but I had set the garbage collection TTL to 60 seconds and I believe it expired halfway through the test, so it had to generate the cache again. Once I adjusted that, and set the TTL to 600 seconds, the second test performed better. The page remained cached throughout:

• 273 requests for the page embed.
• 289 requests for the page itself.
• 1 minute load average topped out at 0.71 for 5 seconds.

The main points of my Apache configuration:

• Keep alives are disabled.
• 5 start servers
• Minimum 10 spare servers

When I reduced the start and minimum spare servers to 1, the next test took longer to complete, and the load average rose to 1.24, even on a fully cached page. This was expected as the server didn’t have the spare capacity to deal with the sudden traffic.

After reverting the changes to Apache, I disabled caching on my blog and shared another URL. The load average only rose to 1.12 for a very short time. I was pleased with that. While caching does help, my server could cope with that traffic.

I suspected that there was one hit per Mastodon instance on my site. I checked my logs and was proved right. For all the accounts that follow me on mastodon.social, only one request was made. That does mean the onslaught of requests isn’t as bad as it might be. Instead of 1,800 requests for a page, there were far fewer. I did notice that a Friendica instance requested one of my test URLs several times.

Mastodon and other Fediverse servers will start requesting a preview within a second of you sharing your post on the network. It helps if your server is running some sort of caching.

If you have many Mastodon followers or if you’re worried about a DDoS from Mastodon, the following will help:

• Make sure Apache/Nginx has the spare capacity to grow quickly and respond to a sudden torrent of requests.
• Install a caching plugin like WP Super Cache.
• Use “expert caching” in WP Super Cache which serves the cached page using mod_rewrite. That will mean your blog post is served almost as fast as requesting a text file from the server. No PHP is executed at all.
• Install WP Rest Cache as it will soon cache the embed page request.
• Install Jetpack and enable the Image Accelerator and Jetpack Boost for human visitors who come later.

This problem has existed for a long time. Popular blogs had the same issue when they published new content and people following their blogs (through RSS feed readers, remember them?) hit the server looking for the new post. At least with Mastodon, you can load the post in a private browser window and cache it before sharing it. I want to write a WP Super Cache add-on plugin that allows the site owner to preload a new post as it’s published. That will ensure the new content is ready for sharing. I haven’t started work on that yet, so don’t ask when it’ll be done. Maybe someone else will beat me to it and claim all the credit!

https://odd.blog/2023/01/02/the-mastodon-onslaught-on-your-blog/

#apache #Fediverse #JWZ #Mastodon #WordPress #WPSuperCache

EDIT: Updated for WP Super Cache 1.6.3 and newer.

More sites use cookie banners now that the GDPR is active but some are finding that their banners are misbehaving once they enable caching.

This is a similar issue to the one that happened to some page counter plugins in the past. The page counter wouldn’t increment.

When a cookie banner is clicked a cookie is set in the browser so the website knows this visitor has agreed to accept cookies. If the cookie is set then the cookie banner html is not sent to the browser.

I suspect the main issue is that the code that sets and checks if the cookie is set is PHP. Unfortunately because the page is cached then no PHP code is executed, and the cookie banner is displayed because it was originally cached that way.

Since WP Super Cache only knows about certain WordPress cookies it assumes everyone who doesn’t have those cookies is a first time “anonymous” visitor. It doesn’t know about your cookie banner cookie.

You have two options:

Using Javascript completely is a better solution because it runs in the browser on every page load but that might not be possible every time.

Otherwise, use PHP to get WP Super Cache to play nicely with your existing code. You basically need to run do_action( 'wpsc_add_cookie', 'cookie_name' ); after init so WP Super Cache adds the cookie name to its cookie list. This only needs to be done once, but you can leave it run all the time because it will only ever add the cookie name once. This also ensures the name is added again if the WP Super Cache configuration file is ever reset or deleted.

Substitute the name of the cookie (eucookie) for your cookie name.

When your plugin is uninstalled it should remove your cookie with the following:

For future reference, since cookie banners will hopefully not be around forever, here’s what they looked like in the deep, distant past of 2018. 🙂

https://odd.blog/2018/07/20/wp-super-cache-and-cookie-banners/

#cookieBanner #cookies #GDPR #irishblogs #WordPress #wpSuperCache