Some personal setup-specific lessons I’ve learned in the last few months with Discourse, wp-discourse, and Cloudflare. Sharing in case any of this is useful to anyone.
Environment:
- Discourse & Wordpress hosted on separate AWS EC2 instances in the same VPC
- Wordpress stack is nginx w/fastCGI caching + php8.3-fpm + redis + mariadb
- Using the wp-discourse plugin to link WP + Discourse together and embed discourse comments beneath blog posts
- Cloudflare proxies both Discourse and WP
- WP is using APO
1) Cheat a bit with the VPC
When I initially deployed things, I quickly ran into issues with Cloudflare trying to rate-limit or block the API traffic going between the web server and the discourse box. I thought about trying to figure out some exclusion rules, but as both servers are in the same AWS VPC, it was way easier to simply make host file entries on each to point each server’s hostname at its VPC address instead of its public DNS address. No more need to worry about cloudflare sticking its fingers in between WP & Discourse. Small change, big headache reducer.
2) Dealing with a race between wp-discourse and Apple News
I’d been having a weird intermittent issue for quite some time after setting up Discourse w/Wordpress where sometimes—not often, but sometimes—a newly posted Wordpress post would appear to visitors to have the old Wordpress-native comment block at the bottom instead of Discourse. The actual post was fine, with proper Discourse comments, but Cloudflare’s edge cache was picking up the post in the instant or two before the Discourse comments landed and was hanging onto the stale page.
I could not, for the life of me, identify a how or a why behind the behavior. It appeared random, with no apparent trigger. I scoured logs but didn’t see anything obvious.
So, I chalked it up to the interplay between all the different cache layers and used chatGPT to write a small mu-plugin to sitestep the issue by forcing WP to scream “DO NOT CACHE THIS” on new posts before the Discourse linkage lands, and then forcing one additional round of cache-clearing on the CF side after the comment thread is attached, to make absolutely sure nothing stale lingers in CF’s cache.
discourse-cloudflare-purge.php
<?php
/**
* Plugin Name: Discourse → Cloudflare Safe Cache for Comments
* Description: Prevents caching of single-post HTML until Discourse linkage exists; also purges Cloudflare when linkage lands.
* Author: Lee Hutchinson + ChatGPT
* Version: 1.6.1
*
* Changelog:
* 1.6.1 - Added timeout failsafe so that we're not emitting no-cache headers forever
* 1.6.0 — ADD pre-linkage no-cache gate (template_redirect) so edge/origin never cache the WP-native-comments HTML.
* 1.4.0 — Purge on added/updated postmeta + status transition; purge slash/no-slash variants.
* 1.3.0 — Credentials via wp-config.php constants only.
*/
if (!defined('ABSPATH')) exit;
/** Resolve Cloudflare credentials from wp-config.php */
function scw_dcfp_get_creds(): array {
$zone = defined('SCW_CF_ZONE_ID') ? trim((string) SCW_CF_ZONE_ID) : '';
$token = defined('SCW_CF_API_TOKEN') ? trim((string) SCW_CF_API_TOKEN) : '';
return ['zone_id' => $zone, 'api_token' => $token];
}
/** Discourse linkage meta keys (filterable) */
function scw_dcfp_meta_keys(): array {
$keys = ['discourse_topic_id', 'discourse_post_id', 'discourse_permalink'];
return apply_filters('scw_dcfp_meta_keys', $keys);
}
/** Build URLs to purge for a post (slash + no-slash, plus home + RSS) */
function scw_dcfp_build_urls(int $post_id): array {
$urls = [];
$permalink = get_permalink($post_id);
if ($permalink) {
$urls[] = $permalink;
$urls[] = (substr($permalink, -1) === '/') ? rtrim($permalink, '/') : trailingslashit($permalink);
}
$urls[] = home_url('/');
$urls[] = get_bloginfo('rss2_url');
$urls = array_unique(array_filter($urls));
return apply_filters('scw_dcfp_urls', $urls, $post_id);
}
/** Minutes since publish (UTC) or null if unknown */
function scw_dcfp_minutes_since_publish(int $post_id): ?int {
$post_time = get_post_time('U', true, $post_id);
if (!$post_time) return null;
return (int) floor((time() - (int)$post_time) / 60);
}
/** Low-level Cloudflare purge-by-URL */
function scw_dcfp_purge_urls(array $urls): void {
$creds = scw_dcfp_get_creds();
if ($creds['zone_id'] === '' || $creds['api_token'] === '' || empty($urls)) return;
$endpoint = sprintf('https://api.cloudflare.com/client/v4/zones/%s/purge_cache', $creds['zone_id']);
$response = wp_remote_post($endpoint, [
'headers' => [
'Authorization' => 'Bearer ' . $creds['api_token'],
'Content-Type' => 'application/json',
],
'body' => wp_json_encode(['files' => array_values($urls)]),
'timeout' => 10,
]);
if (is_wp_error($response)) {
error_log('[SCW CF Purge] WP_Error: ' . $response->get_error_message());
return;
}
$code = (int) wp_remote_retrieve_response_code($response);
if ($code < 200 || $code >= 300) {
$body = wp_remote_retrieve_body($response);
error_log(sprintf('[SCW CF Purge] HTTP %d. Response: %s', $code, $body));
}
}
/** Common gate: only act when linkage meta key written & post is public */
function scw_dcfp_should_trigger($post_id, $meta_key, $meta_value): bool {
$creds = scw_dcfp_get_creds();
if ($creds['zone_id'] === '' || $creds['api_token'] === '') return false;
if (empty($meta_value)) return false;
if (!in_array($meta_key, scw_dcfp_meta_keys(), true)) return false;
return (get_post_status($post_id) === 'publish');
}
/** Purge on added/updated Discourse linkage meta */
function scw_dcfp_on_post_meta_change($meta_id, $post_id, $meta_key, $meta_value): void {
if (!scw_dcfp_should_trigger($post_id, $meta_key, $meta_value)) return;
$urls = scw_dcfp_build_urls((int) $post_id);
scw_dcfp_purge_urls($urls);
}
add_action('added_post_meta', 'scw_dcfp_on_post_meta_change', 10, 4);
add_action('updated_post_meta', 'scw_dcfp_on_post_meta_change', 10, 4);
/** Purge on publish transition, if linkage meta already present */
function scw_dcfp_on_transition_post_status($new_status, $old_status, $post): void {
if ($new_status !== 'publish' || !($post instanceof WP_Post)) return;
foreach (scw_dcfp_meta_keys() as $k) {
if (get_post_meta($post->ID, $k, true)) {
$urls = scw_dcfp_build_urls((int) $post->ID);
scw_dcfp_purge_urls($urls);
break;
}
}
}
add_action('transition_post_status', 'scw_dcfp_on_transition_post_status', 10, 3);
/**
* NEW: Pre-linkage no-cache gate.
* Until any Discourse linkage meta exists on a published single post,
* emit strong no-cache headers so neither origin (FastCGI) nor Cloudflare
* can store the pre-linkage HTML that shows WP's native comment form.
*/
function scw_dcfp_prelinkage_nocache(): void {
if (!is_singular('post')) return;
$post = get_queried_object();
if (!($post instanceof WP_Post) || get_post_status($post) !== 'publish') return;
foreach (scw_dcfp_meta_keys() as $k) {
if (get_post_meta($post->ID, $k, true)) return; // linkage exists; cache normally
}
// In wp-config.php you can set: define('SCW_CF_LINKAGE_GRACE_MIN', 10);
$grace = defined('SCW_CF_LINKAGE_GRACE_MIN') ? (int) SCW_CF_LINKAGE_GRACE_MIN : 0;
if ($grace > 0) {
$mins = scw_dcfp_minutes_since_publish($post->ID);
if ($mins !== null && $mins >= $grace) {
// We’ve waited long enough; stop gating and let caching resume.
// (Optionally, trigger one purge to refresh edge with whatever is current.)
// scw_dcfp_purge_urls(scw_dcfp_build_urls((int)$post->ID));
return;
}
}
// Block caching for this response (origin + edge + browsers)
if (!headers_sent()) {
nocache_headers(); // Cache-Control: no-store, no-cache, must-revalidate, etc.
header('cf-edge-cache: no-cache'); // Extra hint for Cloudflare/APO
}
if (!defined('DONOTCACHEPAGE')) define('DONOTCACHEPAGE', true);
// Optional debug: uncomment for a few publishes
// error_log('[SCW CF Gate] Pre-linkage no-cache for post ' . $post->ID);
}
add_action('template_redirect', 'scw_dcfp_prelinkage_nocache', 0);
/** Optional: admin notice if not configured */
add_action('admin_notices', function () {
if (!current_user_can('manage_options')) return;
$creds = scw_dcfp_get_creds();
if ($creds['zone_id'] === '' || $creds['api_token'] === '') {
echo '<div class="notice notice-error"><p><strong>SCW Discourse → Cloudflare:</strong> Missing credentials. Define <code>SCW_CF_ZONE_ID</code> and <code>SCW_CF_API_TOKEN</code> in <code>wp-config.php</code>.</p></div>';
}
});
Note that this mu-plugin does API stuff to Cloudflare, and thus requires some constants to be defined in wp-config with your CF zone (SCW_CF_ZONE_ID) and API key (SCW_CF_API_TOKEN). You also might want to rename these constants.
This completely eliminated the problem behavior—it ceased the moment I deployed discourse-cloudflare-purge.php. But it still bothered the crap out of me. Why was it doing this? I could get the problem behavior to come back within a few days if I disabled the mu-plugin, so the root cause was still hanging around.
Eventually, after scrutinizing logs, I found the problem:
The WP site I run cross-pubs its content to Apple News using this plugin, which is regularly updated and has worked great for years. However, the apple news pub process triggers immediately on post publication, and sometimes, the behavior shown in the nginx log excerpt below happens. This excerpt starts with the “POST” event triggered by the author hitting the “publish” button in wordpress:
Messy nginx access log excerpt
[22/Dec/2025:06:15:40 -0600] spacecityweather.com [-] [Poster IP] | POST /wp-admin/admin-ajax.php HTTP/2.0 200 Ref: "https://spacecityweather.com/wp-admin/post.php?post=53600&action=edit" UA: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
[22/Dec/2025:06:15:40 -0600] spacecityweather.com [BYPASS] [Poster IP] | GET / HTTP/2.0 200 Ref: "-" UA: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
[22/Dec/2025:06:15:41 -0600] spacecityweather.com [BYPASS] [Poster IP] | GET /wp-admin/admin.php?page=stats&noheader&proxy&chart=admin-bar-hours-scale HTTP/2.0 200 Ref: "https://spacecityweather.com/" UA: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
[22/Dec/2025:06:15:41 -0600] spacecityweather.com [BYPASS] [Poster IP] | GET /wp-json/jetpack/v4/scan HTTP/2.0 200 Ref: "https://spacecityweather.com/" UA: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
[22/Dec/2025:06:15:41 -0600] spacecityweather.com [MISS] 57.103.65.197 | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2/ HTTP/2.0 200 Ref: "-" UA: "AppleNewsBot"
[22/Dec/2025:06:15:41 -0600] spacecityweather.com [MISS] 57.103.65.183 | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2/ HTTP/2.0 200 Ref: "-" UA: "AppleNewsBot"
[22/Dec/2025:06:15:41 -0600] spacecityweather.com [-] [Discourse server IP] | POST /wp-json/wp-discourse/v1/update-topic-content HTTP/1.1 200 Ref: "-" UA: "Discourse/2025.12.0-latest-585840225f344268cf72cb570ec0f069b83088a8; +https://www.discourse.org/"
[22/Dec/2025:06:15:41 -0600] spacecityweather.com [MISS] 57.103.65.175 | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2 HTTP/2.0 301 Ref: "-" UA: "AppleNewsBot"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [MISS] [Discourse server IP] | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2/ HTTP/1.1 200 Ref: "-" UA: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [-] [Discourse server IP] | GET /wp-content/uploads/2025/12/image-29.png HTTP/1.1 200 Ref: "-" UA: "Discourse/2025.12.0-latest-585840225f344268cf72cb570ec0f069b83088a8; +https://www.discourse.org/"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [-] [Discourse server IP] | GET /wp-content/uploads/2025/12/change.jpg HTTP/1.1 200 Ref: "-" UA: "Discourse/2025.12.0-latest-585840225f344268cf72cb570ec0f069b83088a8; +https://www.discourse.org/"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [HIT] [Discourse server IP] | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2/ HTTP/1.1 200 Ref: "-" UA: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [MISS] 2a01:b747:3003:206::32 | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2/ HTTP/2.0 200 Ref: "-" UA: "AppleNewsBot"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [HIT] 57.103.65.182 | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2 HTTP/2.0 301 Ref: "-" UA: "AppleNewsBot"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [BYPASS] [Poster IP] | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2/ HTTP/2.0 200 Ref: "https://spacecityweather.com/" UA: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
[22/Dec/2025:06:15:42 -0600] spacecityweather.com [HIT] 57.103.65.181 | GET /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2/ HTTP/2.0 200 Ref: "-" UA: "AppleNewsBot"
[Poster IP] is the redacted IP address of the WP post author, and [Discourse server IP] is the VPC address of the Discourse server.
[HIT] or [MISS] or [BYPASS] is the cache hit status of the local nginx fastcgi cache for that request and is a good helper indicator.
The new post URL is /its-beginning-to-feel-not-like-christmas-everywhere-you-go-2.
Briefly, what the log shows is the post being created, and then, before the Discourse plugin can do its thing, AppleNewsBot swoops in (triggered by post publication) and hits the newly-published permalink. (You can see Discourse building the post and grabbing images right below, as other Apple News servers also grab copies.)
This race was almost certainly the source of my stale pages showing up in CF’s edge cache, and the inconsistency is because sometimes Discourse wins the race and the first time the post lands in cache it has proper comments, and sometimes Apple News wins the race and the post doesn’t. The WP CF plugin has its own cache clearing logic, but it looks like it’s firing before Apple News.
Anyway, I feel a hell of a lot better knowing the why of the problem. I’m considering submitting an issue request to the apple news plugin maintainers, but I’m not sure if this problem is widespread enough to warrant dev attention. Plus, the mu-plugin (coupled with making sure nginx is smart about its own caching) completely obviates the problem for me anyway.
3) Trying to have my cake and eat it too by caching ajax responses for 60 seconds
The wp-discourse plugin has several ways to deal with comment caching on WP posts/pages, but to fit with the site owner’s requirements I opted for the ajax method of displaying comments. It’s pretty much exactly what I want and it works great, displaying new comments on WP posts almost as soon as they’re made on the Discourse side.
But I always have the specter of a high-traffic event looming—this is a weather forecasting site, and sometimes forecasts blow up. What if I’m suddenly hammered by users viewing embedded comments and all the ajax requests that generates?
Turns out we can abuse cloudflare a little bit and do some short-duration caching of ajax responses at cloudflare’s edge, to help shed some of that potential load. This requires another mu-plugin to tell WP what to do, and then a Cloudflare cache rule to tell CF what to do.
discourse-rest-edge-cache.php
<?php
/**
* Plugin Name: Discourse REST Edge Cache
* Description: Sets cache headers on WP-Discourse REST responses so Cloudflare can cache them (~60s at edge) while browsers revalidate.
* Version: 1.0.3
* Author: Lee Hutchinson + ChatGPT
*/
if (!defined('ABSPATH')) exit;
add_filter('rest_post_dispatch', function($result, $server, $request){
if (!($request instanceof WP_REST_Request)) return $result;
// Match the WP-Discourse namespace at the start of the route
$route = $request->get_route(); // e.g., /wp-discourse/v1/...
$attrs = method_exists($request, 'get_attributes') ? (array) $request->get_attributes() : [];
$ns = $attrs['namespace'] ?? '';
$is_discourse = ($ns === 'wp-discourse') || (is_string($route) && preg_match('#^/wp-discourse(?:/|$)#', $route));
if (!$is_discourse) return $result;
// Safe methods only
$method = strtoupper($request->get_method() ?: 'GET');
if ($method !== 'GET' && $method !== 'HEAD') return $result;
// Don’t cache personalized/authenticated requests
if (is_user_logged_in()
|| $request->get_header('authorization')
|| $request->get_header('x-wp-nonce')
|| $request->get_header('cookie')) {
return $result;
}
// Cache only successful responses
if (is_wp_error($result)) return $result;
$status = ($result instanceof WP_HTTP_Response) ? (int) $result->get_status() : 200;
if ($status < 200 || $status >= 400) return $result;
// Edge TTL ~60s, browsers revalidate; SWR smooths refresh
$server->send_header('Cache-Control', 'public, s-maxage=60, max-age=0, stale-while-revalidate=30');
$server->send_header('Vary', 'Accept-Encoding');
return $result;
}, 10, 3);
This causes WP to attach a Cache-Controlheader to those /wp-json/wp-discourse/v1/discourse-comments?post_id= calls it’s making. The s-maxage=60 is where I’m setting the length I want the response to stay in cache.
Cloudflare normally won’t cache this kind of request, so we need to gently encourage it to do so with a cache rule:
This rule marks paths with /wp-json/wp-discourse/ as eligible for caching, and then tells CF’s edge cache to hang onto them for however long the origin asks. In our case, we’re asking for 60 seconds. (We have to do this with the plugin instead of using that nice “input time-to-live” box in the third screenshot because the minimum TTL Cloudflare will let you set for free accounts is 2 hours and for Pro accounts it’s 1 hour, and I want way less than that.)
I figure this short-duration cache will help me a bit if a WP post blows up and 100,000 people start simultaneously looking at it—CF will shoulder a bit of the load, while still letting me maintain the appearance of having near-live updating comments.
Other than those items—none of which are wp-discourse’s fault!—CF and wp-discourse have been very easy to integrate. I am a happy customer. (And if I’m being honest, I’ve kind of enjoyed the excuse to tinker!)