Entendo para onde você quer chegar. Se entendi corretamente, você deseja criar uma espécie de editor completo com funcionalidades muito mais avançadas, usando HTML para proporcionar uma experiência muito mais completa.
Eu, por um lado, adoraria ver um editor WYSIWYG que preserve a saída em Markdown. Estou menos preocupado com a capacidade de digitar e ter o Markdown interpretado automaticamente; atalhos normais, como Ctrl-B (negrito), ou uma barra de ferramentas, são suficientes. No entanto, quero preservar a editabilidade posterior, a interpretação fora de um contexto de renderização e a capacidade de exportação. E, na minha experiência, o HTML é problemático para pelo menos parte disso, se não para tudo.
Tenho curiosidade sobre o que exatamente você espera que o editor faça e que seja incompatível com a saída em Markdown?
Além disso, gostaria de destacar que o Typora faz um trabalho bastante bom ao lidar com a renderização de Markdown em linha, além de oferecer atalhos, e não vejo razão para que uma barra de formatação não pudesse funcionar também (embora ele pareça não ter uma).
Olá @ozkn!
Estou trabalhando de uma forma em que apenas o imageUpload será necessário! Então, você pode seguir a mesma linha. No seu inicializador, você pode modificar a classe do componente b-editor alterando a função setupBasicEditor.
api.modifyClass("component:b-editor", {
setupBasicEditor(){
loadScript("/plugins/DiscourseBasicEditor/ckeditor.js").then(() => {
ClassicEditor.create( document.querySelector( '#editor' ), {
toolbar: [xxx],
...
})
}
});
Confira Migrating to new installation methods | CKEditor5 documentation para referência da barra de ferramentas. No meu caso, estou apenas usando toolbar: [“imageUpload”].
Atenciosamente
E aí, pessoal! Talvez eu possa contar com um pouco de ajuda de vocês!
Estou trabalhando em um projeto no qual utilizo mais de um editor de texto (composer), assim como este (no início da página inicial, para que os usuários criem tópicos ali, semelhante ao editor principal do Facebook).
De acordo com isso, tenho enfrentado alguns problemas ao abrir o editor (talvez porque já esteja sendo usado na página principal).
Então, quando quero atualizar um tópico, uso o controlador do editor para abrir o modelo, mas recebo a mensagem b-editor.
Vocês também estão enfrentando o mesmo problema ao trabalhar com múltiplos editores?
Atenciosamente,
Felipe
Talvez você possa desativar o plugin por enquanto. Como disse, isso ainda está em desenvolvimento. Provavelmente vou trabalhar mais nisso no próximo mês. No momento, estou focado em aprender mandarim, rs. Se quiser, pode me enviar o link do seu GitHub ou me mandar seu código para que eu possa tentar entender o que você está tentando fazer.
Relatando um bug: parece que, após ativar o plugin, a seção de gerenciamento ficou coberta.
- Versão testada: Discourse 2.7.4 stable
- Navegador testado: Chrome e Firefox, tanto em computador quanto em celular
Olá, ele suportará funções de plugins adicionais de terceiros para o editor padrão, como…?
Ele suportará, em vez disso, complementos do CKEditor.
Isso é uma experiência minha de simplificação da interface que provavelmente será colocada em um plugin separado. O crescimento descontrolado de funcionalidades é ruim, haha.
Quero dizer algo: sem uma fonte de monetização, não faz sentido para mim escrever esse código. Também tentei fazer plugins de código fechado:
Mas o problema é que o código é compartilhado entre os compradores, o que significa que haveria necessidade de um fluxo constante de novos clientes que não chegam por indicação, o que dificilmente é sustentável.
Então, eu estaria interessado se você estivesse disposto a pagar por isso e se tiver alguma sugestão sobre como podemos resolver o problema do compartilhamento de código entre compradores.
Se sim, por favor, diga-me quanto nos comentários abaixo. ![]()
- sim
- não
Obrigadão
A sua nova editora WYSIWYG altera a estrutura das publicações em relação ao Discourse padrão? Em outras palavras, se o seu editor for desativado, as publicações criadas com ele terão algum problema ao serem editadas pelo editor padrão?
Você tem um plano de monetização para levantar uma quantia de dinheiro?
No momento, o editor gera Markdown, então podemos usar ambos os editores lado a lado sem nenhum problema. Mas a experiência não é perfeita e nunca será se nos mantivermos no Markdown. É por isso que a solução final produzirá HTML. Se isso for um impeditivo para alguém porque não quer ficar preso a um formato, há uma solução simples: basta converter o HTML de volta para Markdown.
Acho que não há necessidade de levantar dinheiro antecipadamente. Se eu souber que há um grupo de pessoas dispostas a pagar por isso e quanto elas pagariam, simplesmente finalizarei o código. Você também pode entrar em contato comigo em particular se se sentir desconfortável em compartilhar discussões relacionadas ao orçamento publicamente.
Você já tentou discutir essa nuance com a equipe do Discourse? Talvez eles também queiram adicionar algum novo editor WYSIWYG?
Eles optaram por não fazê-lo por motivos filosóficos. Você pode pesquisar no fórum se estiver interessado nos detalhes. Os argumentos deles são totalmente válidos e eu os respeito. É por isso que estou trabalhando nisso.
Seguindo a abordagem de "renderização de markdown no momento certo", esta parece ser uma abordagem cada vez mais popular. Roam Research e Obsidian (na última atualização adicionando WYSIWYG) fazem isso, e o já mencionado Typora. Você pode ver alguns exemplos disso na prática no site do Typora:
Esse tipo de "WYSIWYG" com a barra de ferramentas existente parece ser o melhor dos mundos para mim. A maioria das pessoas realmente não precisa de formatação além do que o markdown oferece. O que elas precisam é de uma maneira mais intuitiva de gerar e editar markdown.
Ótimo ponto. Acho que o tiptap.dev tem a melhor abordagem até agora: eles têm atalhos de teclado que fazem parecer que você está editando markdown, mas na verdade é um editor WYSIWYG adequado. Comecei a reescrever o plugin com tiptap em vez de ckeditor. Mas não o publiquei, porque não consegui financiamento para isso (eu não sou pago pelo discourse).
E eu não me importo o suficiente para trabalhar nisso no meu tempo livre.
Atenciosamente,
Spirobel
Toda vez que um usuário precisa usar (e lembrar) atalhos e comandos, o WYSIWYG não importa. A maioria das pessoas não usa nem entende markdown ou HTML. Aqueles que sabem raramente precisam de WYSIWYG e, na maioria das vezes, em cenários onde não se tem certeza absoluta de como a saída é formatada, como tabelas.
Bastante gente aqui vive em uma bolha muito restrita. Há um motivo pelo qual o WordPress é popular e o Ghost vive nas margens.
Sou só eu, mas odiei o Typora. Todo esse pulo me dá dor de cabeça.
E sim, sei que o Discourse (quase) nunca terá um WYSIWYG real, mesmo que a maioria dos usuários o amasse.
Certamente poderia ser feito. Estou talvez 80% lá. A questão é: eu não me importo o suficiente para terminar. O Discourse é mais como um produto de empresa e não como um projeto de código aberto. As pessoas aqui são na maioria funcionários da empresa ou querem usar o discourse para seus próprios projetos. Então a energia simplesmente não está lá. Talvez um dia eu esteja realmente entediado e termine só para provar um ponto. ![]()
De qualquer forma, tenha um bom dia,
Spirobel ![]()
Sim, para que os membros da comunidade façam um esforço tão grande em tais projetos, é necessário um esforço maior da comunidade para patrocinar tais projetos.
O financiamento coletivo dentro do Meta é uma área um tanto complicada, no entanto. O Pavilion está buscando maneiras de tornar isso mais direto.
Este site ainda está disponível para testar este plugin? Parece que ele ainda usa o editor interno




