название для официального сайта inFlowia Lab
  • помощь 4 free! :)
  • делаем добро :)
  • делаю сайты, скрипты и хорошее настроение :)
  • всё поправимо! :)
  • Свобода и OPENsource!
  • Linux - это любовь!
  • Linux - это Lюбовь
  • творим добро с 2019/03/22 :)

Это стоит знать прежде чем решать подключать WYSIWYG-редактор к сайту для редактирования страниц

Это динамическая статья. Время от времени она может пополнятся новым контентом, а старый может изменяться или исчезать.

Чтобы понять, появилось ли что-то новенькое взгляните на дату.
Первая дата - дата выхода первой версии статьи.
Вторая дата - дата последних изменений.
Правда, иногда, я забываю обновлять вторую дату... ':)
Чтобы было проще найти новое воспользуйтесь кнопками для подсветки свежих изменений. Заголовки новых добавленных глав, либо фрагменты текста целиком станут выделены в тексте вот таким образом[ NEW! ]. Так что вы сможете либо найти их глазами, либо, если текста много, можете воспользоваться поиском меток [ NEW! ] при помощи поиска по странице.
Если тема для вас очень важна и совсем не хочется пропустить обновления информации лучше будет подписаться на новости и обновления: в группе VK.


ВНИМАНИЕ!

Данная статья не дописана. Информация может быть неполной, неточной, неактуальной а так же содержать ошибки.

Хочу сразу предупредить...

Более менее плотно я пользовался только WYSIWYG-редактором Xinha. Ещё 2-3 я установил, попробовал и удалил, с десяток просто поюзал на официальных демо-странцах и ещё штук 20 просто посмотрел в кратком описании, так что мой опыт на самом деле достаточно скуден, тем не менее, мне есть что посоветовать полным новичкам.

Только HTML! Возможно вы не сможете редактировать PHP-страницы, JS и прочие вкусности.

Если брать опыт использования Xinha то с ним вы сможете редактировать только HTML-страницу. Если страница написана на PHP и имеет всякие классные штуки вроде подключения кусков текста из разных файлов, то адекватно отредактировать такую страницу не получится. Вернее вы сможете её загрузить, отредактировать, сохранить, однако после сохранения вас скорее всего ждёт шок, от того что вы получите на выходе. Весь PHP-код будет либо удалён, либо закомментирован. Скорее всего то же самое произойдёт и с JS, но я не проверял.

То есть нельзя просто взять PHP страницу целиком - запихнуть её текст в Xinha и ожидать что она за сервер исполнит весь PHP и подтянет все инклюды. Нет, она просто подтянет все понятные её сущности (а это HTML) а оcтальное либо удалит либо закомментит, так что если у вас модульные странички на PHP где шапка подтягивается из одного файла а футер из другого, вам нужно будет придумывать новую архитектуру для того чтобы можно было в редактор отдавать только контент и редактировать только его, причём никакого "сложносочинённого" контента с PHP-инклюдами по тексту.

Как это вижу я (и, должно быть, разработчики WordPress), идеальная архитектура для WYSIWYG-редактора - это когда контент хранится в БД и редактору скармливается только он, а основной каркас страницы существует отдельно и просто подгружает из бд текст нужного контента.

В принципе если по каким-то причинам сильно не хочется юзать БД, то контент можно хранить и в отдельных PHP-файлах - почему нет. Главное чтобы внутри не было PHP-кода. Я на данный момент использую в экспериментальном режиме такой подход для одной из страниц.

Я редактор я так вижу

Если вы планируете использовать комбинированный подход к редактированию страниц, то есть что-то в редакторе, а что-то просто блоконотом, то вас может слегка шокировать то что вытворяет WYSIWYG-редактор с исходным кодом. В таблицах, например, для задания параметров ячеек он не церемонясь применит их к каждой ячейке по отдельности, не заморачиваясь с созданием классов и прочими выкрутасами. Я думаю вы догадываетесь в какое нечитабельное и тяжеловесное месиво превратится исходник. При каждом неосторожном нажатии на Enter будет создаваться новый абзац (жмите Shift+Enter если он не нужен). Стиль табуляций будет скорее всего основан на пробелах... Если только они вообще будут. Мне попадались динозавры которые генерят код тупо в строку и их мало волнует то, как ты это потом будешь читать.

Ты любишь брать параметры и строки в одинарные кавычки а не в двойные? Ну ты наверное уже понял, что эта милая прихоть - сущая ерунда на фоне того огромного списка твоих код-привычек, которые твой будущий WYSIWYG-редактор собирается бесцеремонно попрать :)

Вообще некрасивое и непривычное оформление кода это далеко не самая главная вольность, которую себе позволяют такие редакторы. Куда хуже например то, что Xinha при переключении в режим кода за каким-то чёртом удаляет все символы переноса строки из тэга xmp. Зачем? Почему? - Не понятно. Понятно только одно, если редактируешь через Xinha то xmp теряет всякий смысл

