Эта публикация является ответом на пост «Недостатки WordPress — техническая сторона».
По традиции автора, уточню несколько моментов:
- Дабы внести ясность, сразу скажу, что я тоже намерен рассматривать статью с технической стороны, но через призму всех разработчиков, а не только опытных;
- Мне доводилось иметь дело со многими CMS, в том числе и ezpublish, который написан, практически весь, со строгим использованием ООП. В своё время плотно использовал Drupal;
- Большую часть времени я программирую с помощью сторонних фреймворков и осведомлён, каким должен быть хороший движок;
- Ни в коем случае, не считаю себя гуру PHP, просто знаю, что настоящие гуру возможно обойдут тему WordPress стороной.
Я нигде не встречал более простых и элегантных реализаций функционала, чем в WordPress. Я отнюдь не считаю, что во всех проектах должна использоваться эта CMS, но, на мой взгляд, WordPress хорошо справляется с возложенными на него задачами и отнюдь не без использования ООП. Вся фишка в том, что ООП использовать никто не запрещал. Многие плагины написаны как раз с его использованием.
Но всё же, стоит провести черту, в каких случаях стоит использовать WordPress.
Я лично выделил для себя следующие пункты:
— Сайт должен быть информативным, без сложных запросов для которых может понадобится ORM или ActiveRecord. Т.е. для АПИ, статистики — я бы не советовал использовать CMS;
— Админка должна быть принята, как должное и другую панель управления никто не потребует;
— Предполагается, что WordPress покроет большую часть функционала, а меньшую надо будет дописать(плагины, темы);
— Проект большой и громкий. Использование WordPress в таком случае будет только на руку как разработчикам CMS в качестве рекламы, так и разработчикам проекта (частые обновления, низкий порог вхождения, готовое решение из коробки).
В остальных случаях я всецело за использование своих или чужих фреймворков.
Далее автор приводит примеры.
«Глобальные переменные это так классно, не правда ли?»
Да, есть определенные сложности с поиском ошибок в разных частях проекта. Однако что может быть проще, чем использование глобальных переменных? Необходимость прохода переменной через разные функции может затруднить понимание новичка о том, что происходит внутри кода, точно так же, как и непонимание, откуда берутся эти переменные. В нашем же случае они общеизвестны, так как отписаны в заранее отведенном месте и представлены как должное.
«А пригодился бы разработчику слой абстракции базы данных?»
Хочу отметить, что в этом тоже есть свой плюс. Привыкшие к MVC могут ненароком перекреститься, увидев в шаблонах код, отвечающий за построение запросов к базе.
Не будем считать тех, кто действительно злоупотребляет логикой для входных параметров при построении этого самого запроса (тут я соглашусь, что лучше это выносить всё в виде функций в файл functions.php). Однако всё же я не считаю это чем-то сверхъестественным. Наоборот, удобен случай, когда в темплейте team можно сделать запрос, указав post_type team.
Кому-то может показаться непривычным, что делая запрос он может повлиять на дальнейший вывод контекстной информации, но если понять, как этого избежать, то проблема сразу исчезает. Избежать можно, используя get_posts или wp_reset_query. Скажем, если совсем лень, можно использовать конструкцию вида:
$oldpost = $post;
// query_posts()
$post = $oldpost;
Я не рекомендую никому использовать вышеуказанный код, такой подход использовать в корне не верно.
Далее автор негодует, что все данные вписываются в одну общую схему таблиц. Первый раз столкнувшись с этим я пребывал в лёгком шоке. Мне не давала покоя мысль, как можно настолько аккуратно всё сделать, что для каждой новой сущности не придётся плодить таблиц. Более того, мы сохраняем за любым типом данных возможность вести историю изменений (ревизии), быть объединными между собой в качестве создания подборки похожих материалов (таксономия). Имеем расширенный доступ ко всем данным в одном месте.
«Маршрутизация с помощью mod_rewrite»
С этим пунктом я согласен. Этот момент разработчики не смогли упростить для новичков, без знаний регулярных выражений сложно использовать предопределение ссылок.
От себя добавлю, что во многом rewrite функции конфликтуют между собой. Например, ссылка таксономии может конфликтовать с существующей ссылкой кастомного контентого типа или страницы.
«Как насчет файловой архитектуры?»
Соглашусь, что в имеющемся виде файловая архитектура не шибко гибкая. Опять же, повторюсь, разработчикам не запрещено использовать свои собственные include и requre_once, разносить всё по классам в отдельных подпапках для большего DRY.
Все мысли о том, какой должна быть простая архитектура файлов, часто размывают границы понимания обычного новичка, или, скажем, дизайнера, которому нужно всего лишь подправить вёрстку. Правила именования шаблонов всё это структурируют.
По поводу использования less, sass. Мне прекрасно удавалось ими пользоваться, в том виде, как оно сейчас есть в WordPress.
Мне кажется, что автор в какой-то степени только недавно начал использовать автолодеры с неймспейсами, инкапсуляцию, наследование. При этом, списывая функциональный подход к программированию команды разработчиков WordPress на попытку написания достойной архитектуры. Хотя, на самом деле, низкий поклон ребятам, что они не ударились в PHP5 Only программирование и не заинкапсулировали всё внутри классов с неймспейсами.
Не спорю, что такой подход рано или поздно устареет, после выхода очередной супер простой CMS, с элементами ООП, но пока что всё предельно понятно даже, тем кто знаком с программированием понаслышке, а профи уж и подавно легко разобраться во всём, включая написание собственных плагинов, хуков, предопределением кастомных функций, не просиживая лишнюю тройку дней за сложной документацией.
Псевдо Cron задачи
Коротко отвечу, что тут я согласен с негодующим автором.
«Нарезка изображений»
Предполагается, что объявленные типы будут использоваться по назначению, в обратном случае напрашивается вопрос — зачем их было объявлять. Понятно, что автор подразумевает использование конкретных типов для конкретных изображений, но тут напрашивается уже другой вопрос — как можно быть уверенным, что использование этого изображения не понадобится в другом юз кейсе.
Нужно отдать должное разработчикам, что они не оставили это на волю судьбы какого-нибудь стороннего плагина, который генерирует картинки по мере необходимости(тот же пункт с псевдо-кроном)
Заключение
Можно долго философствовать на тему паттернов, алгоритмов, удобств… Погодите-ка, давайте учитывать, что WP создавался не для профи программеров, а для обычных людей, интересующихся как им создать свой блог. В таком ракурсе, пожалуй, WordPress справляется со своей задачей на все 99%.
Автор: sandrain
