Quizás esto se pueda solucionar con CSS. ¿No aparece nunca o puedes hacer scroll hacia arriba para verlo? ¿Qué navegador/sistema operativo estás usando? Quizás podamos hacerlo fijo en la parte superior. El problema es que algunos navegadores recientemente intentaron ser “creativos” y movieron la barra del navegador a la parte inferior.
Los navegadores son Firefox y Chrome en Android en un teléfono Motorola. Lo mismo ocurre con la aplicación de Discourse.
La barra de botones siempre está presente, solo se encuentra debajo de un menú emergente cuando la selección está en las primeras 3 líneas visibles en el cuadro de texto.
Una solución alternativa es insertar 3 CR/LF (retorno de carro/salto de línea) antes del primer texto. Luego, elimina esos caracteres extra antes de publicar.
1 me gusta
Sí, acabo de probarlo. Entiendo lo que dices. Es súper molesto. Pero creo que las barras en la parte inferior son aún peores. Además, necesito investigar cómo hacer esto y no me pagan por ello. Probablemente exista una forma más limpia de hacerlo. Apuesto a que otros proyectos tienen el mismo problema y que hay una solución estandarizada. Pero, como dije, tengo otras prioridades. Perdona por ser tan directo 
EDITO: solo una nota. Hay una forma de desactivar el clic derecho (doble clic en móviles). https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript pero entonces los usuarios no pueden copiar. Es un desastre…
3 Me gusta
La solución temporal es viable, solo inconveniente.
Probablemente exista un enfoque con CSS móvil para esta molestia. Tendré que buscarlo.
Agregar mucho código para este caso especial no sería un buen uso de tu tiempo y atención. (Además, añade sobrecarga.) Gracias por compartir tus proyectos con la comunidad. Ha sido muy generoso de tu parte.
3 Me gusta
OK, muchas gracias por el informe. Acabo de solucionarlo
6 Me gusta
Un consejo: Rails agrega el método .present? en algunas clases de Ruby, lo cual es mejor que comparar con cadenas vacías. Funciona principalmente con arrays y cadenas.
También existe .empty?, que es lo opuesto a .present?.
5 Me gusta
Eliminé este botón a propósito porque las imágenes deben subirse a través del editor. Sin embargo, acabo de descubrir que, por alguna razón, el menú de selección de archivos no se abre en Android Firefox. Para investigar esto, necesito instalar la depuración remota, por lo que llevará algo de tiempo solucionarlo. Hasta entonces, simplemente usa el editor avanzado para subir imágenes.
EDITO: en realidad funciona perfectamente. No se abría porque antes había denegado el acceso a la cámara de la aplicación. Así que puedes usar el mismo botón de subida de imágenes que usarías en el escritorio. Si tienes dudas, mira la captura de pantalla que subí para probarlo:
https://cidian.social/t/file-upload-from-mobile/292
1 me gusta
Quiero habilitar solo las opciones de Negrita, Cursiva, Enlace y Carga de imagen dentro de la barra de herramientas. ¿Cómo puedo hacerlo?
1 me gusta
Agregaré una opción para configurarlo una vez que esté listo.
4 Me gusta
¿Significa que no hay solución alternativa para esto? ¿No puedo editar el archivo de configuración del CKEditor que has utilizado dentro del plugin?
¿Vas a hacerlo compatible con otros plugins como, por ejemplo, la anotación de imágenes, el formato BB, etc.?
3 Me gusta
Vale, déjame aclarar algo: cuando hablo de «cosas que no funcionan», me refiero simplemente a que no se renderizan en la ventana de entrada WYSIWYG. Todo sigue funcionando en la publicación final. Este editor es solo una forma diferente de crear Markdown por ahora. Al final, lo que se genera sigue siendo Markdown. Desde mi punto de vista, «solo HTML» es el camino a seguir en el futuro. Markdown, BBCode, etc., son cosas del pasado que ofrecen una experiencia de usuario excesivamente compleja. Pero, obviamente, no voy a implementar todas las funciones de BBCode ni los plugins personalizados, porque no obtengo ningún beneficio de ello. Lo primero y más importante es que me importa mi caso de uso. Pero también me importa simplificar la experiencia de usuario de Discourse para los demás. Si te gusta Markdown, BBCode y todos esos «etiquetas» en tu editor, entonces quizás esto no sea lo adecuado para ti.
También me gustaría que esta discusión fuera más constructiva. Me encantaría conocer los casos de uso y las razones por las que la gente quiere usar un editor WYSIWYG en lugar del actual. También me interesa saber qué beneficios esperan obtener de esto y qué objetivos quieren lograr.
Quizás eso nos lleve a algún lado. Preguntar «¿puedes hacer todas estas cosas aleatorias? … (de forma gratuita)» no es útil.
Saludos cordiales,
Spirobel
6 Me gusta
Cambiar a HTML y no admitir Markdown hará que todas las publicaciones creadas en HTML no sean editables una vez que se desactive tu plugin. ¿Es esto correcto?
1 me gusta
@spirobel aunque personalmente no uso tu plugin, admiro su funcionalidad y te saludo por tu gran esfuerzo!
Aunque puedo estar de acuerdo en que bbcode es una sintaxis heredada, la noción de que Markdown es cosa del pasado es incorrecta desde mi punto de vista; todo lo contrario, el conjunto básico de funciones se mantendrá durante mucho tiempo.
Las dos razones principales son;
- Formateo al escribir: puedes formatear el texto correctamente simplemente escribiendo, lo que facilita concentrarse y escribir de manera productiva.
- Legible incluso sin renderizar: la sintaxis básica de Markdown es instintivamente legible como texto sin formato, lo cual es muy útil por muchas razones.
Es cuando intentas extender las funciones de Markdown (imágenes, tablas, etc.) que, en mi opinión, tiende a fallar y a veces romperse debido a una sintaxis ilegible que resulta engorrosa de escribir.
En mi opinión, los mejores editores ofrecen una solución híbrida;
- El formateo de sintaxis básica se renderiza en línea, pero también se muestran los caracteres de sintaxis en el modo de edición.
- Las funciones extendidas (imágenes, tablas, etc.) también deben renderizarse obviamente en el modo de edición, y quizás no representarse mediante los caracteres de sintaxis reales en pantalla. Quizás, me atrevo a decir, deberían considerarse como complementos y almacenarse en un formato más adecuado para el tipo de datos.
6 Me gusta
¡Muchas gracias por tu comentario!
Entiendo lo que quieres decir, pero sigo sin estar de acuerdo. 
A largo plazo, los usuarios avanzados se benefician más con los atajos de teclado. Por ejemplo, podría haber un atajo para el cursiva, de modo que puedas usarlo mientras sigues escribiendo. El atajo podría ser algo como CTRL+*, casi como usar Markdown.
En cuanto al punto 2, puedo decir que HTML también es legible, ya que siempre se renderiza (en el navegador) y, si observas un fragmento de HTML en un editor de texto, también puedes leerlo. Está bien, Markdown puede verse un poco más elegante, pero solo si te limitas a funciones muy básicas; de todos modos, en ese caso no importa demasiado.
La solución híbrida, lamentablemente, no es viable. Una de las razones por las que me he decantado por HTML es que me permite centrarme en construir una interfaz de usuario en lugar de obtener un doctorado en lingüística computacional mientras depuro errores en el analizador de lenguaje. La idea es reducir la deuda técnica, no aumentarla.
Al final, entiendo perfectamente tu punto de vista. También he leído la escritura sobre Markdown. Pero para mí, el paradigma de solo HTML es más convincente para lo que tengo previsto hacer. También soy consciente de que no tiene sentido convencer a quienes realmente les gusta Markdown. Ellos deberían quedarse con el editor tal como está ahora. Sin embargo, creo que hay otro grupo de personas que podría estar interesado en tomar un camino diferente. Este plugin es mucho más que un editor WYSIWYG. Tengo la visión de utilizar Discourse para crear software que permita a las personas editar datos estructurados de forma colaborativa sin necesidad de aprender un lenguaje de marcado. Si observas proyectos grandes como Wikipedia o Wikcionario y todas las formalidades implicadas en contribuir a ellos, ves un potencial desperdiciado enorme. Quiero cambiar eso. Y si quiero lograrlo, necesito aprovechar las funciones colaborativas de Discourse, pero descartar la idea de que se requiere un lenguaje de marcado para ingresar datos en el sistema.
Entiendo por qué se usó Markdown en Discourse desde el principio y las razones son muy buenas. Pero mis objetivos son diferentes, por lo que también sigo un paradigma distinto.
5 Me gusta
¡Excelente complemento, @spirobel! Esto es exactamente lo que necesitan nuestros usuarios no técnicos y creo que agilizará notablemente el funcionamiento de nuestro sitio. Gracias por el tiempo y el esfuerzo que has dedicado a ello. He notado un par de problemas que podrían ser útiles.
Conflicto con Ediciones Compartidas
Acabo de instalar tanto este complemento como Discourse Shared Edits. No es muy sorprendente que entren en conflicto un poco, pero parece que podría solucionarse. ¿Considerarías trabajar en hacerlos compatibles? Personalmente, creo que ambos serán indispensables en el futuro.
Lo que sucede es que, cuando edito una publicación compartida usando el Editor Básico, el texto existente en la publicación se borra y solo se puede recuperar deshaciendo la edición.
@menciones sin sugerencias
El Editor Básico de Discourse parece romper parcialmente la función de @menciones. Cuando intento mencionarte aquí, obtengo esto:
Cuando activo el Editor Básico, las sugerencias ya no aparecen. Esto también ocurre si hago clic en Edición Avanzada.
6 Me gusta
Sí. Esto sigue siendo un trabajo en progreso. Las menciones están en mi lista. Aún no he revisado la edición compartida, pero es definitivamente posible implementarla. Sin embargo, es probable que no se logre garantizando la compatibilidad con el plugin de ediciones compartidas. El cambio que introduce el editor básico es bastante significativo, por lo que muy probablemente requerirá una solución dentro del propio editor básico.
4 Me gusta
¿Has hablado con @sam sobre esto? Podría estar interesado en la posibilidad y seguramente dará consejos sabios.
1 me gusta