I’m guessing this is related to the changes to blocks in the 5.3 update. You can see the post here: In Conversation with Anna Morgan - In Layers: Conversations - Nature Photographers Network
FYI I also have this snippet for CDN images
add_filter( 'wp_discourse_excerpt', 'wpdc_custom_excerpt' );
function wpdc_custom_excerpt( $content ) {
return apply_filters( 'as3cf_filter_post_local_to_s3', $content );
}
I am also getting this error in my dashboard which I’m fairly certain is from the Wordpress plugin.
I came across this post WP Discourse plug in being odd but I am on 1.9.7 and the publishing username is an active account.
I’ll be looking into this today. What I’m seeing on my site is that images published from WordPress are displayed correctly until Discourse attempts to download the remote image. When that is done, I’m ending up with markup like you are getting in the post:
I am not sure if this is related to changes in WordPress 5.3.
If you are getting the We detected an API request using a deprecated authentication method warning, that will not be causing the issue you are having with images. WP Discourse versions 1.9.6 and greater should not be causing that warning. All API requests from the plugin are now using header based authentication.
The problem seems to be that when the Discourse upload markdown is wrapped in HTML tags, the markdown isn’t getting parsed. For example, this is what I’m seeing for a WordPress post after the Discourse PullHotlinkedImages Job is run:
<small>Originally published at: https://scossar.com/figure-tags-cause-issues/
</small><br>
<figure class="wp-block-image"></figure>
Editing the post to remove any html tags that are surrounding the markdown link solves the issue, but a proper solution will need to be found for this.
Sorry to bug, but are you working on this Simon or has someone been assigned to it?
The issue is that when posts with images are published to Discourse, the post’s HTML initially looks something like this:
<figure><img src="https://example.com/wp-content/uploads/your-image.png" /></figure>
If the download remote images to local site setting is enabled on Discourse, the image link will break when Discourse downloads the post from WordPress. The problem will happen any time an image tag with a remote URL is wrapped with HTML tags.
The easiest solutions for this issue are to either disable the download remote images to local site setting, or to not publish full post content from WordPress to Discourse.
In the future, the WP Discourse plugin may remove the option to publish full posts. There are multiple issues that can occurr when publishing full post content from WordPress to Discourse. Most of these issues should be able to be solved by publishing excerpts from WordPress to Discourse and then using the Show Full Post button to display the full post on Discourse. Does this sound like something that could work for your case?
Another possible solution would be to customize the template that is used to publish WordPress posts. Images could be extracted from the posts and then published along with a post excerpt. With a custom template, the image HTML could be structured in a way that doesn’t conflict with the Discourse markdown processor.
Thanks Simon, download remote images to local was the easy solution for now. I am discouraged to hear that publish full posts may go away. The way I currently use it is by publishing a post to wordpress, which then gets published to the Articles section on discourse, which is set to Watching First Post for everyone by default. This way everyone gets an email with the full content of the article, and the best part is they can just reply to the email to add a comment, if they have to take that extra step of visiting the site it’s likely most won’t read the article if there’s just a little snippet, especially if it doesn’t have images which is really important for our site. If publish full posts went away I may consider going away from wordpress and only publish the articles directly in discourse which is not ideal for SEO, etc. but I think the engagement is more important.
También echaría de menos una publicación completa.
No estoy 100 % seguro de lo que sugieres aquí…
¿Cómo extraerías las imágenes? ¿Con una expresión regular?
Podría imaginarme una expresión regular que reemplace las etiquetas de imagen con la sintaxis adecuada de Markdown. ¿Es eso a lo que te refieres y funcionaría?
No. Me habría sentido tentado a hacerlo si no hubiera probado ese tipo de cosas en el pasado. Esta publicación de Stack Overflow explica en parte el problema: https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454.
Voy a investigar qué tan difícil sería que el plugin genere una versión HTML básica del contenido de la publicación. El último recurso sería utilizar los métodos de DOMDocument para analizar el contenido. Los comentarios que devuelve Discourse se analizan con esos métodos y no he recibido informes de problemas al respecto.
Creo que publicar un extracto y luego permitir que los usuarios vean la publicación completa haciendo clic en el botón “Mostrar publicación completa” en Discourse es probablemente la mejor solución para esto, pero me resisto a eliminar la opción “Publicar publicación completa” del plugin WP Discourse.
Gracias por la explicación.
Pediré a mis autores que simplemente publiquen el artículo y hagan clic en “actualizar”, ya que publicar y luego actualizar el artículo en WP siempre parece solucionar los problemas de imágenes en Discourse.
Prefiero que mis autores dediquen 1 segundo más a cada artículo antes que ver que desaparezca la opción de publicar completamente 
Si tienes habilitada la configuración del sitio de Discourse descargar imágenes remotas a locales, ¿no es cierto que la imagen simplemente desaparece de nuevo unos minutos después de actualizar la publicación? Si no es así, investigaré por qué eso soluciona el problema.
Sí, tengo esta configuración habilitada y las imágenes se siguen mostrando correctamente en todos mis artículos más recientes, incluso después de días y semanas. Un ejemplo es este artículo de hace un mes, en el que encontré el problema con las imágenes.
Además, revisé las URL de las imágenes en Discourse y los enlaces son los mismos que los de WordPress, por lo que las imágenes no se descargan en Discourse. ¿Será porque el sitio web y el foro comparten el mismo dominio?
(sitio: https://monocycle.info, foro: https://forum.monocycle.info)
Sigo obteniendo una miniatura enorme rota en lugar de la imagen cuando actualizo el hilo de Discourse. Al editar la publicación, veo lo siguiente entre < >:
img src="http://mysite.com/wp-content/uploads/2020/03/asha2.jpg" class="ss-hidden-pin-image" alt="Blog" data-pin-url="" data-pin-media="http://mysite.com/wp-content/uploads/2020/03/asha2.jpg" data-pin-description=""/
¿Tu sitio de WordPress usa http o https?
Actualmente es http, aunque estoy investigando https.
Los navegadores no cargarán contenido de fuentes inseguras si la página es HTTPS.
Si estás dependiendo de un elemento HTML para cargar la imagen, esto no funcionará hasta que tu sitio principal use HTTPS.
Acabo de publicar WP Discourse versión 2.0.2 en el repositorio de plugins de WordPress. La actualización debería solucionar el problema de las imágenes rotas que ocurría al publicar entradas en Discourse con el editor de bloques.
Las imágenes, las galerías de imágenes, así como los videos de YouTube y Vimeo, ahora se extraen de las entradas y se formatean de manera que Discourse pueda procesarlos. Avísame si encuentras algún problema con la actualización. Si aún hay bloques de WordPress que no se renderizan correctamente en Discourse, házmelo saber: ahora los bloques se pueden analizar por nombre, por lo que debería ser posible resolver cualquier problema.
La próxima semana añadiré un filtro al que se pueda conectar para analizar cualquier bloque demasiado obscuro para ser gestionado por el plugin.
Unos cuantos problemas aquí después de la actualización.
En WP estoy usando el «editor clásico» (TinyMCE).
Tenía artículos antiguos con URLs de vídeo en shortcodes [video] y mis artículos más recientes (de menos de 3 años) usaban el plugin incrustador de vídeo ARVE, que pone la URL del vídeo dentro de un shortcode [arve].
Así que filtré las entradas de WP a Discourse con esto:
$excerpt = preg_replace('/\[arve .*url="(.*?)" .*\/\]/is',"\n$1\n", $excerpt);
$excerpt = preg_replace('/\[video .*mp4="(.*)"\]\[\/video\]/is',"\n$1\n", $excerpt);
Funcionaba perfectamente y solo se pasaban las URLs de los vídeos a Discourse, de modo que se mostraban incrustados en Discourse.
Pero desde la actualización de WP-Discourse, los vídeos no se muestran en Discourse.
También probé simplemente pegando la URL de YouTube en TinyMCE, sin shortcode (aprendí que no se requiere ningún shortcode para que WP incruste vídeos de YouTube de alguna manera… O quizás sea por uno de mis otros plugins o por mi tema? 
Pero creo que eso no importa), y eliminando mis funciones preg_replace, pero el vídeo sigue sin mostrarse en Discourse.
Aquí está mi texto en WP (texto plano, no en la pestaña WYSIWYG):
https://www.youtube.com/watch?v=e6MCkspqtxo
[arve url="https://www.youtube.com/watch?v=e6MCkspqtxo" /]
Así aparece en WP:
Entrada en Discourse:
Código HTML de la entrada en Discourse:
<p>Prueba de vídeoooo:</p>
<div data-mode="normal" data-provider="youtube">
<div></div>
</div>
<div data-mode="normal" data-provider="youtube">
<div></div>
</div>
edición: también, noté que cuando el artículo es privado en WP, no se sincroniza en Discourse cuando editamos el artículo. Eso es un poco molesto cuando queremos hacer algunas pruebas en privado.
Eso es extraño. Mi esperanza con el cambio era que no afectara a las publicaciones que se publican con el editor Clásico. Intentaré reproducir el problema. ¿Podrías compartir el marcado que ves si abres la publicación en la pestaña Texto del editor?
Con el plugin de WP ARVE
<p>Test vidéooo:</p>
<div class="arve-wrapper aligncenter" data-mode="normal" data-provider="youtube" id="arve-e6MCkspqtxo-3" style="max-width:800px;" itemscope itemtype="http://schema.org/VideoObject">
<div class="arve-embed-container" style="padding-bottom:56.250000%"><iframe allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen class="arve-iframe fitvidsignore" frameborder="0" name sandbox="allow-scripts allow-same-origin allow-presentation allow-popups allow-popups-to-escape-sandbox" scrolling="no" src="https://www.youtube-nocookie.com/embed/e6MCkspqtxo?iv_load_policy=3&modestbranding=1&rel=0&autohide=1&playsinline=1&autoplay=0" width="480" height="270"></iframe></div>
</div>
<div class="arve-wrapper aligncenter" data-mode="normal" data-provider="youtube" id="arve-e6MCkspqtxo-4" style="max-width:800px;" itemscope itemtype="http://schema.org/VideoObject"><div class="arve-embed-container" style="padding-bottom:56.250000%"><iframe allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen class="arve-iframe fitvidsignore" frameborder="0" name sandbox="allow-scripts allow-same-origin allow-presentation allow-popups allow-popups-to-escape-sandbox" scrolling="no" src="https://www.youtube-nocookie.com/embed/e6MCkspqtxo?iv_load_policy=3&modestbranding=1&rel=0&autohide=1&playsinline=1&autoplay=0" width="480" height="270"></iframe></div></div>
Sin el plugin, si simplemente escribo en WP:
https://www.youtube.com/watch?v=e6MCkspqtxo
El editor de Discourse muestra este resultado:
<p>Test vidéooo:</p>
<div class="fitvids-video"><iframe title="Volkor X - Enclave" width="800" height="450" src="https://www.youtube.com/embed/e6MCkspqtxo?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></div>
Parece que WP sigue utilizando otra biblioteca no nativa, ¿quizás de mi tema?
Supongo que el problema está más de mi lado que del tuyo, aunque antes funcionaba bien tras la actualización… 