Что такое невезет — и как с этим бороться …
Этой статьей я возможно открываю новый цикл … внетемной направленности по отношению к основной сюжетной линии данного сайта, и ввиду этого (с целью «незахламления» основной тематики) буду писАть подобные статьи (если придется) в виде «записей» — выражаясь в терминах движка WordPress, собственно отчасти виновника материала этой статьи.
maslenizza.ru — не первый мой проект (но первый проект на движке WordPress), у меня на администрировании и другие творения, но либо полностью «самописные», любо на движке ModX. Не буду лишний раз рекламировать ModX, ибо в рекламе он не нуждается. Но почему же очередной проект поселился на новом (не обкатанном для меня) движке. До детального знакомства с WordPress’ом я наивно думал, что сей движок пусть и изначально менее универсален и в целом примитивнее ModX’а — но также в большей степени «допилен» и удобен для конечного администратора сайта, и требует от последнего меньше внимания (в плане организации работы самого движка), освобождая больше времени на написания контента. Я ошибался …
С одной стороны, казалось бы, к создателям движка по большей части нареканий много быть не должно — они ведь создали только базовый инструмент, канву — на которой можно не только творить (в плане контента), но и усовершенствовать ее (вплане расширения возможностей различными плагинами и хаками). Своего рода «квартира со свободной планировкой». Но как и в квартире с «голыми стенами» изначально жить невозможно, также нельзя и пользоваться «чистым» движком — и он с первых минут работы уже обрастает плагинами. Разумеется подобная тенденция хоть в целом и положительна, но зачастую не только увеличивает функционал движка, но и его нестабильность, глючность и т.п. Но в данной статье речь пойдет не об этом …
Неотъемлемой частью любого движка (его админ-панели) является встроенный WYSIWYG редактор контента, и наибольшую распространенность в качестве такового (встраиваемого «по-умолчанию») является скрипт TinyMCE. Он же и является основным виновником данной статьи.
TinyMCE производит потрясающее впечатление на пользователя с первого взгляда — практически MS Word в окне браузера! Как всегда — первое впечатление обманчиво, и недолюбливать я его стал еще со времен общения с ModX’ом. А напрягал он всегда в первую очередь своим стремлением «испохабить» html-контент (упорядочить его по своему усмотрению). Также не радовала и общая скудность визуальных инструментов не позволяющая изящно реализовать задуманное не прибегая к прямому редактированию html-кода. И треть — совокупность первого и второго: напишешь кусочек своего кода, а редактор его тут же исказит по-своему. Так вот после этого всего плюнешь на все визуальность и пойдешь писАть странички в DreamWeaver’е… Но в купе с ModX’ом таких плясок было не много и не часто (или привык уже их обходить) — короче не напрягало. C WordPress’ом же все началось с новой силой: поначалу возился с «тини» и пытался выжимать соки из него, потом поняв бесполезность затеи, а также бесполезность попыток импортировать документы из MS Word — пересел на любимый DreamWeaver, который куда как лучше справляется и с импортом вордовских документов в том числе. Но вот, например, встает задача — отредактировать (чуток дополнить или исправить) документ, вымученный альтернативными путями и вставленный в виде html-кода средствами движка (не прибегая к неадекватному «тини»). И что — тащить его обратно? — ведь один клик на страничку «визуального редактора» и усердием «тини» львиная доля форматирования летит к чертям!
Как пример подобной (архи-абсурдной) ситуации: (в «тини») выделяем часть текста параграфа, задаем ей начертание к.л. шрифтом; переключаемся в режим кода — видим что появилась конструкция из тега span и атрибута style внутри него — замечательно; переключаемся обратно в «тини»; указанное начертание уже пропало — куда?; возвращаемся в режим кода — видим, что тег и атрибут остался, а вот содержимое его пустО! Незадача — правда?
Нужно было разбираться в ситуации — ибо отказываться полностью от TinyMCE как визуального редактора не хотелось. На все про все был потрачен не один час, пересмотрены и прочитаны разные материалы официального и иного характера ;-) В итоге можно сказать, что «камней в огород» досталась бы прилично как разработчикам TinyMCE, так и разработчикам WordPress‘а. И так …
Казалось бы — причем тут WordPress? — подумав так я начал копать глубже в сторону «тини», пупутно рукая разработчиков за кривые руки, голову и пр. На самом деле ситуация в конце-концов вышла несколько по другому. Действительно и к моему сожалению разработчик «тини» практически совсем не уделяет внимание русскоязычной поддержке своего творения (в плане документирования) — кратенькие советы на разных форумах и блоках носят характер неких «шаманских танцев» и в целом картины не проясняют, хотя и заставляют понять, что без подробной документации разработчика тут и черт голову свернет. Не без помощи гугла обращаюсь к ней. Надо сказать что официальная вики разработчика TinyMCE также не дает исчерпывающей информации об юзании сего творения, но тем не менее базовые принципы, функциональность и общую концепцию оттуда вынести можно ;-) Возможности по настройке TinyMCE весьма широки и разнообразны и примеру идущие в дистрибутиве это только «примеры». Но как эту «гибкость» заюзать нам? — ведь мы не встраиваем «тини» в свой движок — мы уже юзаем готовый WordPress?
И вот тут мы погружаемся в изучение недр вордпресса… Слюновыделение усиливается, рука тянется за очередным камнем… О чем думали разработчики вордпреса? — но явно не о том, о чем были должны! TinyMCE внедрен в WordPress с некоторым набором параметром (почему именно таких, для меня осталось загадкой) — причем администратору не оставлено никаких средств (в плане админ-панели) для манипулирования этими параметрами. Я уже не говорю о том, «тини» встроен в вордпресс в сильно кастрированном виде (в плане стандартных плагинов). И до кучи — свежая версии WordPress 3.0 (от июня 2010) имеет в себе старенькую версию TinyMCE — 3.2.7 (сентябрь 2009), в то время как за прошедшее время «тини» неоднократно апгредился (в настоящее время доступна версия 3.3.8). Видимо разработчики «тини» стремятся улучшать свой продукт, что не скажешь о разработчиках «вордпресса» — выпустить «трешку» и не обновить редактор?! С вордпрессом 2.9.2 детально знакомлюсь я чуть более месяца — обновившись до 3.0 отличий не увидел никаких!
В отсутствии материалов в сети, решил сам обновить TinyMCE в составе WordPress’а до последней на текущий момент версии — о чем и распишу подробнее.
Как я уже упоминал «тини» в составе вордпресса присутствует в весьма кастрированном виде, уменьшить кастрированность призваны некоторые плагины к вордпрессу, содержащие в себе недостающие плагины к «тини» — одним из таких является tinymce-advanced (его мы тоже возьмем на вооружение).
Сам TinyMCE располагается в папке /wp-includes/js/tinymce а вызывается он из скрипта /wp-admin/includes/post.php — в котором и задаются параметры инициализации редактора. Помимо этого упомянутый выше плагин tinymce-advanced хранится в /wp-content/plugins/tinymce-advanced — его содержимое мы тоже должны обновить (в случае его использования — а он явно не лишний).
Как и в иных подобных случаях обновление я проводил «по аналогии» — была скачана новая версия «тини» с русским языковым пакетом и обновленными файлами производилась замена (на оффлайн версии базовой) — попутно требовалось реструктурировать языковые файлы ибо их структура в вордпрессе иная, чем изначально у «тини». Проапгрежен был и плагин tinymce-advanced, а также создан упакованный вариант редактора с базовыми плагинами wp-tinymce.js.gz (чисто задумка разработчиков вордпресса). Были добавлены на мое усмотрение полезные параметры в строку инициализации редактора — файл /wp-admin/includes/post.php (подробнее о которых читаем здесь).
В итоге имеем вцелом положительный результат — от большинства глюков удалось избавиться, хотя и непонятки остались. Например почему всегда используется «упакованная» версии «тини» wp-tinymce.js.gz — и параметр ‘compress’ => ‘false’ на это не влияет. Также чисто гипотетически смущает, то что некоторые из скриптов по сопряжению «тини» и вордпресса я позаимствовал без изменений (возможно оно и нормально, но все же). В общем желающие могут установить и ознакомиться с обновленной версией TinyMCE в рамках WordPress’а, не забыв предварительно сделать резервные копии, а об результатах отписать мне ;-))
- Резервируем содержимое папки /wp-includes/js/tinymce полностью, удаляем и заменяем содержимым архива.
- Резервируем содержимое папки /wp-content/plugins/tinymce-advanced/ полностью, удаляем и заменяем содержимым архива.
- Резервируем /wp-admin/includes/post.php — в районе 1470-ой строки редактируем или добавляем параметры (для примера мой модифицированный файл post.php) — о возможных параметрах читаем здесь.
Вордпресс не просто пи*дец — а ПИ*ДЕЦЦ с большой буквы … Никогда бы не подумал, что для того чтоб исправить мелкие неточности по тексту уже написанной ранее статьи, дабы не испортить ее структуру (а я хорошо помню как при ее создании и редактировании я уже знал какие места коцаются в оформлении при повторном открытии и правил их … сейчас понятно я об них забыл) — так вот, что называется «от греха подальше», проще залезть в phpmyadmin и напрямую подправить контент в базе данных !!!
Дожили !!! Средство управления базой данных — лучший инструмент администрирования сайта !!!
$%^&* разработчики вордпресса !!! Создали практически наркотик — посадил сайт на движок, и админить гемормо, и слезать уже тоже лениво ибо не менее трудозатратно …
Как дополнение …
При переходе двига (WP) на версию 3.0.1 — тини опять откидывается на допотопную версию 3.2.7 (на предмет чего я вновь шестнадцати-этажно высказываюсь в адрес горе-разработчиков) — опять применяю фиксы уже по проторенному пути, то что описано в этой статье, детально тестирую … и все равно — полного удовлетворения нет. Нужно видимо более детально изучать параметры инита и крутить ими (как вариант) или …
Ну почему нельзя сразу раз и навсегда «приручить» тини, как это удалось например сделать разработчикам двига ModX.