oui, je l’ai utilisé pour tester d’autres plugins récemment. Vous pouvez simplement regarder la vidéo que j’ai faite si vous êtes pressé ou l’installer localement et jouer avec le code. Je n’ai pas rendu open source la version tiptap sur laquelle j’ai commencé à travailler. J’ai également travaillé à la correction du système de brouillons. Je pense que les règles concernant le nombre de brouillons que l’on peut avoir et où ils se trouvent semblent arbitraires. Ainsi, les utilisateurs peuvent avoir autant de brouillons de nouveaux sujets qu’ils le souhaitent.
Mais comme je l’ai dit, je ne le finirai probablement pas à moins d’être vraiment, vraiment ennuyé haha
S’il n’y a pas d’incitation financière, je ne m’en soucierai tout simplement pas assez.
J’ai aussi pensé à cela. Je travaillais sur une intégration discourse-monero afin de pouvoir vendre un accès anticipé aux dépôts git (j’ai aussi envisagé d’intégrer discourse et quelque chose comme gitea ou gitlab). Mais je ne suis pas sûr s’il y a vraiment une “foule” pour mettre la “foule” dans le “financement participatif”. Il semble que les seules personnes qui paient pour discourse aient une relation commerciale avec l’entreprise derrière discourse.
Tiptap n’est pas vraiment un exemple comparable car il utilise simplement des raccourcis markdown pour convertir en HTML (à ma connaissance). Vous ne pouvez pas modifier le formatage existant à l’aide de markdown (car la syntaxe ne s’affiche pas). Vous pouvez donc aller dans un sens mais pas dans l’autre. Et pour moi, toute solution d’éditeur WYSIWYG pour Discourse qui ne rend pas en markdown dans la sortie est inacceptable. Cela brise fondamentalement la compatibilité de base et vous enferme dans le plugin d’éditeur spécifique que vous avez choisi. Je suppose que si Tiptap pouvait générer du markdown, l’approche serait correcte.
L’objectif de montrer Typora comme exemple est qu’il harmonise assez élégamment le WYSIWYG avec le markdown. Il semble que pour certains, comme @Jagster, la possibilité de conserver le comportement existant et de ne pas “sauter” entre la prévisualisation et la syntaxe serait souhaitable. Mais je pense que l’approche Typora est préférable et plus intuitive pour beaucoup d’autres personnes.
C’est excitant à entendre ! Je serais certainement intéressé par cela.
D’accord ! Je pense/espère que cela sera amélioré dans le cœur du système à l’avenir.
Bien que je ne pense pas que vous ayez tout à fait raison de dire que “seules” les personnes qui paient pour Discourse ont une relation commerciale avec CDCK (Communiteq aurait probablement quelque chose à dire à ce sujet ), je suis d’accord que pour un projet open source, Discourse a une communauté qui manque quelque peu d’“esprit communautaire” ou d’“ouverture” ou quelque chose comme ça. Je n’arrive pas tout à fait à mettre le doigt dessus, mais les choses fonctionnent certainement différemment ici que dans de nombreux autres projets open source, même ceux gérés par des entités commerciales. J’espère que de véritables efforts de financement participatif et des plugins communautaires (ou même des modifications du cœur) pourront se produire un jour. J’aimerais particulièrement voir cela autour du développement de thèmes pour des mises en page et des modifications plus avancées, comme je l’ai mentionné précédemment : Manque relatif de thèmes - est-ce que je rate quelque chose ?
J’ai déjà expliqué ma position à ce sujet. Markdown est une béquille et nous devons nous en débarrasser.
Ce n’est pas le cas. Si quelqu’un veut vraiment convertir du HTML en markdown, il peut le faire et migrer en arrière. Regardez les scripts de migration et écrivez le vôtre. Ce n’est pas grave.
Point juste.
Le problème principal est : tout ce qui n’est pas écrit en React est juste un coût irrécupérable à ce stade. Quiconque est sérieux au sujet d’avoir une carrière en développement frontend ou même quelqu’un qui veut juste faire quelque chose qui a un impact évitera tout ce qui n’est pas React.
Il faut donc une incitation financière qui contrecarre cela. L’expérience développeur n’est pas non plus très bonne. Ce n’est pas vraiment amusant de travailler avec cette base de code. Donc, la seule raison pour laquelle je continuerais à travailler sur ces choses quand je m’ennuie vraiment, c’est parce que j’y ai déjà passé tellement de temps et que je m’y suis habitué.
Le financement participatif, à mon humble avis, fonctionnerait plus facilement pour les personnes qui ne sont pas de grandes entreprises gérant des discussions. Il existe quelques plugins et composants de thème contribués par la communauté.
Les petites entreprises n’ont souvent pas de grandes réserves de fonds à investir individuellement. Mais en organisant l’intérêt, un projet financé par la communauté peut avoir un bassin égal, voire plus important.
Il suffit de trouver comment postuler. Que ce soit en utilisant quelque chose comme Donate, Patreon, etc.
Et oui, je pense que votre vision de moderniser et de rendre l’éditeur très convivial est très attrayante pour les masses.
Je ne suis pas d’accord et j’utilise Markdown partout et je suis heureux qu’il existe et qu’il soit largement pris en charge.
C’est intéressant à entendre. Je ne suis pas moi-même un développeur, donc je ne sais pas ce que c’est que de travailler avec la base de code Discourse. J’espère que votre expérience n’est pas la norme, bien que je reconnaisse également sa validité et son importance.
Serait-il mieux formulé comme suit : toute personne qui souhaite avoir le plus d’opportunités d’emploi en frontend devrait apprendre React ?
J’utilise des frameworks non-React en production depuis plus d’une décennie, de petits projets à de grands projets, du neuf à l’ancien. J’ai utilisé React dans quelques prototypes et projets personnels pour voir comment cela fonctionne. L’entreprise où je travaille actuellement emploie de bons développeurs JavaScript, quelle que soit leur expertise dans un framework particulier.
Cela risque de nous éloigner considérablement du sujet, mais cela mérite d’être discuté quelque part.
Je pense que, indépendamment de la valeur marchande immédiatement évidente, il est bon d’apprendre une variété de langages et de frameworks si l’occasion se présente, car il y a toujours une approche généralement applicable à apprendre. De plus, cela peut être la passerelle pour apprendre des choses indirectement. J’ai récemment appris Go afin de livrer un projet sur une plateforme complètement différente et cela m’a rappelé les avantages de la simplicité et de la vitesse. J’ai également beaucoup appris sur la création d’une bonne API. Si je n’avais pas fait l’effort d’apprendre Golang, je n’aurais pas eu cette expérience.
Ember est impitoyable mais apparemment bien conçu ? Le défi avec Discourse est que vous êtes également confronté à une grande plateforme sur mesure que vous devez apprendre à naviguer. Les approches d’ingénierie inverse autonome (en l’absence de documentation détaillée) que vous développez en faisant cela vous seront bénéfiques dans des domaines complètement différents.
Je dirais qu’apprendre une ou deux plateformes majeures est plus important que d’apprendre un framework spécifique. Par exemple, est-il plus important d’apprendre Wordpress que de se concentrer sur l’apprentissage de PHP ?
Je ne pense donc pas que l’apprentissage de différentes plateformes et de leurs piles technologiques individuelles devrait poser problème. Vient ensuite le réseautage professionnel qui en découle. La combinaison de toute cette expérience vous servira bien pour votre carrière.
Le principal problème que je vois ici est le conflit entre l’open source et le financement. CDCK a prouvé que la création d’une entreprise durable autour de l’open source est réalisable. Nous devons devenir assez sophistiqués pour que cela rapporte et apporte de la valeur.
Il est de la responsabilité de toute la communauté de soutenir ceux qui font progresser l’écosystème. Je suggérerais que cela commence également par la communauté qui monétise ses propres plateformes afin qu’elle puisse se permettre de contribuer. Et beaucoup l’ont fait : je suis très reconnaissant pour le travail pour lequel j’ai été financé par les hommes et femmes d’affaires les plus ambitieux et les plus travailleurs qui fréquentent ce lieu.
Le fait est que si quelqu’un commence maintenant ou est encore au début de sa carrière, il apprendra et se concentrera sur React. Se concentrer sur une technologie, c’est comme faire un pari, et parier sa carrière sur autre chose que React dans le frontend en ce moment est un mauvais choix. La seule alternative légitime pourrait être Vue, mais ce n’est certainement pas Ember.
Je dirais que le nombre de personnes ayant une carrière axée sur Ember a probablement atteint son apogée il y a un moment.
voyez-vous un afflux massif de personnes voulant apprendre Ember et la base de code Discourse ?
Je n’en vois pas. C’est un signe que c’est un logiciel obsolète. Qui a atteint le pic de son potentiel. Il n’y a pas un afflux massif de personnes voulant l’utiliser ou travailler dessus. Même après l’augmentation du travail à domicile et l’utilisation de logiciels de collaboration à distance. Les gens préfèrent utiliser Zoom et Discord.
c’est ce que j’entends par expérience développeur.
C’est un bon point. Discourse est principalement un produit : un forum communautaire/de support auto-hébergé pour un public un peu geek. Il ne sera jamais beaucoup plus que cela car c’est de là que vient son financement. Donc la plupart des décisions seront prises pour satisfaire ce public.
Pour revenir au sujet. Remplacer le compositeur markdown signifie rendre ce logiciel moins geek. Cela signifie donc une division avec le public auquel il s’adresse.
Il n’est pas facile de sortir de ce minimum local.
donc une fois qu’un logiciel a trouvé son public, une boucle de rétroaction réflexive commence qui mène à plus de fonctionnalités qui satisfont ce public, tandis que l’utilisabilité pour d’autres groupes est de plus en plus négligée.
Nous avons environ 1 000 utilisateurs actifs sur notre forum et une bonne partie d’entre eux ont plus de 50 ans, et ils s’entendent tous bien avec le markdown et nous n’avons jamais eu de plaintes.
Ce que j’en retiens : Si un groupe de fumeurs de marijuana peut maîtriser la courbe d’apprentissage du markdown, tout le monde le peut.
Il y a 3,5 millions de fumeurs de cannabis en Allemagne. 84% de tous les Allemands sont favorables à la légalisation. Je pense donc qu’il y a beaucoup de place pour la croissance de votre forum. La base d’utilisateurs actuelle et sa base d’utilisateurs potentiels sont éloignées de plusieurs ordres de grandeur. Il ne suffit pas de travailler à cet objectif en apportant de petites améliorations ou modifications.
Les changements qui apaisent la base d’utilisateurs actuelle pourraient même entraver sa croissance.
Les changements sont toujours des compromis. Ce qui peut rendre la vie plus pratique pour un utilisateur expérimenté rebutera un nouvel utilisateur. À un moment donné, la barrière est si élevée que les nouvelles inscriptions s’assèchent et que le forum se dégrade lentement.
Vous avez un bon argument. Nous pourrions vouloir interroger les anciens membres pour identifier les raisons de leur départ de notre forum. Peut-être que certains d’entre eux ont été dépassés par l’éditeur markdown.
Oui, c’est absolument représentatif de certains points que j’ai déjà soulevés concernant la chambre d’écho de Meta elle-même et des clients payants existants de CDCK. Évidemment, vous voulez satisfaire vos clients existants, mais il est également clair qu’il existe un marché global beaucoup plus large pour les « plateformes de communauté/discussion » qui est desservi par un certain nombre d’autres acteurs, dont certains font certainement des choses qui les aident à conclure une vente au lieu de Discourse. L’une de ces choses pourrait bien être le WYSIWYG, mais ce n’est qu’une partie d’un problème plus large à mon avis. La conception et le thème généraux en sont un autre, que j’ai déjà mentionné ci-dessus, mais qui mérite d’être répété dans ce contexte distinct : Manque relatif de thèmes - est-ce que je rate quelque chose ?
très bon point. Ce n’est que la pointe de l’iceberg. Il y a beaucoup de choses qui pourraient être améliorées. Par exemple, les règles idiosyncratiques sur le nombre de brouillons que vous êtes autorisé à avoir. J’ai d’abord pensé que c’était juste un bug, mais c’est en fait intentionnel tel quel.
J’essaie aussi d’aborder cela.
Bonjour, cher développeur !
Vous avez écrit le 07.2020 :
Alors, est-ce terminé ? Sinon, s’il vous plaît, soyez assez aimable pour décrire les problèmes connus et quoi faire dans le premier sujet, afin que les administrateurs des communautés Discourse personnalisées puissent facilement décider de l’utiliser ou non.
N’abandonnez pas tout de suite ! Je pense pouvoir parler au nom de nombreux autres utilisateurs ici lorsque je dis que ce Plugin serait une percée absolue pour Discourse et changerait tout, surtout dans certains cas d’utilisation. Je vous encourage vivement à continuer et à parcourir le dernier kilomètre.
Pourriez-vous élaborer ? J’en aurais peut-être besoin, donc je suis très intéressé par ce que vous avez à dire. Vous avez toute mon attention maintenant…
J’ai réfléchi davantage à cela. Je pense que ce n’est pas une bonne idée de remplacer le compositeur. Parce que cela signifie qu’il y aura toujours une lutte pour suivre les changements actuels dans Discourse et je ne veux pas passer autant de temps à le maintenir.
Je vais utiliser les connaissances que j’ai acquises à partir de cela et construire quelque chose qui fonctionne parallèlement à l’interface utilisateur de Discourse au lieu de la remplacer.
Oui, en fait, j’ai déjà examiné de près et je vais l’utiliser. Ils intègrent même Excalidraw dans l’éditeur. C’est incroyable. J’ai rejoint leur canal Discord il y a quelque temps pour discuter d’un problème lié au téléchargement d’images. Actuellement, leur exemple pour Excalidraw intègre les images en SVG, ce qui pose un problème de sécurité et doit être modifié. Il y a donc quelques petits détails à régler.
Mais comparé à CKEditor ou Tiptap, il sera beaucoup plus facile à utiliser. Pour donner également une courte mise à jour sur ce sujet en général :
Comme dit précédemment, modifier le frontend de Discourse pour quelque chose d’aussi important n’est pas une bonne idée. C’est pourquoi il est beaucoup plus judicieux d’implémenter cette fonctionnalité dans le cadre d’un ajout à l’interface traditionnelle, au lieu d’essayer de la remplacer. Les connaissances acquises jusqu’à présent dans ce travail seront utilisées ici :
Bien qu’il soit orienté vers un cas d’utilisation web3 et contienne certaines fonctionnalités web3, il n’est pas nécessaire de les utiliser.
Il sera donc possible d’utiliser ce plugin pour créer des catégories qui ont un éditeur lexical. Cela signifie également qu’il y a beaucoup moins de risques à essayer cela. Parce que l’expérience sera limitée à une seule partie du site.
Je suis actuellement encore occupé par le travail sur les abonnements aux cryptomonnaies pour Discourse. Une fois cela terminé, je me concentrerai à nouveau sur la progression de ce projet.
), je suis d’accord que pour un projet open source, Discourse a une communauté qui manque quelque peu d’“esprit communautaire” ou d’“ouverture” ou quelque chose comme ça. Je n’arrive pas tout à fait à mettre le doigt dessus, mais les choses fonctionnent certainement différemment ici que dans de nombreux autres projets open source, même ceux gérés par des entités commerciales. J’espère que de véritables efforts de financement participatif et des plugins communautaires (ou même des modifications du cœur) pourront se produire un jour. J’aimerais particulièrement voir cela autour du développement de thèmes pour des mises en page et des modifications plus avancées, comme je l’ai mentionné précédemment : 
