Discourse Comments stuck on "Loading..."

[spectrum]

Hello,

Over the past few days, in our Discourse, we have noticed that the “View Full Post” button remains at “Loading…” when it’s clicked:

Additionally, new Discourse comments have stopped showing from our embed from within our Drupal website. We have been successfully using the JavaScript embed instructions from below for years:

Embed Discourse comments on another website via Javascript

Discourse has the ability to embed the comments from a topic in a remote site using a Javascript API that creates an IFRAME. For an example of this in action, check out Coding Horror’s blog. The blog is run via Ghost but the comments are embedded from his Discourse forum. One important thing to note with this setup is that users have to navigate to your forum to post replies. This is intentional, as we feel that the posting interface on a Discourse forum is currently much richer than what we …

However, for some reason this seems to have stopped working lately. I believe the last working post was around the 1st of this month. Older posts do display in Discourse and in the embed module, but in newer recent articles, the Discourse block just hangs on the Loading… text.

Our Discourse Drupal module loads from the following code:

<div id="discourse-comments">
 <script type="text/javascript">
            var discourseUrl = "https://discourse.sitename.com/",
            discourseEmbedUrl = "http://sitename.com/node/' . $nid . '";

            (function() {
              var d = document.createElement("script"); d.type = "text/javascript"; d.async = true;
              d.src = discourseUrl + "javascripts/embed.js";
              (document.getElementsByTagName("head")[0] || document.getElementsByTagName("body")[0]).appendChild(d);
            })();
          </script>
 </div>

I have confirmed that the “javascripts/embed.js” file still exists at the same path.
This is the block that is shown on article pages; it shows just “Loading Discussion…” lately though:

We have not made any changes within the past few years to our Discourse embed or setup. Have there been any changes recently to Discourse functionality that would break this? Any help in fixing this would be greatly appreciated!

[Lilly]

we use the same embed functionality on our site. i assume the discourseUrl and discouseEmbedUrl are not what you posted above and instead your forum’s relevant urls?

otherwise, the code looks ok. i know the embed functionality is working for up-to-date Discourse beta. we’ve had a ton of embedded posts this past week. i find it odd that it is embedding the first part of the post but the show full post button isn’t working. ours load immediately

did you check the console for errors?

you could always try disabling the embed_truncate setting just to see if it posts the whole text. that might help narrow down the cause of the issue.

[pfaffman (Jay Pfaffman)]

@spectrum

We have not made any changes within the past few years to our Discourse embed or setup

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

[spectrum]

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…

[Lilly]

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

[spectrum]

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.

[Lilly]

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

[spectrum]

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

[embed-application-4e18c443be26cb7c50c56d1a8f39fcf176af9b4ae8e42243648f33c23d9b7eb9.js:5](https://conversation.spectrummagazine.org/assets/embed-application-4e18c443be26cb7c50c56d1a8f39fcf176af9b4ae8e42243648f33c23d9b7eb9.js)

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

[Lilly]

@spectrum

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

[spectrum]

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.

[Lilly]

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.

[Lilly]

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

[spectrum]

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!

[Lilly]

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

[fabsh (Fabian A. Scherschel)]

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:

Change in 3.0.4 broke my embedding use case

I have the suspicion that this change broke how I use embedding on my website. Can someone point me to what exactly was changed? I use Discourse to create topics for posts on my blog (as a commenting system). My website is divided into two parts for two languages, so I use two hosts to filter the English (/blog/somepost) and German (/de/blog/somepost) posts into different forum categories. [screenshot-forum.fab.industries-2023.06.16-02_30_47] Posts from the German side of the website aren…

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

[spectrum]

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.

[fabsh (Fabian A. Scherschel)]

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.

[fabsh (Fabian A. Scherschel)]

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

Change in 3.0.4 broke my embedding use case

So main has this TopicEmbed.import_remote(@embed_url, user: User.find_by(username_lower: username.downcase)) and stable has this TopicEmbed.import_remote(user, @embed_url) Note the order of the parameters. Now the backport of the security patch changed the function signature on stable to the new parameter order,so def self.import_remote(import_user, url, opts = nil) became def self.import_remote(url, opts = nil) and now the url parameter receives a User object. Changing the function ca…

[RGJ (Richard - Communiteq)]

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.

[spectrum]

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:

Embedding is BROKEN in 3.0.4 (stable)

I have the suspicion that this change broke how I use embedding on my website. Can someone point me to what exactly was changed? I use Discourse to create topics for posts on my blog (as a commenting system). My website is divided into two parts for two languages, so I use two hosts to filter the English (/blog/somepost) and German (/de/blog/somepost) posts into different forum categories. [screenshot-forum.fab.industries-2023.06.16-02_30_47] Posts from the German side of the website aren…

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

Or,

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