Отличный бб-редактор для сайта

Сергей, нееееет, это все не то.

Опубликовано в блоге

Ну а толку собирать все подряд и делать? Есть два редактора родных, в них добавить нужные функции и выложить, нет вот эту простыню из 15 редакторов крутим и один другого хуже с каждым разом, или ради иконок новых?

Ну а толку собирать все подряд и делать? Есть два редактора родных, в них добавить нужные функции и выложить, нет вот эту простыню из 15 редакторов крутим и один другого хуже с каждым разом, или ради иконок новых?

Зачем Вы так? Хороший редактор, пусть людям будет из чего выбирать. Это же не значит, что если адаптировали этот, то за родной забудут. Возможно, их и объединят когда-то.

Зачем Вы так? Хороший редактор, пусть людям будет из чего выбирать. Это же не значит, что если адаптировали этот, то за родной забудут. Возможно, их и объединят когда-то.

Посчитайте сколько редакторов уже сделано, я ценю труд Майка и других, но такое впечатление, что делается лишь бы сделать. Ведь как использовался стандартный так и используется. Один кривой, второй не имеет того, в третьем глючит, в четвертом загрузка не работает. Глаза разбегаются, а по сути все кроме стандартных не работают толком.

Ну так и в стандартном тоже не всегда гладко. Ведь каждый новый редактор — это новый опыт. К примеру, мне очень нравится, что при форматировании текста сразу показывает, как в визуальном редакторе. Так же есть возможность выбора цвета текста, чего стандартному не хватает. В свою же очередь он не имеет возможности загрузки своей картинки. Если бы выбрать как-то все самое лучшее из редакторов и соединить в один — был бы идеал, не спорю. Но перед этим нужно же испытать другие…

Я объясню, свою позицию (естественно по собственным впечатлениям и предпочтениям):
1. Встроенный редактор с ББ-кодами, на данный момент, самый удобный для наращивания функционала;
2. Без серьезного вмешательства в ядро, многие вещи сделать не удастся (хак);
3. Можно прибегнуть к обходным путям и вынести изменяемые файлы в директорию с плагином, но при этом потеряется сквозная связь со встроенной версией;
4. Весь новый функционал и новые возможности не будут работать со старыми записями;
5. На “выходе” должен получаться “грамотный” html с разделением разметки и стилевого оформления и, соответственно, SEO дружественный, при этом должна остаться гибкость настройки под конкретные компоненты iCMS (форум, блоги, стены пользователей и клубов, записи каталога, товары, статьи, комментарии, система личных сообщений);
6. Должна быть возможность повторного редактирования элементов записи, с тем же удобством, как и при первой вставке;
7. Для всего выше перечисленного должны быть задействованы, по-возможности, штатные функции iCMS;
8. Редактор должен максимально просто встраиваться как в существующие так и в сторонние компоненты;
9. Новый функционал для редактора добавляется как и сейчас через плагины;

Ну и остаются парочка вопросов: делать его “реалтайм превью” или “по кнопке” и что при этом использовать вставку ББ-кодов или сразу теги html…

Перечисленным выше условиям ни один из “сторонних” редакторов не соответствует, а “прикручиваю” я их не для разнообразия выбора, а для тестирования функционала и возможностей и удобства его расширения, ну и плюс смотрю что они дают на “выход”…

1. Встроенный редактор с ББ-кодами, на данный момент, самый удобный для наращивания функционала;
2. Без серьезного вмешательства в ядро, многие вещи сделать не удастся (хак);
3. Можно прибегнуть к обходным путям и вынести изменяемые файлы в директорию с плагином, но при этом потеряется сквозная связь со встроенной версией;
4. Весь новый функционал и новые возможности не будут работать со старыми записями;
5. На “выходе” должен получаться “грамотный” html с разделением разметки и стилевого оформления и, соответственно, SEO дружественный, при этом должна остаться гибкость настройки под конкретные компоненты iCMS (форум, блоги, стены пользователей и клубов, записи каталога, товары, статьи, комментарии, система личных сообщений);
6. Должна быть возможность повторного редактирования элементов записи, с тем же удобством, как и при первой вставке;
7. Для всего выше перечисленного должны быть задействованы, по-возможности, штатные функции iCMS;
8. Редактор должен максимально просто встраиваться как в существующие так и в сторонние компоненты;
9. Новый функционал для редактора добавляется как и сейчас через плагины;

1. Согласен
2. Например?
3. А может не надо выносить? тут я незнаю о каких функциях вы говорите.
4. Конвертнуть, что я и сделал, после изменения тегов ББ редактора.
5. Непростой вопрос, но чуть бы конкретнее
6. Согласен, а почему её не будет?
7. Согласен.
8. Согласен
9. Пример выровнять по ширине добавляем просто код.

Думаю не хватает ясности, так как каждый хочет свое от редактора. Давайте попробуем определить что должен делать редактор для минимального удобства хотя бы.

2. Например мульти-загрузчик для фото
3. Если не выносить, до них будет так же как и сейчас не просто “добраться”, т.е. придётся редактировать файлы ядра каждый раз при обновлениях и внесении изменений для сторонних компонентов
4. Например для фото у меня на данный момент предусмотрено 7 опций (необязательных, конечно), но вставляются они пока по старой схеме в коде ББ и парсер их учитывает, значит, придётся открывать все старые записи и добавлять всё в ручную
5. Учитывающий вложенность тегов их правильное применение по назначению, с присвоением классов для стилей
6. Её сейчас нет, а с “накруткой” функционала необходимость появляется
9. Ага правим библиотеку вместо допустим стиля

Так как каждый хочет своё, единственный путь — разнообразие настроек и удобное добавление своих функций, например по некому шаблону в админке

В общем “голые” идеи обсуждать сложно, гораздо проще “пощупать в живую” и смотреть в том направлении двигаешься или нет…

В общем “голые” идеи обсуждать сложно, гораздо проще “пощупать в живую” и смотреть в том направлении двигаешься или нет…

Согласен и всегда ценил ваш труд. Только вот движение странное, в сторону редакторов, которые не дотягивают до уровня того что уже есть. Если идти в улучшение, то брать редактор ВП например, который заточен под записи и уже сделать пусть не идеальный, но хотя бы лучше того что есть.

2. Например мульти-загрузчик для фото
3. Если не выносить, до них будет так же как и сейчас не просто “добраться”, т.е. придётся редактировать файлы ядра каждый раз при обновлениях и внесении изменений для сторонних компонентов
4. Например для фото у меня на данный момент предусмотрено 7 опций (необязательных, конечно), но вставляются они пока по старой схеме в коде ББ и парсер их учитывает, значит, придётся открывать все старые записи и добавлять всё в ручную

Да берете далеко, буду рад если получится.

Только вот движение странное, в сторону редакторов, которые не дотягивают до уровня того что уже есть.

Это один из потоков…) параллельный, но не единственный…
Схема простая — разберись с тем что уже существует и сделано до тебя и сделай свое и по-своему учитывая полученный опыт…
Скоро выложу в блоге очередную версию, можно будет обсудить конкретику…

• Mike •, а действительно, зачем привязываться к разметке которая в базе хранится? сделать единый редактор и конвертнуть записи в базе под него.

все редакторы на данный момент "кастрированные", черт с ним с визивнгом, но нужна банальная мультизагрузка фоток к посту и хоть минимальный предпросмотр. и редактор на сайте должен быть один. с точки зрения админа — разницы нет и разобраться дело 5 минут как и что работает в другом редакторе, но пользователи реально тупят когда в блогах один, в статьях другой и тд.