Fix broken images for posts created by the WP Discourse and RSS plugins

You can do this from the Login section of your Discourse settings page. Select the login required setting to prevent anonymous users from viewing the site.

This means that the WP Discourse plugin can make API calls to your DIscourse site, but it does not mean that your WordPress site is allowing requests made from Discourse to get through. When you click the “Show Full Post” button, Discourse attempts to make a request to your WordPress site to scrape the post content. It seems likely this request is being blocked.

Thank you for this great information. I have disabled the login (great tip!) and will probably just wait to see what happens when I eventually take the main site live. Perhaps at that time it will properly enable the Show Full Post button.

About Onebox, do you know if it only works for https sites?

There are a few requirements for getting a link to form a onebox. I am not certain if HTTPS is now a requirement, but I wouldn’t be surprised if it was. The other requirements are that the page that’s linked to need to have an open graph description tag set, and the page needs to allow requests from the Discourse server to get through. I suspect that you’re running into a few issues with your staging site that are preventing oneboxes from being created.

1 Like

Hi Simon,

This makes sense. I will try Oneboxing again once I take the main site live.

As mentioned above, hopefully taking the site live and out of staging will also help the post to discourse functionality as well.

Thank you, again, for your help and insight.

It seem that the broken image from RSS feed cannot be fixed manually.
I can see the image reappear in the preview in the right side of the editor. But after I press save, the image are still broken in the post.

Discourse won’t generate thumbnail if the image is not local. If I disabled image download domains, all the post imported will have no thumbnail.

3 Likes

Having the same issue. I see two images in preview but after saving it looks like this:

Any solutions to how to get the images also display in the post and not only preview?

Update: 2.7.0.beta7

1 Like

You need to edit the post to add an empty line above both of the markdown tags.

If you are publishing the posts to Discourse from a website, you should add the domain that the images are being served from to your Discourse disabled image download domains site setting. This should prevent the issue from happening with new posts that are published to Discourse.

Thanks Simon. Unfortunately I cannot make it work:

I can send you the public URL, but not sure if this is considered spam. I can PM if you want.

Let me know if you need more info.
(Currently 2.7.0.beta7, 890b06b10f)

Update: some more background: The posts where imported from via import script originating from a Freshdesk Forum XML Export. The actual content contained the full HTML. We then imported the backup from our local devsystem to our fresh production instance. Initially the images were displayed, but because there was the original img-tag referencing the external URL. after a while Discourse downloaded the external remote image… but then the post looked broken as shown above.

1 Like

I’m really not understanding the complication here. Clearly, the HTML image tag is being replaced with markdown – e.g. ![](upload://6zqK52dO23i1JsYH2oyMU12U2ro.jpeg). Why not just make that include two carriage returns before the !? That’ll make it render right, and allow the image upload feature to work to prevent broken images and cross-site issues.

Is there a real-world non-theoretical situation where that whitespace might cause a problem? Is that problem worse than the “images are just broken all of the time” state of the current plugin?

Our WordPress plugin attempts to get around the issue by doing exactly that on the WordPress end. Inserting two carriage returns before any HTML img tags before the post is published to Discourse fixes the issue.

I believe that I have suggested adding something similar to our markdown parser here: Markdown rendering issue with image surrounded with HTML. I think the reason for rejecting that approach was because we do not want to deviate from the CommonMark spec.

Okay, so now I’m even more confused! And, I promise, this is genuine confusion, not something I’m affecting for extra impact. :slight_smile: We have hosted Discourse and our Wordpress has what I believe to be the latest version of the plugin (2.3.0), but we’re still getting broken images and I need to go in and add the blank lines manually. Is there something I need to do to enalbe this?

For sure. It’s a confusing issue. The WP Discourse plugin attempts to fix the issue with images, but currently only catches images if posts are published with the WordPress Block Editor and images are added to the posts with the default Image block. If you can share some details about how you are adding images to your WordPress site’s posts, we may be able to come up with a way of dealing with this issue.

Ideally this will get fixed on the Discourse end, but if that is not possible the image parsing that is done by the WP Discourse plugin will need to be improved.

Hmmm, okay, so Would you use this as your homepage? – Fedora Community Blog yielded Would you use this as your homepage? - Community Blog - Fedora Discussion. (The images on the second link work because I edited the post directly.)

When I look on the wordpress backend, the images are all image blocks.

Again, I don’t understand the complexity here, though. Something is adding markdown like ![](upload://na9g3dGvhEU753JEnGrz8xER4XS.png) to the raw text of each post on the Discourse site. Why not make that thing add a blank line before each such inserted bit of markdown?

Can you try posting that question in the related bug topic here: Markdown rendering issue with image surrounded with HTML. It is likely to get more attention if you post it in the bug topic.

Edit: I’ll notify @angus about the issue with the WP Discourse plugin not correctly parsing the images to fix the issue on the WordPress end. It’s likely he’ll need some more details from you to diagnose what is going on.