Bonjour,
il semble qu’il ne soit plus possible d’ajouter des pièces jointes dans les tableaux. Avez-vous une idée de comment résoudre ce problème ?
Exemple
| Nom | Fichier |
|---|---|
| bla | bla |
| [bla.docx |
| Nom | Fichier |
| --- | --- |
| bla | bla |
| | [bla.docx|pièce jointe](upload://hu8jvVTNiCjzn5XmxXRnhUaRINy.docx) (22,4 Ko) |
Cela est dû au séparateur “|” entre le nom du fichier et la fonction pièce jointe.
J’en ai vraiment besoin pour garder les choses propres et organisées.
Je ne sais pas s’il existe une correction à apporter pour l’éviter, mais si vous échappez le pipe avec \, cela fonctionnera.
| Nom | Fichier |
|---|---|
| bla | bla |
| bla.docx (22,4 Ko) |
| Nom | Fichier |
| --- | --- |
| bla | bla |
| | [bla.docx\|attachment](upload://hu8jvVTNiCjzn5XmxXRnhUaRINy.docx) (22,4 Ko) |
Je préfère l’ancienne méthode pour ajouter des pièces jointes. Ce serait génial si un paramètre de Discourse me permettait de choisir le mode.
Je ne suis absolument pas d’accord avec ce que vous proposez ici ?
Le schéma de syntaxe a été récemment modifié. Cependant, l’ancienne version reste valide. Je suggère donc de donner à l’administrateur la possibilité de choisir quelle syntaxe (ancienne ou nouvelle) sera fournie par défaut aux utilisateurs.
Je n’aime pas le contournement par le caractère pipe. Il n’est pas intuitif et reste en conflit global avec les tableaux Markdown.
Si vous pensez qu’une telle rétrocompatibilité n’est pas nécessaire, alors, vous devriez au moins envisager un mécanisme de complétion automatique pour détecter ce type de comportement dans les tableaux.
Cordialement,
Il est hors de question de proposer un paramètre ou un plugin permettant de changer le format des pièces jointes en HTML au lieu de Markdown. Vous devez vous rendre sur Marketplace. L’ancien format pose de nombreux problèmes de portabilité avec les téléchargements.
Je ne suis pas opposé à corriger ce cas particulier d’une manière ou d’une autre, mais il est assez difficile de déterminer si vous êtes dans un tableau ou non en fonction de la position du curseur, ce qui rend la correction automatique complexe.
Par exemple ?
Quelle était l’intention de changer le format sans fournir de tâche Rake ou quelque chose de similaire ? (Pour mettre à jour l’ancien code…)
À plusieurs reprises, le format de syntaxe a changé de manière marginale, avec un impact majeur sur l’ensemble du contenu… par exemple avec des espaces manquants entre les hashtags de section et leurs noms, ou entre les citations > et le texte. Surtout sur plusieurs niveaux. C’est un vrai chaos de corriger manuellement ces changements pour des centaines de publications en tant qu’administrateur. Croyez-moi. J’aurais aimé qu’on me demande, en tant qu’administrateur, si je vous suis ou si je conserve le format de syntaxe actuel.
À mon avis, la priorité numéro 1 devrait être de s’assurer que chaque changement de format n’affecte pas l’utilisabilité des fonctionnalités principales.
Je n’ai pas une connaissance approfondie du problème de position du curseur. Je vous crois. Mais cela devrait être possible, car le compositeur semble savoir où commence et où finit un tableau. Tant que vous pouvez déterminer la position du curseur n’importe où entre les deux, vous pourriez ajouter automatiquement un pipe pour les téléchargements. N’est-ce pas ?
Il existe une tâche rake, elle s’appelle :
rake posts:inline_uploads
Vous ne devez exécuter cette tâche que si vous avez rencontré des problèmes de téléversement par le passé ou si vous souhaitez migrer le stockage de local vers S3.
100 % de nos sites hébergés sont en ligne, car cela rend les téléversements moins fragiles.
J’ai l’impression qu’il y a un peu de tempête ici pour ce qui est essentiellement un cas limite.
La grande majorité des publications sur le web ne contiennent aucune table. Parmi les rares publications contenant effectivement des tables, la grande majorité n’inclut pas de téléversements.
Je suppose que nous pourrions prendre en charge quelque chose comme ceci à la place de la barre, qui est résiliente face aux tables :
[bla.docx¦attachment](upload://hu8jvVTNiCjzn5XmxXRnhUaRINy.docx)
J’ai besoin de un peu de temps pour réfléchir à cela… je ne vais pas me précipiter pour apporter des modifications.
L’échappement par barre oblique ne pose pas de problème. Si vous faites quelque chose d’aussi avancé, échapper une barre oblique n’est pas bien grave.
Mettre des fichiers en ordre, c’est une fonctionnalité avancée ? 
Je me demande juste pourquoi je ne peux pas revenir au format ancien. La plupart des pièces jointes ajoutées précédemment sont toujours incluses de cette manière et tout semble fonctionner parfaitement.
Les mises à jour de Discourse cassent encore et encore des fonctionnalités essentielles. Et il n’y a aucun avertissement supplémentaire concernant les conflits.
J’aime vraiment le développement agile et le gestionnaire de mises à jour Docker. Mais ce type de gestion de versions me rend fou, encore et encore.
Même les petits détails comptent.
Y a-t-il une chance que l’outil d’importation puisse ajouter automatiquement le caractère d’échappement lorsqu’il importe un fichier qui sera utilisé dans un tableau ? Il m’a fallu environ 20 minutes pour comprendre ce qui causait le plantage de mon tableau et/ou de mon importation sur un article de tableau que nous avions.
Je pense qu’un utilisateur non technique aurait simplement abandonné.
Très difficile à faire avec précision, notre moteur markdown ne fait qu’un mappage inverse par ligne, nous aurions donc besoin d’une tonne de logique spéciale.
Si la PR pour cela est suffisamment petite, je serais cependant ouvert à une amélioration ici.