Peut-être que cela peut être résolu avec du CSS. Est-ce qu’il n’apparaît jamais, ou pouvez-vous faire défiler vers le haut pour le voir ? Quel navigateur/système d’exploitation utilisez-vous ? Peut-être pouvons-nous le rendre fixe en haut. Le problème est que certains navigateurs ont récemment essayé d’être « créatifs » et ont déplacé la barre du navigateur vers le bas.
Les navigateurs sont Firefox et Chrome sur Android, sur un téléphone Motorola. La même chose se produit avec l’application Discourse.
La barre de boutons est toujours présente, mais elle se trouve juste en dessous d’un menu contextuel lorsque la sélection se situe dans les 3 premières lignes visibles dans la zone de texte.
Une solution de contournement consiste à insérer 3 retours chariot/saut de ligne (CR/LF) avant le premier texte. Supprimez ensuite ces caractères supplémentaires avant de publier.
1 « J'aime »
Oui, je viens de tester. Je vois ce que tu veux dire. C’est super énervant. Mais je pense que les barres en bas sont encore pires. Et en plus, je dois faire des recherches sur la façon de faire ça, et je ne suis pas payé pour ça. Mais il y a probablement un moyen plus propre de le faire. Je parie que d’autres projets ont le même problème et qu’il existe une solution standardisée. Mais comme je l’ai dit, j’ai d’autres priorités. Désolé d’être si franc 
EDIT : juste une note. Il y a un moyen de désactiver le clic droit (double-clic sur mobile). https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript mais alors les utilisateurs ne peuvent pas copier. C’est un vrai chaos…
3 « J'aime »
La solution de contournement est viable, simplement peu pratique.
Il existe probablement une approche CSS mobile pour cette contrainte. Je devrai simplement la trouver.
Ajouter beaucoup de code pour ce cas particulier ne serait pas une bonne utilisation de votre temps et de votre attention. (De plus, cela ajoute une surcharge.) Merci d’avoir partagé vos projets avec la communauté. C’était très généreux de votre part.
3 « J'aime »
D’accord, merci beaucoup pour le rapport. Je viens de le corriger.
6 « J'aime »
Un petit conseil : Rails ajoute la méthode .present? dans plusieurs classes Ruby, ce qui est préférable à la comparaison avec des chaînes vides. Elle fonctionne principalement avec les tableaux et les chaînes de caractères.
Il existe également .empty?, qui est l’opposé de .present?.
5 « J'aime »
J’ai retiré ce bouton intentionnellement car les images doivent être téléchargées via l’éditeur. Cependant, je viens de constater que le menu de sélection de fichiers ne s’ouvre pas sur Firefox pour Android pour une raison inconnue. Pour investiguer ce problème, je dois installer le débogage à distance, ce qui prendra donc un certain temps avant d’être résolu. En attendant, utilisez simplement l’éditeur avancé pour télécharger des images.
EDIT : en fait, tout fonctionne parfaitement. Le menu ne s’ouvrait pas parce que j’avais précédemment refusé l’accès à la caméra de l’application. Vous pouvez donc utiliser le même bouton de téléchargement d’images que sur ordinateur. Si vous êtes confus, regardez la capture d’écran que j’ai téléchargée pour tester : https://cidian.social/t/file-upload-from-mobile/292
1 « J'aime »
Je souhaite activer uniquement les options Gras, Italique, Lien et Téléchargement d’image dans la barre d’outils. Comment puis-je faire cela ?
1 « J'aime »
J’ajouterai une option pour le configurer une fois que ce sera terminé.
4 « J'aime »
Cela signifie qu’il n’y a pas de solution de contournement pour cela ? Puis-je modifier le fichier de configuration de CKEditor que vous avez utilisé dans le plugin ?
Allez-vous le rendre compatible avec d’autres plugins comme, par exemple, l’annotation d’images, le balisage BB, etc. ?
3 « J'aime »
D’accord, laissez-moi clarifier un point : quand je parle de « choses qui ne fonctionnent pas », j’entends simplement qu’elles ne sont pas rendues dans la fenêtre d’entrée WYSIWYG. Tout fonctionne toujours dans le message final. Cet éditeur n’est pour l’instant qu’une autre façon de créer du Markdown. C’est toujours du Markdown qui est produit à la fin. De mon point de vue, le « HTML uniquement » est la voie à suivre à l’avenir. Le Markdown, le BBCode, etc., appartiennent au passé et offrent une expérience utilisateur excessivement complexe. Mais évidemment, je ne vais pas implémenter chaque fonctionnalité BBCode ou plugin personnalisé, car cela ne m’apporte aucun avantage. Ma priorité absolue est de répondre à mon cas d’usage. Je tiens également à simplifier l’expérience utilisateur de Discourse pour les autres. Si vous aimez le Markdown, le BBCode et tous ces « tags » dans votre éditeur, alors peut-être que ce n’est pas la bonne solution pour vous.
J’aimerais également que cette discussion devienne plus constructive. Je serais ravi d’entendre les cas d’usage et les raisons pour lesquelles les personnes souhaitent utiliser un éditeur WYSIWYG plutôt que l’actuel. Je suis aussi intéressé à connaître les avantages que vous en attendez et les objectifs que vous souhaitez atteindre.
Peut-être que cela nous permettra d’avancer. Demander « pouvez-vous faire toutes ces choses aléatoires ? … (gratuitement) » n’est pas utile.
Cordialement,
Spirobel
6 « J'aime »
Passer au HTML et ne plus prendre en charge le Markdown rendra tous les posts créés en HTML non modifiables une fois votre plugin désactivé. Est-ce exact ?
1 « J'aime »
@spirobel bien que je n’utilise personnellement pas votre plugin, j’admire ses fonctionnalités et je vous félicite pour votre grand effort !
Bien que je puisse convenir que bbcode est une syntaxe héritée, l’idée que Markdown soit une chose du passé est incorrecte selon moi – bien au contraire, son ensemble de fonctionnalités de base est là pour rester longtemps.
Les deux raisons principales sont :
- Mise en forme par la saisie – vous pouvez mettre correctement le texte en forme simplement en tapant, ce qui permet de se concentrer et de travailler de manière productive.
- Lisible même non rendu – la syntaxe de base de Markdown est instinctivement lisible sous forme de texte brut, ce qui est très utile pour de nombreuses raisons.
C’est lorsque vous essayez d’étendre les fonctionnalités de Markdown (images, tableaux, etc.) que cela tend à échouer et parfois à se briser en raison d’une syntaxe illisible et fastidieuse à taper.
À mon avis, les meilleurs éditeurs offrent une solution hybride :
- La mise en forme de base s’affiche en ligne tout en conservant les caractères de syntaxe en mode édition.
- Les fonctionnalités étendues (images, tableaux, etc.) doivent bien sûr également être rendues en mode édition, et ne pas nécessairement être représentées par les caractères de syntaxe réels à l’écran. Peut-être, oserais-je le dire, devraient-elles être considérées comme des plugins et stockées dans un format le plus adapté au type de données.
6 « J'aime »
Merci beaucoup pour votre commentaire !
Je comprends ce que vous voulez dire, mais je suis toujours en désaccord. 
À long terme, les utilisateurs avancés seront mieux servis par des raccourcis. Par exemple, il pourrait exister un raccourci pour les italiques. Vous pourriez ainsi utiliser le raccourci tout en continuant à taper. Le raccourci pourrait même être quelque chose comme CTRL+*, ce qui serait presque comme utiliser Markdown.
Concernant le point 2, je peux dire que le HTML est également lisible, car il est toujours rendu (dans le navigateur), et si vous examinez un extrait de HTML dans un éditeur de texte, vous pouvez aussi le lire. D’accord, Markdown peut sembler un peu plus joli, mais seulement si vous vous en tenez à des fonctionnalités très basiques, et dans ce cas, cela n’a d’ailleurs pas vraiment d’importance.
La solution hybride n’est malheureusement pas réalisable. L’une des raisons pour lesquelles j’ai adhéré à l’approche « HTML uniquement » est qu’elle me permet de me concentrer sur la création d’une interface utilisateur plutôt que d’obtenir un doctorat en linguistique informatique tout en déboguant des bugs de parseur de langage. L’idée est de réduire la dette technique, pas de l’augmenter.
En fin de compte, je comprends très bien votre point de vue. J’ai aussi lu les écrits sur Markdown. Mais pour moi, le paradigme « HTML uniquement » est plus convaincant pour ce que je compte faire. Je réalise aussi qu’il n’y a aucun intérêt à convaincre les personnes qui aiment vraiment Markdown. Elles devraient rester avec l’éditeur tel qu’il est actuellement. Mais je pense qu’il existe un autre public qui pourrait être intéressé par une approche différente. Ce plugin va bien au-delà d’un simple éditeur WYSIWYG. J’ai cette vision d’utiliser Discourse pour créer un logiciel permettant à des personnes de modifier collectivement des données structurées sans avoir besoin d’apprendre un langage de balisage. Si vous regardez de grands projets comme Wikipédia ou Wiktionnaire et toutes les formalités impliquées pour y contribuer, je vois un énorme potentiel gaspillé. Je veux changer cela. Et si je veux changer cela, je dois exploiter les fonctionnalités collaboratives de Discourse tout en abandonnant ce concept selon lequel il faut un langage de balisage pour entrer des données dans le système.
Je comprends pourquoi Markdown a été utilisé dans Discourse à l’origine, et les raisons sont très bonnes. Mais mes objectifs sont différents, donc je suis également un paradigme différent.
5 « J'aime »
Excellent plugin, @spirobel ! C’est exactement ce dont nos utilisateurs peu technophiles ont besoin, et je pense que cela va nettement fluidifier le fonctionnement de notre site. Merci pour le temps et les efforts que vous y avez consacrés. J’ai remarqué quelques problèmes qui pourraient être utiles à signaler.
Conflit avec Shared Edits
Je viens d’installer à la fois ce plugin et Discourse Shared Edits. Ce n’est guère surprenant, mais ils entrent un peu en conflit. Cependant, il semble que cela puisse être corrigé. Seriez-vous prêt à examiner la possibilité de les rendre compatibles ? Personnellement, je les considère tous deux comme indispensables à l’avenir.
Voici ce qui se passe : lorsque j’édite un message en utilisant l’éditeur de base, le texte existant du message est effacé et ne peut être récupéré qu’en annulant l’édition.
Les @mentions ne proposent pas de suggestions
L’éditeur de base de Discourse semble perturber partiellement les @mentions. Lorsque j’essaie de vous mentionner ici, j’obtiens ceci :
Lorsque j’active l’éditeur de base, les suggestions n’apparaissent plus. C’est également le cas si je clique sur Édition avancée.
6 « J'aime »
Oui, c’est encore très en cours de développement. Les mentions figurent sur ma liste. Je n’ai pas encore examiné l’édition collaborative, mais il est certainement possible de la mettre en œuvre. Cependant, cela risque de ne pas se faire en assurant la compatibilité avec le plugin d’édition collaborative. Le changement introduit par l’éditeur de base est assez significatif, il faudra donc très probablement une solution intégrée à l’éditeur de base.
4 « J'aime »
Avez-vous parlé de cela à @sam ? Il pourrait être intéressé par la possibilité et ne manquera pas de donner des conseils avisés.
1 « J'aime »