The fix only applies to posts that are published with the WordPress Block editor. It will fix old posts if the “Update Discourse Topic” button is clicked on WordPress. It will need to be done manually for each post unless someone writes a script to loop through old posts.
We fix the markdown engine to render <p></p>. Note that this does not render in the commonmark demo either.
Absolutely do not want to deviate from the spec here. I guess we fix pull hotlink images to allow for this by injecting 2 newlines for cases like this. I think it is rather rare though and sort of self inflicted.
@Arkshine we have been discussing this a lot internally. The key thing for us is to maintain the integrity of the content, so the newline solution will probably not happen.
But we will definitely be doing something - having the pull_hotlinked_images job destroy the images is not acceptable. Hope to have a solution soon
A workaround for this issue is to prevent Discourse from downloading the remote images. This can be done by adding the image domain to the disabled image download domains site setting. It is also possible to prevent Discourse from downloading all remote images by disabling the download remote images to local site setting. See Fix broken images for posts created by the WP Discourse and RSS plugins for details.
In our case, we can’t because we’re using the official topic thumbnail component which requires a local image. We solved the issue by adding newlines before any <img> in the content before topic being created with WP-Discourse. Not a solution for everyone but it works for us. A bit sad Discourse doesn’t support this legal usage.
But yes, if you are not tightened to a plugin/component and/or can’t fix the content before topic is created, this is for sure a reasonable workaround.
We are still planning to fix the issue. Unfortunately it is a problem quite deep in our markdown rendering system which is complex to fix. But we will get to it - sorry it is taking so long!
Sorry for the multiple posts in this topic, but the issue also affects images in posts that are created through our Zendesk plugin when the sync comments from zendesk setting is enabled. The difficulty with this case is that it’s not possible to know the source of the images before hand, so the workaround of adding the image src to the disabled image download domains setting will not work.
Is there any way we could just prevent remote images from being downloaded to local if the image tag is wrapped in HTML tags?
I am afraid that is completely off the table, if we did something like this we would allow third parties to track usage on a forum by injecting a tracking gif. The download remote image thing is a part security feature.
Instead I think we need a “smarter” system that works similar to the way @tgxworld built our image remappers a few years ago, one that works backwards from HTML and ensures stability of the change by re-cooking. Very complex change sadly.
Just thinking out-loud here, but I wonder if we can elide the tricky problem here (i.e. the conversion of HTML to markdown). To recap (just to help think this through)
Discourse supports the importation of HTML for the creation of post content (e.g. HTML from WP Discourse).
In some contexts the user expects the integrity of the original HTML to be retained exactly.
“integrity” here has at least two aspects:
How the content is rendered, e.g. linebreaks
Where media is hosted, e.g. downloading images to local to avoid broken images, or potentially for security concerns
The conversion of HTML to markdown potentially creates issues for the first type of integrity, however it is currently necessary to ensure the second type of integrity.
So perhaps one way to address this issue for certain imported posts would be for the imported HTML to be stored directly as the cooked post content, and the pull_hotlinked_images job would support downloading images in such content without converting img to markdown.
