Oui, si vous alliez entièrement dans cette direction, vous devriez choisir entre ne pas pouvoir éditer le contenu dans Discourse et préserver l’intégrité complète du HTML.
Je pensais qu’il pourrait y avoir un compromis où vous appliqueriez cette approche uniquement aux balises img dans les posts HTML importés.
Mais je commence à douter de cette idée. Le faire de manière sélective nécessiterait des modifications dans de nombreuses parties du traitement des posts.
Oui, je pense que c’est probablement la meilleure option. J’avais commencé à travailler dessus en juin 2020, mais cela s’est avéré être beaucoup de travail et j’ai dû passer à d’autres projets. J’avais envisagé deux approches pour autoriser les URL upload:// dans les balises <img… aucune n’est parfaite. Voici mes notes :
Dans le pipeline Markdown, analyser le contenu de chaque html_block (en abusant légèrement de la bibliothèque xss.js) et traiter les balises d’image ayant des attributs src upload://.
Avantages : tout se passe dans le pipeline Markdown, ce traitement n’est effectué que sur les jetons html_block
Inconvénients : utilisation quelque peu abusive du sanitizeur xss.js. Ce n’est peut-être pas un analyseur HTML5 parfait
Cette option pourrait être améliorée en utilisant une implémentation DOM JavaScript conforme aux normes (par exemple jsdom) côté serveur, mais cela semble assez lourd.
Autoriser les attributs src upload:// tout au long du pipeline Markdown, puis les remplacer ultérieurement. Côté client, c’est en fait assez simple : nous remplaçons déjà les URL upload:// de manière asynchrone après la cuisson. Côté serveur, cela ajoute une étape de traitement supplémentaire utilisant Nokogiri.
Avantages : l’analyseur est conforme aux normes HTML5
Inconvénients : implémentation différente côté client/serveur, rend le pipeline légèrement plus complexe
Je pense que l’option 2 est probablement la voie à suivre. Nous devrons ensuite mettre à jour le travail pull_hotlinked_images pour conserver les balises <img, sans les remplacer par du Markdown. J’espère pouvoir trouver le temps d’y revenir bientôt 
Je ne comprends vraiment pas la complication ici. Clairement, la balise HTML image est remplacée par du Markdown – par exemple . Pourquoi ne pas simplement ajouter deux sauts de ligne avant le ! ? Cela permettrait un rendu correct et permettrait à la fonctionnalité de téléversement d’images de fonctionner, évitant ainsi les images brisées et les problèmes de cross-site.
Existe-t-il une situation réelle, non théorique, où cet espace blanc pourrait causer un problème ? Ce problème est-il pire que l’état actuel du plugin où « les images sont simplement brisées tout le temps » ?
@david, vous notez que « la solution avec le saut de ligne ne se produira probablement pas » car « l’élément clé pour nous est de maintenir l’intégrité du contenu ». Mais le contenu est déjà modifié par l’insertion des balises dès le départ. Je… ne comprends vraiment pas comment cela pourrait être mieux.
Actuellement, à chaque fois que quelqu’un inclut une image dans son post WordPress, les images reviennent brisées, et je dois fréquemment gérer des commentaires du type « les images sont brisées », souvent suivis de réponses du genre « oui, c’est parce que Discourse est nul ». J’aimerais éviter ces deux problèmes.
Je comprends que le paramètre « ne pas télécharger les images » puisse être une solution de contournement, mais en réalité, je veux que les images soient téléchargées, donc j’espère que cela ne sera qu’une solution temporaire.
Cela devrait être résolu par :
Essayons ici sur Meta.
<div>
Image dans un bloc HTML :
<img src="..." width=100 height=100>
</div>
Ce sujet a été automatiquement fermé après 5 jours. Les nouvelles réponses ne sont plus autorisées.
