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!
Scusa per i numerosi post in questo argomento, ma il problema riguarda anche le immagini nei post creati tramite il nostro plugin Zendesk quando l’impostazione sync comments from zendesk è abilitata. La difficoltà in questo caso è che non è possibile conoscere in anticipo la fonte delle immagini, quindi l’alternativa di aggiungere l’URL dell’immagine all’impostazione disabled image download domains non funzionerà.
Esiste un modo per impedire il download delle immagini remote sul locale se il tag immagine è racchiuso in tag HTML?
Temo che questa opzione sia completamente fuori discussione; se facessimo qualcosa del genere, permetteremmo a terze parti di tracciare l’utilizzo su un forum iniettando un’immagine di tracciamento. Il download delle immagini remote è una funzione di sicurezza.
Invece, penso che abbiamo bisogno di un sistema “più intelligente” che funzioni in modo simile a come @tgxworld ha implementato i nostri mappatori di immagini alcuni anni fa, uno che opera all’indietro partendo dall’HTML e garantisce la stabilità della modifica attraverso una nuova cottura. Purtroppo, si tratta di una modifica molto complessa.
Sto solo pensando ad alta voce, ma mi chiedo se possiamo evitare il problema complesso qui (cioè la conversione da HTML a Markdown). Per riassumere (solo per aiutarmi a ragionare su questo)
Discourse supporta l’importazione di HTML per la creazione del contenuto dei post (ad esempio HTML da WP Discourse).
In alcuni contesti, l’utente si aspetta che l’integrità dell’HTML originale venga mantenuta esattamente.
“Integrità” qui ha almeno due aspetti:
Come viene renderizzato il contenuto, ad esempio i ritorni a capo
Dove sono ospitati i media, ad esempio il download delle immagini in locale per evitare immagini rotte o potenzialmente per motivi di sicurezza
La conversione da HTML a Markdown potenzialmente crea problemi per il primo tipo di integrità, ma è attualmente necessaria per garantire il secondo tipo di integrità.
Quindi, forse un modo per affrontare questo problema per determinati post importati sarebbe salvare l’HTML importato direttamente come contenuto cotto del post, e il job pull_hotlinked_images supporterebbe il download delle immagini in tale contenuto senza convertire img in Markdown.
La cosa complicata è: come potresti mai modificare i post con quel flag? L’editor si troverebbe in modalità HTML grezzo e l’intera barra degli strumenti non funzionerebbe, ecc.
