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!
Entschuldigt bitte die mehreren Beiträge in diesem Thema, aber das Problem betrifft auch Bilder in Beiträgen, die über unser Zendesk-Plugin erstellt werden, wenn die Einstellung „Kommentare aus Zendesk synchronisieren
Ich fürchte, das kommt überhaupt nicht infrage. Wenn wir so etwas tun würden, könnten Dritte die Nutzung in einem Forum durch das Einschleusen eines Tracking-GIFs nachverfolgen. Das Herunterladen von Remote-Bildern ist ein Sicherheitsfeature.
Stattdessen glaube ich, dass wir ein „intelligenteres
Ich denke hier einfach nur laut nach, aber ich frage mich, ob wir das knifflige Problem hier umgehen können (d. h. die Umwandlung von HTML in Markdown). Zur Erinnerung (nur um das Ganze besser durchdenken zu können):
Discourse unterstützt die Importierung von HTML zur Erstellung von Beitragsinhalten (z. B. HTML aus WP Discourse).
In einigen Kontexten erwartet der Nutzer, dass die Integrität des ursprünglichen HTML exakt erhalten bleibt.
Das Tückische daran ist, wie man Beiträge mit diesem Flag jemals bearbeiten könnte. Der Editor würde im Raw-HTML-Modus sein und die gesamte Symbolleiste wäre kaputt, usw.