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!
نعتذر عن تعدد المنشورات في هذا الموضوع، لكن المشكلة تؤثر أيضًا على الصور في المنشورات التي يتم إنشاؤها عبر إضافة Zendesk لدينا عند تفعيل إعداد “مزامنة التعليقات من Zendesk”. تكمن الصعوبة في هذه الحالة في أنه لا يمكن معرفة مصدر الصور مسبقًا، وبالتالي لن تعمل حيلة إضافة مصدر الصورة إلى إعداد “نطاقات تحميل الصور المعطلة”.
هل توجد طريقة لمنع تحميل الصور البعيدة إلى الجهاز المحلي إذا كانت وسم الصورة محاطة بوسوم HTML؟
أخشى أن هذا غير ممكن على الإطلاق؛ فإذا قمنا بمثل هذا الإجراء، فسنتيح لأطراف ثالثة تتبع الاستخدام في المنتدى عن طريق حقن صورة تتبع. إن ميزة تحميل الصور البعيدة هي جزء من نظام الأمان.
بدلاً من ذلك، أعتقد أننا بحاجة إلى نظام “أذكى” يعمل بطريقة مشابهة للطريقة التي بنى بها @tgxworld خرائط الصور الخاصة بنا قبل بضع سنوات، نظام يعمل بشكل عكسي من HTML ويضمن استقرار التغيير من خلال إعادة الطهي. تغيير معقد للأسف.
فقط أفكر بصوت عالٍ هنا، لكنني أتساءل عما إذا كان بإمكاننا تجاوز هذه المشكلة الصعبة (أي تحويل HTML إلى Markdown). للتذكير (لمساعدة التفكير في هذا الأمر)
يدعم Discourse استيراد HTML لإنشاء محتوى المنشورات (مثل HTML من WP Discourse).
في بعض السياقات، يتوقع المستخدم الحفاظ على سلامة HTML الأصلي تمامًا.
تشمل “السلامة” هنا جانبين على الأقل:
كيفية عرض المحتوى، مثل فواصل الأسطر
مكان استضافة الوسائط، مثل تنزيل الصور محليًا لتجنب الصور التالفة، أو ربما لأسباب تتعلق بالأمان
قد يؤدي تحويل HTML إلى Markdown إلى مشاكل من النوع الأول من السلامة، ومع ذلك فهو ضروري حاليًا لضمان النوع الثاني من السلامة.
لذا، ربما تكون إحدى الطرق لمعالجة هذه المشكلة لبعض المنشورات المستوردة هي تخزين HTML المستورد مباشرة كمحتوى منشور مطبوخ، ودعم مهمة pull_hotlinked_images لتنزيل الصور في مثل هذا المحتوى دون تحويل img إلى Markdown.
