Lors de l’édition d’une publication utilisant un modèle de formulaire, l’aperçu de la composition affiche tout champ composer multi-lignes comme une seule ligne continue : les titres sont collés à la phrase qui les suit, et les listes ainsi que le BBCode apparaissent en texte brut. La publication enregistrée est correctement traitée — seul l’aperçu est incorrect.
Cause : form-template-field/composer.gjs reflète chaque champ de composition dans un <input type="text"> masqué pour la validation native :
<input id={{this.validationInputId}} type="text" name={{@id}} value={{this.composerValue}} ... class="form-template-field__composer-hidden-input" />
La réponse du composeur — qui est ce que l’aperçu traite — est assemblée à partir de ces champs. Selon les règles de nettoyage des valeurs HTML, un champ type="text" supprime les retours chariot/saut de ligne lors de l’affectation, si bien que tous les sauts de ligne de la valeur du champ ont disparu avant que l’aperçu ne les voie. L’enregistrement lit l’éditeur lui-même, ce qui explique pourquoi la valeur brute stockée n’est pas affectée.
Reproduction (2026.9.0-latest) : tout modèle de formulaire avec un champ composer → saisir un texte contenant des lignes vides (par ex. un ## titre, un paragraphe, une liste) → ouvrir l’édition sur la publication enregistrée → l’aperçu l’affiche aplati en une seule ligne, tandis que la publication elle-même s’affiche correctement.
Solution de contournement que nous utilisons en tant que thème : passer les champs masqués à type="hidden" (ce qui préserve les sauts de ligne lors de l’affectation), réparer la valeur déjà aplatie depuis l’éditeur de champ, et déclencher un événement d’entrée unique pour que la réponse se reconstruise. Cela restaure entièrement l’aperçu.
Note pour un correctif du cœur : type="hidden" contourne la validation de la contrainte required native, il est donc probable que le contrôle de remplacement doive être une <textarea> visuellement masquée plutôt qu’un champ de texte.