Talvez isso possa ser corrigido com CSS. Ele nunca aparece ou você pode rolar para cima para vê-lo? Qual navegador/sistema operacional você está usando? Talvez possamos torná-lo fixo, mas no topo. O problema é que alguns navegadores recentemente tentaram ser “criativos” e moveram a barra do navegador para a parte inferior.
Os navegadores são Firefox e Chrome no Android, em um telefone Motorola. O mesmo acontece com o aplicativo Discourse.
A barra de botões está sempre lá, apenas fica escondida sob um menu pop-up sempre que a seleção está nas 3 primeiras linhas visíveis na caixa de texto.
Uma solução alternativa é inserir 3 quebras de linha (CR/LF) antes do primeiro texto. Depois, apague essas linhas extras antes de publicar.
1 curtida
Sim, acabei de testar. Entendo o que você quer dizer. É super irritante. Mas acho que as barras na parte inferior são ainda piores. Além disso, preciso pesquisar como fazer isso e não sou pago por isso. Provavelmente existe uma maneira mais limpa de fazer. Aposto que outros projetos têm o mesmo problema e há uma solução padronizada. Mas, como disse, tenho outras prioridades. Desculpe ser tão franco 
EDIT: só uma nota. Existe uma maneira de desativar o clique direito (duplo clique no mobile). https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript mas aí os usuários não conseguem copiar. É uma bagunça…
3 curtidas
A solução alternativa é viável, apenas inconveniente.
Provavelmente existe uma abordagem com CSS para dispositivos móveis para resolver essa chateação. Vou apenas ter que procurá-la.
Adicionar muito código para esse caso especial não seria um bom uso do seu tempo e atenção. (Além disso, isso adiciona sobrecarga.) Obrigado por compartilhar seus projetos com a comunidade. Foi muito generoso da sua parte.
3 curtidas
ok, muito obrigado pelo relatório. Acabei de corrigi-lo
6 curtidas
Apenas uma dica: o Rails adiciona o método .present? em algumas classes do Ruby, o que é melhor do que comparar com strings vazias. Ele funciona principalmente com arrays e strings.
Também existe o .empty?, que é o oposto do .present?.
5 curtidas
Eu removi este botão de propósito, pois as imagens precisam ser enviadas através do editor. Mas acabei de descobrir que o menu de seleção de arquivos não abre no Firefox para Android, por algum motivo. Para investigar isso, preciso instalar a depuração remota, então vai levar algum tempo para corrigir. Até lá, use apenas o editor avançado para enviar imagens.
EDIT: na verdade, funciona perfeitamente. Só não abria porque eu havia negado o acesso da câmera ao aplicativo antes. Então, você pode usar o mesmo botão de envio de imagens que usaria no desktop. Se estiver confuso, veja a captura de tela que enviei para testar:
https://cidian.social/t/file-upload-from-mobile/292
1 curtida
Quero habilitar apenas as opções de Negrito, Itálico, Link e Upload de Imagem na barra de ferramentas. Como faço isso?
1 curtida
Adicionarei uma opção para configurá-lo assim que estiver pronto.
4 curtidas
Isso significa que não há nenhuma solução alternativa para isso? Não posso editar o arquivo de configuração do CKEditor que você usou dentro do plugin?
Vocês vão fazer funcionar com outros plugins como, por exemplo, Image Annotation, BB markup, etc?
3 curtidas
Ok, deixe-me esclarecer algo: quando falo sobre “coisas que não estão funcionando”, quero dizer apenas que elas não são renderizadas na janela de entrada WYSIWYG. Tudo ainda funciona na postagem final. Este editor é apenas uma maneira diferente de criar Markdown no momento. No final, ainda sai Markdown. Do meu ponto de vista, “apenas HTML” é o caminho a seguir no futuro. Markdown, BBCode, etc., são coisas do passado que entregam uma experiência de usuário excessivamente complexa. Mas, obviamente, não vou implementar todos os recursos de BBCode ou plugins personalizados. Porque não obtenho nenhum benefício com isso. Em primeiro lugar, me importo com meu caso de uso. Mas também me importo em simplificar a UX do Discourse para os outros também. Se você gosta de Markdown, BBCode e todas essas “tags” no seu editor, então talvez isso não seja o ideal para você.
Gostaria também que essa discussão se tornasse mais construtiva. Fico feliz em ouvir sobre os casos de uso e as razões pelas quais as pessoas querem usar um editor WYSIWYG em vez do atual. Também estou interessado em saber quais benefícios vocês esperam obter com isso e quais objetivos desejam alcançar?
Talvez isso nos leve a algum lugar. “Você pode fazer todas essas coisas aleatórias? …(de graça)” não é útil.
Atenciosamente,
Spirobel
6 curtidas
A mudança para HTML e o desamparo do Markdown farão com que todas as postagens criadas em HTML fiquem ineditáveis assim que seu plugin for desativado. Está correto?
1 curtida
@spirobel, embora eu pessoalmente não use seu plugin, admiro sua funcionalidade e parabenizo você pelo seu grande esforço!
Embora eu possa concordar que o bbcode seja uma sintaxe legada, a ideia de que o Markdown é coisa do passado está incorreta, na minha opinião – quite o contrário, o conjunto básico de recursos veio para ficar por muito tempo.
As duas principais razões são:
- Formatação por digitação – você pode formatar o texto corretamente apenas digitando, o que facilita o foco e a produtividade na digitação.
- Legível mesmo sem renderização – a sintaxe básica do Markdown é instintivamente legível como texto puro, o que é muito útil por várias razões.
É quando você tenta estender os recursos do Markdown (imagens, tabelas etc.) que, na minha opinião, ele tende a falhar e, às vezes, quebrar devido a uma sintaxe ilegível, que é trabalhosa de digitar.
Na minha visão, os melhores editores oferecem uma solução híbrida:
- A formatação básica de sintaxe é renderizada em linha, mantendo os caracteres de sintaxe visíveis no modo de edição.
- Recursos estendidos (imagens, tabelas etc.) também devem ser renderizados naturalmente no modo de edição e, talvez, não serem representados pelos caracteres de sintaxe na tela. Talvez, atrevo-me a dizer, devam ser considerados como plugins e armazenados em um formato mais adequado ao tipo de dado.
6 curtidas
Muito obrigado pelo seu comentário!
Entendo o que você quer dizer. Mas ainda discordo. 
A longo prazo, usuários avançados são melhor atendidos com atalhos. Por exemplo, poderia haver um atalho para itálico. Assim, você poderia pressionar o atalho enquanto continua digitando. O atalho poderia até ser algo como CTRL+*, quase como usar markdown.
Sobre o ponto 2, posso dizer que o HTML também é legível, pois é sempre renderizado (no navegador) e, se você olhar um trecho de HTML em um editor de texto, também consegue lê-lo. Bem, o markdown pode parecer um pouco mais bonito, mas apenas se você se ater a recursos muito básicos e, mesmo assim, não importa de qualquer forma.
A solução híbrida, infelizmente, não é viável. Uma das razões pelas quais bebi o “kool-aid” do HTML puro é que isso me permite focar em construir uma interface de usuário, em vez de fazer um doutorado em linguística computacional enquanto depuro bugs no parser de linguagens. A ideia é reduzir a dívida técnica, não aumentá-la.
No final, consigo entender muito bem sua perspectiva. Também li os textos sobre markdown. Mas, para mim, o paradigma de HTML puro é mais convincente para o que pretendo fazer. Também percebo que não faz sentido tentar convencer pessoas que realmente gostam de markdown. Elas devem continuar usando o editor como está agora. Mas acredito que há um público diferente que pode se interessar por seguir um caminho diferente. Este plugin é muito mais do que apenas um editor WYSIWYG. Tenho a visão de usar o Discourse para criar software que permita às pessoas editar dados estruturados coletivamente, sem precisar aprender uma linguagem de marcação. Se você observar grandes projetos como Wikipedia ou Wikcionário e todas as formalidades envolvidas na contribuição para eles, verá tanto potencial desperdiçado. Quero mudar isso. E, se quero mudar isso, preciso aproveitar os recursos colaborativos do Discourse, mas descartar a ideia de que é necessário uma linguagem de marcação para inserir dados no sistema.
Entendo por que ela foi usada no Discourse inicialmente e os motivos são realmente bons. Mas meus objetivos são diferentes, então também sigo um paradigma diferente.
5 curtidas
Ótimo plugin, @spirobel! É exatamente isso que nossos usuários nada técnicos precisam e acho que isso vai alavancar consideravelmente o funcionamento do nosso site. Obrigado pelo tempo e esforço que você dedicou a isso. Notei alguns problemas que podem ser úteis.
Conflito com Edições Compartilhadas
Acabei de instalar este plugin e o Discourse Shared Edits. Não foi muito surpreendente, mas eles conflitam um pouco. No entanto, parece que o problema pode ser resolvido. Você consideraria verificar como torná-los compatíveis? Pessoalmente, vejo ambos como indispensáveis no futuro.
O que acontece é que, quando faço uma edição compartilhada em uma postagem usando o Editor Básico, o texto existente na postagem é apagado e só pode ser recuperado revertendo a edição.
@menções sem sugestões
O Discourse Basic Editor parece quebrar parcialmente a funcionalidade de @menções. Quando tento mencioná-lo aqui, recebo isso:
Quando ativo o Editor Básico, as sugestões deixam de aparecer. Isso também ocorre se eu clicar em Edição Avançada.
6 curtidas
Sim. Isso ainda está em desenvolvimento. As menções estão na minha lista. Ainda não analisei a edição compartilhada, mas certamente é possível implementá-la. No entanto, é provável que isso não aconteça ao garantir compatibilidade com o plugin de edições compartilhadas. A mudança introduzida pelo editor básico é bastante significativa, então muito provavelmente será necessário uma solução dentro do próprio editor básico.
4 curtidas
Você já conversou com @sam sobre isso? Ele pode se interessar pela possibilidade e certamente dará conselhos sábios.
1 curtida