Возможно, это можно исправить с помощью CSS. Элемент вообще не отображается или вы можете прокрутить страницу вверх, чтобы увидеть его? Какой браузер и операционную систему вы используете? Возможно, мы можем сделать его зафиксированным (sticky) в верхней части. Проблема в том, что некоторые браузеры недавно решили проявить «креативность» и переместили адресную строку вниз.
Браузеры: Firefox и Chrome на Android на телефоне Motorola. То же самое происходит и с приложением Discourse.
Панель кнопок всегда присутствует, но она находится под всплывающим меню, когда выделение находится в первых трёх видимых строках текстового поля.
Обходной путь: вставьте 3 символа перевода строки (CR/LF) перед первым текстом. Затем удалите эти лишние символы перед публикацией.
Да, я только что проверил. Понимаю, о чём ты. Это действительно раздражает. Но, на мой взгляд, панели внизу ещё хуже. К тому же мне нужно изучить, как это реализовать, а за это мне не платят. Но, вероятно, есть более чистое решение. Уверен, что другие проекты сталкиваются с той же проблемой и существует стандартизированный подход. Но, как я уже сказал, у меня сейчас другие приоритеты. Извини за прямоту ![]()
РЕДАКТИРОВАНИЕ: просто заметка. Есть способ отключить правый клик (двойной клик на мобильных). https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript но тогда пользователи не смогут копировать. Это просто хаос…
Обходной путь возможен, просто неудобен.
Вероятно, для этого раздражающего момента существует решение с помощью мобильного CSS. Мне придётся его найти.
Добавление большого объёма кода для этого частного случая не было бы лучшим использованием вашего времени и внимания. (К тому же это создаёт лишние накладные расходы.) Спасибо, что делитесь своими проектами с сообществом. Это очень щедро с вашей стороны.
Спасибо большое за отчет. Я только что исправил это:
Совет: Rails добавляет метод .present? в несколько классов Ruby, что лучше, чем сравнение с пустыми строками. Он в основном работает с массивами и строками.
Также существует .empty?, который является противоположностью .present?.
Я намеренно убрал эту кнопку, так как изображения нужно загружать через редактор. Но я только что обнаружил, что меню выбора файлов по какой-то причине не открывается на Android в Firefox. Чтобы разобраться в этом, мне нужно настроить удалённую отладку, поэтому на исправление потребуется некоторое время. До тех пор используйте расширенный редактор для загрузки изображений.
ОБНОВЛЕНИЕ: на самом деле всё работает отлично. Просто оно не открывалось, потому что я ранее запретил приложению доступ к камере. Так что вы можете использовать ту же кнопку загрузки изображений, что и на компьютере. Если возникнут вопросы, посмотрите на скриншот, который я загрузил для проверки:
https://cidian.social/t/file-upload-from-mobile/292
Я хочу включить только опции жирного шрифта, курсива, ссылки и загрузки изображений в панели инструментов. Как это сделать?
Как только это будет сделано, я добавлю возможность его настроить.
Это значит, что обходного пути нет? Не могу ли я отредактировать файл конфигурации ckeditor, который используется внутри плагина?
Собираетесь ли вы обеспечить совместимость с другими плагинами, такими как, например, Image Annotation, BB-разметка и т. д.?
Хорошо, давайте проясним один момент: когда я говорю о том, что «что-то не работает», я имею в виду лишь то, что это не отображается в окне визуального редактора (WYSIWYG). В конечном посте всё работает корректно. На данный момент этот редактор — просто альтернативный способ создания Markdown-разметки. В итоге всё равно получается Markdown. С моей точки зрения, в будущем стоит ориентироваться на вариант «только HTML». Markdown, BBCode и подобные технологии — это уже прошлое, которое создаёт излишне сложный пользовательский опыт. Однако я, разумеется, не буду реализовывать каждую отдельную функцию BBCode или пользовательские плагины, поскольку не вижу в этом для себя никакой пользы. В первую очередь я ориентирован на свой конкретный случай использования. Но мне также важно упростить пользовательский опыт в Discourse для других. Если вам нравятся Markdown, BBCode и все эти «теги» в редакторе, возможно, это решение вам не подойдёт.
Я также хотел бы, чтобы наша дискуссия стала более конструктивной. Буду рад узнать о конкретных сценариях использования и причинах, по которым люди хотят использовать визуальный редактор вместо текущего. Мне также интересно услышать, каких преимуществ вы от этого ожидаете и каких целей хотите достичь?
Возможно, это поможет нам найти общее решение. Фразы вроде «вы можете сделать все эти случайные вещи? … (бесплатно)» не приносят пользы.
С уважением,
Spirobel
Переход на HTML и отказ от поддержки Markdown приведут к тому, что все посты, созданные в HTML, станут неизменяемыми после отключения вашего плагина. Верно ли это?
@spirobel, хотя я лично не использую ваш плагин, я восхищаюсь его функциональностью и приветствую ваши огромные усилия!
Хотя я согласен с тем, что bbcode — это устаревший синтаксис, утверждение о том, что Markdown остался в прошлом, с моей точки зрения неверно — скорее наоборот: базовый набор функций останется с нами надолго.
Основные две причины:
- Форматирование при наборе — вы можете правильно форматировать текст, просто печатая, что позволяет сосредоточиться и продуктивно работать.
- Читаемость даже без рендеринга — базовый синтаксис Markdown интуитивно понятен как исходный текст, что очень удобно по многим причинам.
Проблемы возникают, когда вы пытаетесь расширить возможности Markdown (изображения, таблицы и т. д.). В таких случаях он, на мой взгляд, начинает давать сбои и иногда ломается из-за нечитаемого синтаксиса, который неудобно вводить.
По моему мнению, лучшие редакторы предлагают гибридное решение:
- Базовый синтаксис форматирования отображается внутри строки, при этом символы синтаксиса остаются видимыми в режиме редактирования.
- Расширенные функции (изображения, таблицы и т. д.) также должны отображаться в режиме редактирования, и, возможно, не должны представляться символами синтаксиса на экране. Может быть, осмелюсь сказать, их стоит рассматривать как плагины и хранить в формате, наиболее подходящем для типа данных.
Большое спасибо за ваш комментарий!
Я понимаю, что вы имеете в виду. Но я всё же не согласен.
В долгосрочной перспективе продвинутым пользователям больше подходят горячие клавиши. Например, можно добавить сочетание клавиш для курсива. Тогда вы сможете нажимать его прямо во время набора текста. Это сочетание может быть даже таким простым, как CTRL+*, что почти эквивалентно использованию Markdown.
Что касается пункта 2, то я могу сказать, что HTML тоже читаем, поскольку он всегда отображается (в браузере), и даже если посмотреть на фрагмент HTML в текстовом редакторе, его можно прочитать. Да, Markdown может выглядеть немного приятнее, но только если ограничиться самыми базовыми функциями, и в любом случае это не имеет большого значения.
Гибридное решение, к сожалению, невозможно. Одна из причин, по которой я принял философию «только HTML», заключается в том, что это позволяет мне сосредоточиться на создании пользовательского интерфейса, а не получать докторскую степень по компьютерной лингвистике, отлаживая ошибки парсера языка. Идея состоит в том, чтобы сократить технический долг, а не увеличивать его.
В конце концов, я очень хорошо понимаю вашу позицию. Я тоже читал документацию по Markdown. Но для меня парадигма «только HTML» более убедительна в контексте моих задач. Я также осознаю, что нет смысла убеждать тех, кто действительно любит Markdown. Им следует остаться с редактором в его нынешнем виде. Однако я думаю, что есть другая аудитория, которая может заинтересоваться другим подходом. Этот плагин — гораздо больше, чем просто WYSIWYG-редактор. У меня есть видение: использовать Discourse для создания программного обеспечения, которое позволит людям совместно редактировать структурированные данные без необходимости изучать язык разметки. Если посмотреть на такие крупные проекты, как Википедия или Викисловарь, и на все формальности, связанные с внесением в них вкладов, можно увидеть огромный нереализованный потенциал. Я хочу это изменить. И чтобы изменить это, мне нужно использовать возможности совместной работы в Discourse, но отказаться от концепции необходимости языка разметки для ввода данных в систему.
Я понимаю, почему Markdown был использован в Discourse изначально, и причины этого действительно веские. Но мои цели другие, поэтому я и выбираю другую парадигму.
Отличный плагин, @spirobel! Именно это нужно нашим пользователям, далёким от технологий, и я считаю, что это значительно упростит работу нашего сайта. Спасибо за время и усилия, которые вы вложили в его создание. Я заметил несколько проблем, которые могут быть полезны.
Конфликт с Shared Edits
Я только что установил этот плагин и Discourse Shared Edits. В некоторой степени неудивительно, что они немного конфликтуют. Но, похоже, это можно исправить. Не рассматривали ли вы возможность сделать их совместимыми? Лично я считаю, что оба плагина станут незаменимыми в будущем.
Суть проблемы в том, что при редактировании сообщения с помощью базового редактора в режиме «Shared Edit» существующий текст в сообщении удаляется, и его можно восстановить только путём отката правки.
@упоминания не предлагают подсказки
Базовый редактор Discourse частично ломает функцию @упоминаний. Когда я пытаюсь упомянуть вас здесь, я получаю следующее:
При активации базового редактора подсказки больше не появляются. То же самое происходит, если я переключаюсь на расширенное редактирование.
Да, это всё ещё находится в стадии активной разработки. Упоминания уже включены в мой список задач. Я ещё не изучал возможность совместного редактирования, но его определённо можно реализовать. Однако это, скорее всего, не будет достигнуто за счёт обеспечения совместимости с плагином для совместного редактирования. Внесённые базовым редактором изменения довольно значительны, поэтому решение, вероятнее всего, потребуется реализовать непосредственно внутри базового редактора.
Вы обсуждали это с @sam? Ему может быть интересна эта возможность, и он наверняка даст мудрый совет.


