Drupal наше все!

По необходимости пришлось столкнуться с MODx, которого я раньше совсем-совсем не видел. Самую чуточку — сменить шаблоны на одном сайте. Первые впечатления — ужас-ужас. И эти люди запрещают мне ковыряться в носу говорят, что Друпал сложен для изучения! Я как открыл страницу управления элементами, да как увидел, что там в шаблоны могут вставляться и какие-то «Параметры», и «Чанки», и «Сниппеты», а потом еще и прочитал подсказку наверху, что, дескать, «Чанки — это куски (X)HTML-кода, используемые в неизменном виде в нескольких местах. Чтобы иметь возможность централизованно редактировать повторяющийся код, вынесите его в чанк. Чанки не могут прямо содержать исполняемый код, однако могут включать в себя вызовы сниппетов и/или параметров (TV), обеспечивающих динамическую логику.» (первый вопрос — а какого, собственно, нужны вообще эти чанки в качестве прослойки между сниппетами и шаблоном?), то совсем в осадок выпал… И желание изучать этот MODx пропало сразу… В общем, скорее всего, знатному MODx’еру будет смешно читать такое брюзжание, но факт есть факт — в свое время первый взгляд на Друпал не вызвал у меня такого непонимания и неприятия. А значит, я сделал правильный выбор. 🙂

Сеятель РДВ

Всегда у меня так — очень хочется взять все готовое, взболтать не смешивая и продать клиенту «за дорого». Чтобы как у всех и без проблем. Но подводит, судя по всему, генетический перфекционизм — обязательно стоит сделать шаг в сторону от очередного «Best practice guide», как натыкаюсь на какие-нибудь очередные грабли, с которыми мужественно начинаю бороться… В последнее время такими граблями становится Drupal и все что с ним связано. С одной стороны — супер-расширяемая (за счет чего — тяжеловесная) и гибкая система, которая должна обеспечивать спасение котят целыми прайдами.

С другой — вся эта гибкость обеспечивается как раз только в ядре, над каждым элементом которого думают месяцами и годами, а в модулях — в которых и состоит вся сила Друпала — предполагается зачастую один единственный сценарий работы, а чуть стоит от него отойти хотя бы на шаг (даже на полшага), то оказывается что либо это совсем невозможно, либо глючит все не по-детски. Причем это касается не только мелких и «самопальных», но и таких «столпов» друпаловского сайтостроительства, как приснопамятный Views. Кто хакал Views, тот меня поймет… По написанию для него хендлеров и т.п. и то толковой документации за столько лет не родили… А потом еще, значится, кто-то рассказывает, как сильно ООП упрощает жизнь… Тьфу.

В общем, у меня почти каждая серьезная работа с Друпалом выливается в суровое ковыряние внутренностей то Views, то вот теперь Feeds, то каких-нибудь субмодулей CCK с целью исправления багов и обеспечения их нормальной работы c последующим отправлением закрывающих эти баги патчей. За предыдущие сутки — штук пять чужих багов закрыл. Больше всего мозг взорвали, конечно же, те же Views — не зря же про них вспомнил… Но была и адаптация одного JavaScript’а под Оперу, и верстки одного упрямого разработчика («Я не буду поддерживать браузер 10-летней давности!») под IE6.

Но самое главное, что я не понимаю логики тех, кто отписывается о багах, но не выкладывает патчи. Человек что, сдает заказчику работу с косяками? Или тупо забивает и не делает этот функционал? Это как вообще? Вот я представляю — звоню я завтра своему заказчику и объясняю, что вот такой-то блок новостей по федеральным округам мы выводим не сможем, потому что соответствующий субмодуль Views глючит и выкидывает ошибки SQL, я оставил репорт с багтрекере, но когда разработчик среагирует — неизвестно… Заказчик после этого пошлет меня на хер и будет совершенно прав — свои деньги он платит за результат, а не за то, чтобы я в багтрекер чей-то писал. А народ именно так и делает, а потом еще через полгода спрашивает — ну как, мол, ситуация там — исправили ошибку или нет? Что они эти полгода делали? И неужели им эта проблема еще актуальна? И вот я выкладываю патч для исправления косяка, который тянется с 2009 года (!!!), они его применяют и что говорят заказчику? «Наконец выложили патч по багрепорту, который я оставлял 2 года назад!» Бррр… Наверное, еще и деньги за свою работу просят.

Короче, в шоке я от основной массы девелоперов. Или я уже слишком стар, а они не девелоперы, а просто эникейщики, которые вышли на новый уровень? Раньше эникейщик устанавливал софт через виндовый Wizard и был крут по сравнению с пользователем. А теперь эникейщик делает сайты и тоже крут.

В такой ситуации остается только одно — учиться, учиться и еще раз учиться. Без перерыва. Тренировать мозг. Чтобы никогда в жизни не стать таким «разработчиком». Разработчик — который вместо кода и патчей генерирует багрепорты — уже не может считаться таковым. По-моему так.

Корректные «чистые» URL на nginx для Drupal

Запишу, чтобы самому же не забыть в следующий раз. Почти все конфиги для поддержки «чистых» URL в nginx для адекватной работы Drupal — неправильные. Точнее, в некоторых старых этот момент учтен (которые через «if (!-e $request_filename)» и т.п. сделаны), а в новых — красивых и цивильных — нет. В частности — в том, который в FAQ самого nginx дается. Корень зла в том, что Друпалу в запросе передается URI целиком вместе с первым слэшем, а это — неправильно. Т.е. надо передавать не q=/node/1, а q=node/1. Самое печальное, что в .htaccess по умолчанию, который идет в комплекте, правила тоже неправильные: «RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]» вместо «RewriteRule ^/(.*)$ index.php?q=$1 [L,QSA]». При этом все работает нормально, а косяки вылезают, например, при создании мультиязычного сайта — на всех языках, кроме default ничего не открывается — page not found.

Соответственно, достаточно вставить маленький rewrite в location @drupal в описании сервера для nginx’а:

rewrite        ^/(.*)$          $1  break;
fastcgi_param  QUERY_STRING     q=$uri&$args;

И все тут же становится хорошо…