Environment: Self-hosted Discourse on AWS EC2, with the Ubuntu 24.04 AMI. Host is an r7g.large with 2x vCPUs and 16GB RAM. Discourse is at version 3.6.0.beta1-dev (db974047e4) and is updated regularly. WordPress is at version 6.8.2, and the wp-discourse plugin is at version 2.5.9. Both Wordpress and Discourse are proxied (“orange-cloud”) behind Cloudflare.
Current wp-discourse settings: I am displaying Discourse comments for all topics, and I have “Load comments with Ajax” ticked. (Both the readers and the Wordpress site owners want new comments displayed ASAP beneath WP posts, so per the owners’ requirements I would prefer to leave “Load comments with Ajax” enabled.)
What I’m seeing: Generally, wp-discourse is working great. When a reader visits a WP post, their browser requests /wp-json/wp-discourse/v1/discourse-comments?post_id=XXXXX,where XXXXX is the expected post ID, and comments load without issue. New comments show up on the Wordpress side within a few seconds of being posted to DIscourse.
However, visitors’ browsers are also emitting a call to the same discourse-commentsURI when they visit any wordpress address on the entire site. The site’s homepage, comment archives, the about page, the contact page, author bio pages, static pages, search pages, everything. These requests are all for/wp-json/wp-discourse/v1/discourse-comments?post_id=undefined, and I’m getting ~20,000 of them in a 24-hour period (roughly corresponding to my total number of pages served).
I wouldn’t care much, except that servicing that many additional requests is creating a noticeable load on my WP origin server. It’s manageable now, but this site is a gulf coast weather forecasting site and during weather events (especially hurricanes) our daily view count can shoot up from its normal ~20k to between 1.5-2 million, and handling millions of post_id=undefined requests in a day would be challenging.
The only thing I can find here on meta that seems to have anything to do with this issue is this thread from 2019, where the given answer is “turn off loading comments with ajax.” As noted above, given the requirements I’m operating under, I’d prefer not to do that.
Here’s a representative undefined request. This one was generated when I accessed the site’s homepage:
Workaround: Since these requests don’t seem to be actually doing anything, I’ve implemented a Cloudflare WAF rule to respond to them at the CF level with an empty response body. This has completely eliminated the effects of the problem behavior—I no longer see the undefined requests at my origin, and I’m not wasting CPU generating responses.
Question: Is the sending of discourse-comments?post_id=undefined ajax requests for every single WP page the intended behavior of the wp-discourse plugin? It seems like it might be a little safer (or at least a bit more deterministic) to only send those requests when actually loading a WP post (or a page, too, if pages are enabled in the wp-discourse options).
Like I said, I’ve got a workaround in place that seems to be doing the trick and removing the extra load of handling those tens of thousands of spurious requests, so I’m stable and in a good spot. But it’d be nice to know if the behavior I’m seeing is by design.