- Сложен в изучении
- Высокая нагрузка на БД
- Безграмотная структура
- Отсутствие ООП
- Странный кэш
- Несовместимость модулей
- Трудоёмкая кастомизация
Предыстория
Прошло три месяца с того момента, как я начал изучать Drupal. В процессе изучения я прочитал книги «Building Powerful and Robust Applications with Drupal 6», «Learning Drupal 6 module development» и «Pro Drupal Development. 2nd Edition», также во время пользования часто приходилось обращаться к документации Drupal'а и его API. Где-то в конце сентября я прочитал лекцию «Drupal» на веб-семинаре в родном университете, где рассказал о том, что такое Drupal, что он может и что я уже научился в нём делать.
Во-многих источниках я натыкался на фразы и диаграммы, суть которых сводилась к тому, что вот ещё чуть-чуть и Drupal станет ну просто идеальным средством для разработки… Не дождался, задолбало!
Базовые проблемы
Уже когда я читал доклад на семинаре, я выделил пару проблем Drupal'а, о которых пишут и говорят многие, это: сложность изучения и высокая нагрузка на базу данных. На моём докладе присутствовал человек, который уже успел до этого с ним повозиться около года и невзлюбить очень сильно. Он сказал, что нагрузка на базу данных чуть ли не самый худший параметр Drupal'а, в котором он проигрывает практически всем. А все красивые числа о большом количестве пользователей преувеличены, реально же Drupal может держать не более 1000 посетителей в день. На моё замечание по поводу drupal.org он лишь посмеялся, сказав, что в drupal.org уже столько патчей напичкано, что от drupal'а в нём только название то и осталось.
Но мне предстояло закончить проект на Drupal'е и поэтому пришлось продолжить трепыхания. По мере углубления я стал замечать, что проблем в Drupal'е гораздо больше, чем мне казалось тогда, когда я делал доклад. Первой и самой порой выводящей из колеи стал Drupal'овский кэш. Я так и не понял как он работает. К примеру, я изменяю функцию в модуле, и она может выполниться, а может и не выполниться. Это всё при том, что все доступные из админского интерфейса настройки кэша были выключены. Ещё хуже ситуация обстоит с добавлением и удалением функций в модуль. Если при добавлении ещё иногда достаточно просто обновить «любимый» кэш, то вот при удалении какой-нибудь функции порой выскакивает fatal error. Лечить его получается далеко не всегда, а зачастую приходится уже ручками удалять все данные кэша из базы данных.
Забегая вперёд скажу, что в Симфони, который я сейчас изучаю, этой проблемы не существует. В нём есть Environment'ы (по-русски наверное это будет «окружения», но возможно официально переводится не так, поправьте, если что!), грубо говоря каждое окружение — это определённая конфигурация сайта. По-умолчанию, имеются окружения dev и prod (есть ещё и test, если что) соответственно development и production (т.е окружения для разработки и при релизе). В dev'е почти все кэширования отключены, и не нужно лишний раз рвать на себе волосы, пытаясь угадать что произошло: синтаксическая ошибка или кэш не обновился.
Отступление, имеющее место: Вообще, наверное, ни сказанное выше, ни сказанное ниже не может быть единственно верной истиной. Негатив с Drupal'ом в моём случае связан ещё и с некоторыми сопутствовавшими его изучению факторами: я стал изучать Drupal 6, по которому в настоящий момент написано мало книг, а часть документации пишется исходя из того, что ты уже знаком с Drupal 5; я не доизучал книги до конца, т.к. внезапно навалился проект, и стало не до углубленного ковыряния.
Вторая проблема Drupal'а — это кастомизация шаблонов. Мне она представлялась такой: даётся набор переменных, которые нужно вставить в соответствующие места в вёрстке. Но это оказалось не совсем так. Во-первых, каждый модуль Drupal'а умеет и отдаёт свой html код, который зачастую меня не устраивает. Несмотря на то, что в Drupal'е есть так называемые функции темизации (т.е возможности перегрузки стандартного вывода), не всегда так просто докопаться до них, потому что во-вторых, иногда к моменту запуска конечной функции (т.е функции, которая отдаёт содержимое) часть html'а уже сидит в переменных. Ну и в-третьих, где это видано, чтобы html отдавался из функции? В итоге получается абсолютно нечитабельный код.
Отдельное слово стоит сказать о модулях в Drupal. У стандартного модуля структура такая:
- module_name.info (тут хранится инфа о модуле)
- module_name.install (тут хранится инфа как ставить модуль)
- module_name.module (тут хранится код модуля; ВЕСЬ!)
Размер файла module_name.module колеблется в диапазоне от 1 до 109 (в моём случае) килобайт. В случае самого страшного и огромного файла это 3000 строчек кода. Возможно ли читать и/или управлять таким кодом? И такая структура принята стандартом для данной CMF'ки.
Копнём глубже
Это лишь начало тех проблем, которые подстерегали меня на пути работы с Drupal'ом. Следующей проблемой стала несовместимость модулей. Понятно, что ожидать совместимости от модулей, которые написаны пионерами и нерекомендованы сообществом не стоит. Но я ставил вполне отработавшие и зарекомендовавшие себя модули:
- Devel — набор полезностей для разработчиков (Devel от Development), в частности внедряет в менюшку кнопку очистки кэша (см. выше зачем это нужно)
- FCKeditor — WYSIWYG редактор
- TinyMCE — ещё один WYSIWYG редактор, зачем мне их два читайте ниже
- Localization Client — удобный Ajax-клиент для локализации интерфейса, т.к нормального перевода на русский у Drupal'а нет
- Ubercart — интернет-магазин
Первая несовместимость выявилась между FCKeditor и Localization Client. Если на странице было две и более textarea, в которые нужно вставить редактор, то страница начинала капризничать и отказывалась сохраняться. Ну хорошо, поставил TinyMCE, но при всей моей любви к этому редактору я так и не смог заставить его работать в части администрирования сайта. Потому что настраивается он не так как FCKeditor. Для того чтобы включить TinyMCE нужно указать путь страницы, на которой редактор будет виден. А FCKeditor настраивается по id'шникам textarea. В итоге в одной части у меня FCK, а в другой TinyMCE. К сожалению TinyMCE пришлось ещё и оставить потому, что модуль для вставки картинок, который умеет их ресайзить (Imagepicker) работает только с ним.
Devel, который все очень любят, также в последствии вывалил наружу ещё и несовместимость с Ubercart, убивая весь проект на странице категорий каталога Интернет-магазина.
Drupal не для разработчиков
Окончательно уйти от использования Drupal я решил познакомившись с Symfony. Будучи разработчиком, который любит творить, в Drupal'е большую часть времени я пытался закрутить болты велосипеда, чтобы у него крутилось третье колесо, а цепочка была из платины. Также мне очень не нравится, что несмотря на то, что версия 6 была выпущена в этом году в ней даже не пахнет ООП. Разработчики объясняют это очень просто, буквально говоря следующее:
«Да, в Drupal'е нет ООП, но многие его принципы были реализованы нами, и в принципе вы будете себя свободно чувствовать». Но разница всё-таки сильно ощутима. Иначе зачем нужно было бы пользоваться калькулятором, ведь счёты давно уже изобретены!
Но не всё так плохо
Практика показывает, что у медали две стороны. Если бы всё было так плохо, то никто бы такой плохой штукой как Drupal и не пользовался бы, а ведь пользуются. Drupal неплохо подходит для тех, кому нужно очень быстро развернуть мощный ресурс, типа Хабры (смотрите пример Швабрашвабра) в кратчайшие сроки, при этом не сильно заморачиваясь с кастомизацией и своими фичами. Но нужно быть готовым, что выходя за границы функций используемых модулей вы столкнётесь с проблемами, часть из которых я описал выше.
Эта статья является личным мнением автора по поводу CMF Drupal, а также подытоживанием опыта работы с ним. Не пинайте, если кого обидел
upd: Спасибо за плюсик в карму, чуть-чуть не хватало чтобы в блог Drupal перенести
upd2: Я обнаружил, что несколько соврал в фразе Первая несовместимость выявилась между FCKeditor и Devel, там не Devel, а Localization Client. Прошу прощения!
