Discourse Comments stuck on "Loading..."

Have you upgraded or changed any themes recently? Or do you really mean that you haven’t upgraded in years?

1 Like

Yes, that’s correct, I used the sitename placeholder just for clarity.
Dang, well it’s a relief that it sounds like Discourse embed functionality is not broken! Must be something on our end.

I checked the Discourse logs (discourse.sitename.com/logs) and just see a lot of deprecation notices like below:

Deprecation notice: SiteSetting.enable_personal_messages has been deprecated.

I can definitely try to disable the embed_truncate as well, will search for that next. But that functionality was working for years without issue, so I’m not sure why it would break…

1 Like

try looking at the dev tools console for errors when you click the show full post button. dev tools can be access via right click and “inspect” the errors will show up in red on the right side.

yea the embed feature is most definitely not broken. it’s a multiple times a day thing for my site.

latest beta is Discourse 3.1.0.beta4, stable release is 3.0.3: Security and bug fix release


I believe our setup is managed; I haven’t made any changes to it, but our Discourse dashboard shows a Discourse last updated date of April 18. Looking at the latest announcement linked to that, it appears that is 3.0.3.

1 Like

make sure you are also running the latest Discourse version. might also be worth seeing if the same thing is happening in safe mode.

That’s a good call, thanks! I just checked and see this error:

Uncaught DOMException: An invalid or illegal string was specified

postUp embed-application.js:6

onload embed-application.js:36

EventHandlerNonNull* embed-application.js:25

<anonymous> embed-application.js:66


postUp embed-application.js:6

onload embed-application.js:36

(Async: EventHandlerNonNull)
<anonymous> embed-application.js:25

<anonymous> embed-application.js:66

It’s so strange because I made no changes to the code or anything recently. However, I do recall I was using Cloudflare on the 2nd of this month to strengthen security; I may need to check for anything on that end that could be blocking scripts.

I saw a CSP error in the Developer Tools Console last time I checked into this, so maybe that could be the issue, potentially on Cloudflare’s end

1 Like

i suspect something to do with this.

i know that when our parent site edited their online content policy and security settings once, it blocked our embeds for a few days. the effect was different though and it blocked the embeds going the other direction, not posting them in our forum.

1 Like

Ooh, good call! Would you happen to know which security setting had to be altered to fix this?
I had made a few changes so just not sure which one specifically I should roll back.

no idea, i don’t manage that part of the site. i had to call the people who host it to change the security policy settings back.

yea something isn’t very happy about that button being clicked.

I was able to pinpoint what the issue was! I had reached out to our managed Discourse support and they provided an IP address that we’d previously added to a blocklist on our WAF, due to a high amount of traffic from that address. Turns out that IP address was required to be allowed in order for Discourse to communicate properly. I’m so glad it was not an issue on Discourse’s end!


yea a bit sounds similar to the issue i encountered. glad you got it fixed :slight_smile:


I think I might be having the same issue. I have these DOMException errors in my browser dev console. I don’t use Cloudflare, though. My blog that embeds the Discourse iframe is hosted by Netlify, Discourse itself by Communiteq.

I first thought this change was causing the issue:

But now I think it might be something else? Any help would be appreciated.

Do you have access to security and/or network settings from your server on Netlify? From my recent experience, if I was in your shoes, I’d check your security settings out to see if there have been any IP addresses blocked. I’d double check with Communiteq support as well, because they might be able to confirm the IP address(es) required in order for your Netlify server to communicate with Communiteq to successfully execute scripts needed to display Discourse resources.

1 Like

Hey! Thanks for trying to help!

I have reached out to Communiteq.

Not sure what I can do on the Netlify side but I will investigate. I doubt the issue is there though, because technically the requests are coming from the browsers of visitors to my site, right? If I understand correctly how this works, and please enlighten me if I don’t, this is client-side JavaScript executed in the browser of the site visitor. Discourse sees the host name of the server in the request, but not the IP. My blog server doesn’t communicate with the forum server. It’s a static blog installation anyway. It’s just HTML with client-side JavaScript. It uses a script to send the blog post data to Discourse and load stuff from the forum in an iframe.

1 Like

The issue was indeed a bug in the latest Discourse version. Communiteq is patching it on my forum instance. For more info see here:

Please note that this issue is a different one.

The issue in this topic was about the inability of Discourse to “Show full post” on Discourse because the embedded site refused to serve the contents of the blog post to Discourse.

The issue in @fabsh topic is the result of a (more recent) security patch in Discourse that contains an issue.


Hi, I’m posting an update to this, as some things have changed my investigation into this issue. The issue persists since updating to 3.0.4; all newly created articles are having issues displaying the embedded Discourse code. All articles created prior to this update have no issue, so it is not an IP address block that’s causing this.

It looks like Discourse in the most recent version has changed the logic of how posts are automatically created by the embed code, so now the new code requires the canonical URL. See the topic previously linked:

However, this fully breaks the embed functionality on sites like mine. I was previously using the Node ID in Drupal to embed, seen in the code below:

discourseEmbedUrl = "http://sitename.com/node/' . $nid . '";

This new Discourse code requires the canonical URL to be used instead, which results in duplicate topics being created if someone simply renames the article title. That’s the reason I was using Node ID, because it does not change.

Would it be possible to have this new canonical URL be optional? I tried changing my embed code to use it, but the Loading issue came back for all posts created using the old embed code.

So right now, with the new Discourse code running on my Production site, I’m stuck with either of these two options:

  • Newly created articles on Drupal show “Loading…” but never load the Comments embed block; old articles created before Discourse 3.0.4 load fine


  • Newly created articles on Drupal load the Comments embed block just fine, but all old articles created before Discourse 3.0.4 show “Loading…” but never load the Comments embed block

Is there a way to make this new feature optional? Having to choose between either of these options puts me in sort of a lose-lose situation.



Did you find a solution for your problem ? I managed to make embed comments work on my Drupal website, but only by using canonical URL.

Yes, we ended up having to switch to canonical URL. This resulted in us having to run a full database replacement on all existing topics to change their source URL to point to the canonical URL instead of Drupal’s node URL.

An additional huge problem arose from this as well, because multiple different redirects to URL aliases were in place from different iterations of our website, which was not a problem when using /node/12345 since it would always redirect to the same Discourse topic. As a result, we’ve been having multiple duplicate topics created for months now.

Frankly, I am deeply disappointed and bitter at Discourse for forcing this new update and not allowing canonical URL to be an optional setting. Shame on the developers for forcing this without even allowing it to be optional, because this creates an endless slog of headaches for Drupal users in particular – every time a post title is changed even, a duplicate topic will be created in Discourse, and the embed code is neither smart enough nor robust enough to handle this.

1 Like