WYSIWYG-редакторы не занимаются, сохранением, загрузкой и аутентификацией

По крайней мере те что мне попадались требовали засунуть редактируемый текст в какой-нибудь HTML-элемент и сказать по какому классу или IT-у этот элемент найти. ВСЁ - как ты будешь этот текст получать и куда сохранять дело твоё. Так же твоим делом является созданием системы авторизации для страницы с редактором, чтобы никто кроме тебя к нему доступа не имел.

Если нужно чтобы это было уже сделано за вас, вам нужна CMS.

Подсветка кода? А чё, нужно было?

Представьте себе, такая подразумеваемая, как нечто дефолтно нужное, вещь как подсветка синтаксиса отсутствовала ВО ВСЕХ что я видел WYSIWYG-редакторах. Не знаю чем вызвано такое волевое решение разработчиков. Возможно безбожно медленное переключение текст / код становилось апокалиптически медленным. Так или иначе, я даже намёков на подключение такой функции не наблюдал. Крайне странно.

Сохранение позиции в тексте и выделения при переключении текст / код

Да да. Не менее маст-хэв функция чем подсветка синтаксиса так же в большинстве редакторов не реализована. Увидел только в Xinha, но её нужно подключить как плагин, однако работает довольно плохо - после переключения на код сперва прокручивает страницу к выделению а потом немножко поднатужившись сбивает прокрутку на 1-2 строчки так что выделение уходит за нижнюю границу экрана. В других редакторах может тоже есть в формате плагинов, но так глубоко я их не копал.

С JS могут быть проблемы

Если вы используете какой-нибудь скрипт для автоподстановки например, то не факт, что он будет срабатывать для текста загруженного в редактор. Во первых, потому что редактор будет выводить всё скорее всего в iframe, а это значит что нужно использовать немного другие jQ-селекторы. Кроме того нужно будет отлавливать момент загрузки iframe, то есть на момент исполнения вашего скрипта, нужного контента может ещё просто не быть, так что скорее всего потребуется переработка таких скриптов, чтобы они работали и в редакторе в том числе.

Производительность может просесть

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

Для примера возьму свою любимую Xinha с несколькими плагинами,

используемую на машине:


    RAM: total: 3.82 GiB CPU: Topology: Quad Core model: AMD Athlon II X4 641 bits: 64 type: MCP L2 cache: 4096 KiB Speed: min/max: 800/2800 MHz Graphics: Device-1: NVIDIA GT218 [GeForce 210]

При редактировании таблицы размером в 300 КБ я уже не могу шустро переключаться между кодом и результатом, одно переключение занимает секунды 2-3 а это на самом деле не мало, спасает разве что как раз пресловутый функционал, котрый позволяет большую часть операций вроде назначения классов или оборачивания в тэги, отдавать на откуп визуальному редактору и не залезать в код. Однако же и с вызовом штатных функций визуального редактора не всё гладко. Контекстное меню всплывает с ощутимой задержкой, список классов откликается тоже далеко не мгновенно и всё в таком духе.

Кроме того не могу не упомянуть про начальную загрузку, которая у Xinha так же может занимать от 2 до 5 секунд.

А может Composer?

Браузер SeaMonkey имеет в своём арсенале легендарный редактор страниц Composer, который способен прямо не отходя от кассы дать отредактировать вашу страницу прямо с вашего сайта и для этого вам даже не придётся подключать никаких библиотек, он просто подключится по FTP и отгрузит нужную страницу туда куда вы скажете, и на базе этого функционала наверняка можно намутить весьма комфортный статический сайт, но опять же только на обычных HTML-страницах, никакого PHP. Чудес не бывает. Composer получает то, что ему отдаёт сервер, а сервер PHP код не отдаёт никому. Его он исполняет, чтобы на выход отдать готовую страницу, так что все ваши include, Composer конечно же не увидит, вместо них он получит содержимое подключаемых файлов и после редактирования и сохранения вы просто затрёте свою PHP-страничку готовой "литой" HTML-кой, которая будет вполне функциональна, но абсолютно статична, то есть если вы подключали шапку сайта из отдельного файла, чтобы удобно менять дизайн сразу для всех страниц, то после обработки Composer-ом такая шапка уже окажется намертво "пришита" к отредактированной странице, то есть тупо скопирована в неё и соответственно, после того как вы отредактируете файл шапки это никак не отразится на отредактированных Komposer'ом страницах.

Эх... А жаль :)

Помогло? :)

Черкани Инфловии пару строк если нашёл здесь помощь. Можешь писать под любым постом в группе VK или по старинке на почту: inFlowia@netc.it :)

inFlowia Lab. не делает добро за деньги, но знать, что её труды кому-то помогают очень классно. Если тебе помогли - не поленись, всего пара слов: "Спасибо! Помогло :)" сделают дни инфловии светлее. ^^

Количество откликнувшихся: 8