all07

Всего понемногу ...

Вселенский опыт говорит, что погибают царства не оттого, что тяжек быт или страшны мытарства.
А погибают оттого (и тем больней, чем дольше), что люди царства своего не уважают больше. (Булат Окуджава)

Те, кто готовы пожертвовать насущной свободой в обмен на то, чтобы получить временную безопасность, — недостойны ни свободы ни безопасности. (Бенджамин Франклин)

Война — это мир! Свобода — это рабство! Незнание — сила! (Джордж Оруэлл)

Реконструкция сайта - новый "движок". Прощай Wordpress?

 WordPress и фреймворки

С чего бы начать? Начну, пожалуй так: Товарищи! Рабочая и крестьянская революция, о необходимости которой все время говорили большевики, совершилась. Теперь мой сайт работает не на вордпрессовском "движке", на смену ему пришла написанная "с нуля" моя собственная логика. Чем же был вызван подобный шаг, и вообще, была ли в этом необходимость? Чем плох для меня "коробочный WordPress"? В общем, особенно ни чем, а по мелочам - многим. Больше всего меня напрягала, так сказать, его неспешность, размеренность и неповоротливость, вызванная его универсальностью, и чувство "черного ящика" с непонятными процессами внутри. Непонятная концепция плагинов, вплоть до того, что "коробочная" версия без "обвеса" в виде доброго десятка плагинов фактически не годиться для нормальной работы сайта - уж слишком много необходимых функций ей не хватает. К примеру, что стоило уважаемым разработчикам добавить каптчу и генерацию файла sitemap.xml, систему нормального (релевантного) поиска по сайту, черные листы при аутентификации, логи производимых пользователями действий - все было отдано на милость разработчиков плагинов. Что сказать, если даже какую-то несчастную пагинацию приходится "подкручивать".

И вообще, плагины WordPress - отдельная "грустная песня", чем их больше, тем неспешнее работает Ваш сайт, да еще нет никакой уверенности, в том - выполняет ли установленный плагин только то, что заявлено в его описании или под тихую делает еще что-нибудь в своих корыстных интересах. Тоже самое можно сказать про темы. Конечно, все можно проверить, но порой ковырять чужой код сложнее, чем написать по мере возможностей свой собственный (а уж затем ковырять его). Главное - мне в корне не нравится сама идея сложившегося быдло-подхода: по любому "пуку" - ставь плагин, и не важно насколько мелкую и не существенную функцию Вам надо добавить или убрать. Не понятно, как выяснить степень компетенции программера, который писал тот или иной плагин. Действительно: а что, собственно, заморачиваться - это же работает и не важно, что плагин делает сотню запросов к базе данных в цикле, в результате чего время формирования страницы "не известно по каким причинам" возрастет до трех секунд и жрутся процессорные ресурсы и память. Ах! Так вы еще не установили пару-тройку кэширующих плагинов? Да вы, батенька, совсем не умеете работать с WP! У Вас всего десять плагинов? Да Вы что?! Только при установке не менее пятидесяти он приобретает более менее приемлемую функциональность. Бездумно устанавливать кучу сомнительных плагинов - это явно не мой путь.

Тогда спрашивается - что мешает сделать свои плагины и шаблоны? Что бы (качественно) написать свой плагин или шаблон необходимо достаточно хорошо знать API ядра (требует времени для изучения). Несмотря на то, что его функции хорошо задокументированы, иногда приходиться малость помучиться изучая их, вплоть до того, что порой появлялись нехорошие мысли о том, что уж проще написать свое, чем раскапывать эти залежи. Наиболее часто подобные мысли у меня возникали во время "возни" с проблемами, возникшими при адаптации части, отвечающей за XML-PRC, к моим потребностям. (Частично эти проблемы были освещены в статье про реализацию примера, использующего XML-RPC и про передачу параметра времени.) Приходилось терять много времени, внося изменения в библиотеки, что бы "это хоть как-то работало". А потом заново изучать все изменения при выходе очередного обновления на предмет возможности пропатчить новую версию своими правками без ущерба для работоспособности. Хорошо, если изменения затрагивают только пару методов в одином файле, а что делать если у Вас несколько таких фалов? Писать свой вариант заменяющий ту или иную системную функцию? Это грозит несовместимостью, что в дальнейшем чревато еще большими проблемами. Да и настолько глубоко залазить не особо хочется, ненароком можно увязнуть.

Еще одна, не понравившаяся вешь, (в особенности на фоне отсутствия действительно востребованных функций) излишняя перегруженность не нужными для меня сущностями. Одна из которых - черезмерно "умный" (просто "заумный") редактор исправляющий написанный код по собственному "разумению" и выделяющий продукты жизнедеятельности в виде десятков (а то и сотней) копий редактируемого документа, (о чем узнаешь через пол года, когда в базе появляется несколько тысяч не нужных записей, удалить которые можно только SQL запросом или... установкой очередного плагина). Редактором невозможно пользоваться в "визуальном" (WYSIWYG) режиме, от использования которого я отказался после десятого криво оформленного поста, содержащего ужасный код кишащий тегами <span> в сочетании с атрибутами style. Наверное хуже его выдает разметку разве только MS Word, если рискнуть сохранить из него документ в HTML формате.

Дальше - больше. Не удобная медиа библиотека, котрая годится максимум для пары сотен картинок, и начинающая раздражать при наличии нескольких тысяч. Если не задашь правильное название, то считай, что картинка безвозвратно похоронена в недрах медиотеки. Не логичнее было бы добавлять картинки не по безликим папкам с названиями по годам и месяцам, а в папках с названием поста в который они были вставлены? Ведь картинки в любом случае привязаны к какой либо странице или посту (даже если они условно объединены в некую галерею) и бессмысленно их хранить сами по себе. Зачем для каждой картинки создавать набор миниатюр? Не понятно, для чего нужен органайзер ссылок, под который зачем-то отвели отдельную таблицу. Уж лучше бы сделать собственную таблицу под менюшки, картинки и копии постов, а не засорять этим дерьмом основную таблицу posts.

Самое интересное, как всегда выходит, все неудобства "вылазят" по мере работы с WP. Конечно, много проблем можно решить написав "заглушки", поместив их в файл function.php своей темы, остальное дописать в виде плагинов, но опять - это время потраченное зря потому что оно уходит не на создание чего-либо нового, а сугубо для борьбы с "навязанными фитчами", на "правку багов" или на поиск оптимального способа "прикручивания" необходимого функционала с использованием предоставленного API. Данная деятельность не конструктивна по своей природе, ибо она позволяет приобрести знания лишь по отдельно взятому API, (какие функции, с какими параметрами и где нужно вызвать, и какой результат они возвратят) за которым не видна вся картина внутренней работы сайта.

Резюмировав все вышеизложенное, я пришел к мысли: а не будет ли более правильным решением для моего случая написать свой собственный "движок" сайта со своей логикой работы, обладающий только необходимым мне функционалом? Кроме того совместить приятное с полезным, побочно изучив какой-нибудь фреймворк. Сказано - сделано. Хочу представить на всеобщее обозрение, то что у меня вышло. Ведь критиковать чужое намного проще, чем сделать свое, по качеству (по крайней мере) не уступающее тому, что было.

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

Еще нет комментариев к «Реконструкция сайта - новый "движок". Прощай Wordpress?»

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Captcha Обновить картинку Каптчи

Пожалуйста, введите символы,
показанные внутри треугольников