Вы про что?…Не вижу смысла тратить силы на "фильтр" или плагин
• Mike •
Ищущий всегда найдет… что поискать… ))
+912
Репутация
3834
Рейтинг
не получиться, обработка происходит до обработки тега хайд, можно исправить только регулярку по замене, я пока тестирую в редакторе переделанном из стандартного, как выложу в блоги можно будет протестировать работу…наверное в форме надо прикрутить 1 символ в конце конструкции /hide
“если вставить ссылку в скрытый тескт, то для зарегистрированных пользователей получается вид testutf.ru/users/tolik[/hide”
если вставляете текстом добавьте в конце пробел иначе функция autolink сжирает закрывающий тег /hide или используйте кнопку вставки ссылки
например:
это ссылка с пробелом в конце…
если вставляете текстом добавьте в конце пробел иначе функция autolink сжирает закрывающий тег /hide или используйте кнопку вставки ссылки
например:
Группе, к которой вы принадлежите, запрещено просматривать этот скрытый текст
это ссылка с пробелом в конце…
ага, только можно сократить текст в спане в файлике block_rep.js
тогда при нескольких кнопках получается как анимация…
тогда при нескольких кнопках получается как анимация…
бранчи сведены в 1034, пока новых не было…
не спешить с чем — с изменениями или с исправлениями?
не спешить с чем — с изменениями или с исправлениями?
(1042)…
спасибо, завтра поправлю в бранче…
))) да я бы их вообще не трогал…, может кому-то и такой вариант нужен…
Это один из потоков…) параллельный, но не единственный…Только вот движение странное, в сторону редакторов, которые не дотягивают до уровня того что уже есть.
Схема простая — разберись с тем что уже существует и сделано до тебя и сделай свое и по-своему учитывая полученный опыт…
Скоро выложу в блоге очередную версию, можно будет обсудить конкретику…
2. Например мульти-загрузчик для фото
3. Если не выносить, до них будет так же как и сейчас не просто “добраться”, т.е. придётся редактировать файлы ядра каждый раз при обновлениях и внесении изменений для сторонних компонентов
4. Например для фото у меня на данный момент предусмотрено 7 опций (необязательных, конечно), но вставляются они пока по старой схеме в коде ББ и парсер их учитывает, значит, придётся открывать все старые записи и добавлять всё в ручную
5. Учитывающий вложенность тегов их правильное применение по назначению, с присвоением классов для стилей
6. Её сейчас нет, а с “накруткой” функционала необходимость появляется
9. Ага правим библиотеку вместо допустим стиля
Так как каждый хочет своё, единственный путь — разнообразие настроек и удобное добавление своих функций, например по некому шаблону в админке
В общем “голые” идеи обсуждать сложно, гораздо проще “пощупать в живую” и смотреть в том направлении двигаешься или нет…
3. Если не выносить, до них будет так же как и сейчас не просто “добраться”, т.е. придётся редактировать файлы ядра каждый раз при обновлениях и внесении изменений для сторонних компонентов
4. Например для фото у меня на данный момент предусмотрено 7 опций (необязательных, конечно), но вставляются они пока по старой схеме в коде ББ и парсер их учитывает, значит, придётся открывать все старые записи и добавлять всё в ручную
5. Учитывающий вложенность тегов их правильное применение по назначению, с присвоением классов для стилей
6. Её сейчас нет, а с “накруткой” функционала необходимость появляется
9. Ага правим библиотеку вместо допустим стиля
Так как каждый хочет своё, единственный путь — разнообразие настроек и удобное добавление своих функций, например по некому шаблону в админке
В общем “голые” идеи обсуждать сложно, гораздо проще “пощупать в живую” и смотреть в том направлении двигаешься или нет…
Посмотрите как реализовано в бранче priorqwerty для версии 1.9.1 UTF-8… (багтрекер) там компонент подарков уже встроен
Я объясню, свою позицию (естественно по собственным впечатлениям и предпочтениям):
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. Новый функционал для редактора добавляется как и сейчас через плагины;
Ну и остаются парочка вопросов: делать его “реалтайм превью” или “по кнопке” и что при этом использовать вставку ББ-кодов или сразу теги html…
Перечисленным выше условиям ни один из “сторонних” редакторов не соответствует, а “прикручиваю” я их не для разнообразия выбора, а для тестирования функционала и возможностей и удобства его расширения, ну и плюс смотрю что они дают на “выход”…