Советы по применению Drupal

Про него говорят: гибкий и сложный, безопасный и быстрый. Им многие восхищаются, но не все решаются применять в своих проектах. Да он такой, этот Drupal. Умеет многое, но чтобы получить максимальную отдачу от этой системы разработчику придется, как следует попотеть и разобраться в многочисленных тонкостях. Этот путь тернист и труден, но цель однозначно того стоит. Я начал применять Drupal в своем большом проекте не так давно, но уже успел набить несколько шишек и хочу уберечь от этого тебя. Заинтригован? Тогда, приготовься выслушать советы от уже не совсем начинающего Drupal’ера.

Главный минус Drupal

Одним из главных минусов Drupal’а всегда был отсутствие нормальной, структурированной документации. Нет, есть форумы, имеются официальные доки, но это все не то. Вся вкусная информация разбросана по закоулкам мировой паутины, и быстро найти ответ получается не всегда. Еще сложней разработчикам, незнающих язык Шекспира. В этой статье я постараюсь дать советы и примеры решения задач, с которыми я сам когда-то столкнулся. Уверен, что с подобными трудностями сталкиваются многие. Очень надеюсь, что после прочтения статьи, таких не счастливчиков станет меньше. Сразу оговорюсь, что в рамках журнальной статьи освятить все что хочется – нереально. Часть советов останется за кадром, но ты сможешь в любое время их почитать на сайте проекта VR-Online (полную ссылку на статью ищи во врезке).

Совет #1: Каждому проекту – свой Drupal

Drupal пригоден не только для строительства web-сайтов. На основе этого движка удобно разрабатывать различные web-приложения. Зачастую, подобные приложения разрабатываются для внутрикорпоративных нужд. К таким проектам предъявляются совсем другие требования, и типичной сборки Drupal может оказаться мало. Да, все легко допилить и настроить, но иногда беспокоиться об этом не нужно, т.к. любители Drupal’а уже все сделали.

Из альтернативных «версий» Drupal я могу посоветовать: BrainstormBlogger и Open Atrium. Первый проект – это сборка Drupal’а, специально созданная для быстрого создания блогов. Использовать чистый Drupal для строительства блога – процесс трудоемкий и не каждый новичок с ним справиться. Специально для таких случаев и людей наш соотечественник сделал альтернативную сборку Drupal. Из коробки brainstormblogger готов к работе и содержит в себе все необходимые модули (облако тегов, блог и т.д.) для развертывания полноценного блога. В случаях, когда нужен простой блог, то это идеальный вариант. Хочу также отметить, что применение Brainstorm blogger не накладывает никаких ограничений. Ты также можешь устанавливать дополнительные модули, выполнять автоматическое обновление движка и т.д.

Второй проект, о котором я хочу тебе рассказать – Open Atrium. Он позволяет в кратчайшие сроки поднять систему для совместной работы. Если ты руководишь отделом, то однозначно знаком с подобными проектами. Они позволяют закреплять задачи за определенным сотрудником, планировать время их выполнения, отслеживать процесс завершения, формировать отчеты и т.д. Большинство таких программ – платные, но в функциональном плане они недалеко уходят (или вовсе отстают) от Open Atrium. Если перед тобой встала задача найти и развернуть подобный софт, то обязательно присмотрись к этому продукту. Он быстр, функционален, бесплатен и при острой необходимости его можно допилить под себя. Набор ключевых функций привожу ниже:

Система тикетов;

Блоги;

Календарь;

Документы wiki;

Доска для групповой работы;

Совет #2: Рулим Drupal’ом из командной строки

Удобный web-интерфейс панели администрирования Drupal – это хорошо, но отнюдь не всегда удобно. Как было бы здорово, иметь возможность выполнять административные операции прямо из командной строки. А ведь это возможно! Достаточно загрузить и установить пакет drush. С его помощью администратор drupal’а может выполнять разнообразные действия прямо из консоли:

Получать информацию о настройках сайта;

Устанавливать/удалять модули;

Выполнять обновление движка;

и т.д.

Из всех возможностей drush я чаще всего пользуюсь функцией обновления модулей. Стандартный процесс загрузки апдейтов славиться своей занудностью. Изначально требуется составить список обновившихся модулей, затем зайти на официальный сайт Drupal и перейти на страницу модуля. Потом загрузить его, переместить в нужную директорию, выполнить скрипт обновления и т.д. Ладно, если нужно обновить один модуль, а если их 10, 20? Запросто можно сойти с ума! Куда веселей выполнять эту процедуру при помощи Drush. В этом случае достаточно воспользоваться командами up и upc. Удаление/отключение новых модулей выполняется аналогичным образом. Например, для удаления модуля предусмотрена команда:

$ ./drush uninstall <модуль или список модулей>
Примерно также происходит отключение и включение модулей:
$  ./drush en blog  //включаем модуль blog
$  ./drush dis blog  //отключаем модуль blog

Кроме перечисленных вкусностей, drush сослужит хорошую службу, если ты умудришься установить глючный модуль и положишь отображение панели администрирования. Как в такой нелегкой ситуации корректно удалить виновный модуль? При таком раскладе drush сможет оказать первую помощь и посредством одной команды удалит капризный модуль.

Совет #3: Авторизация по OpenID

Сайты с собственной системой авторизации отходят на второй план. Жизненно-необходимых web-сервисов с каждым днем становиться все больше и хранить в голове десятки связок из логинов/паролей задача не из легких. Чтобы как-то ее решить, в свое время и был создан OpenID – открытая централизованная система, позволяющая пользователю использовать единый логин/пароль для выполнения авторизации на различных сайтах. Последнее актуально, если они поддерживают OpenID.

Начиная с шестой версии, в составе Drupal идет модуль, обеспечивающий возможность авторизации по OpenID. Однако, чтобы начать использовать на сайте OpenID, необходимо подключить еще один модуль, содержащий настройки для различных поставщиков OpenID. Таких поставщиков много, но наиболее популярными (для российских пользователей) являются: Yandex, Rambler, Google, VKontakte, FaceBook и т.д. Для зарубежных сервисов (google, livejournal, facebook) в репозиториях drupal есть соответствующие модули, а вот для наших – нет. Когда передо мной встала задача прикрутить OpenID-авторизацию, то мне пришлось прошурстить интернет, с целью поиска решения. И оно нашлось! Чтобы все было тип-топ, нужно воспользоваться модулем OpenID Extension от нашего соотечественника. Обрати внимание, данный модуль – не очередной вариант взаимодействия с OpenID. Это просто удобный блок для выполнения авторизации, а также возможность выбора поствыщка в нашей стране ID параметров.

Совет #4: Drupal + «В Контакте»

Подключить на сайт авторизацию по OpenID несомненно полезно, ну, а что если только требуется обеспечить более простой вход на сайт (без регистрации) пользователям, имеющих аккаунт в социальной сети «В Контакте»? Да, можно просто отключить лишних поставщиков в External Form Login, но это не решит проблему. Выполняя вход по VKontakteID, пользователю фактически придется создать новую учетную запись на сайте. При входе он увидит стандартную регистрационную форму, ожидающая заполнени. Да, ему даже пароль придется придумывать.

Лишь после создания аккаунта к нему будет привязан OpenID идентификатор (в данном случае VKontakteID) и пользователь сможет выполнять вход по нему. Сам понимаешь, такой подход не очень удобный и воспользоваться им можно не всегда. Иногда требуется реализовать что-то более просто. Представь, как было бы здорово, имея пользователь аккаунт в «В Контакте», мог сразу войти на твой сайт. Другими словами, Drupal должен создавать новую учетную запись автоматически на основании полученных данных от «В Контакте». К счастью, добиться такого эффекта не так-то сложно. Примерно полгода назад разработчики популярной социальной сети открыли доступ к OpenAPI интерфейсу. Благодаря этому, пользователи получают возможность выполнять авторизацию на сторонних сайтах, используя учетную запись «В Контакте».

Добавить в Drupal поддержку «В Контакте OpenAPI» позволяет модуль VK OpenAPI. Модуль прост в использовании и с его помощью легко настроить «новую» систему авторизации. Помимо авторизации, VK OpenAPI может добавить к материалам кнопку “Share”, позволяющую пользователям делиться понравившимся материалом.

Совет #5: Выбираем продвинутый шаблонизатор

Одним из самых удачных шаблонизаторов для PHP считается Smarty. Во многих современных CMS используется именно он и на это есть причины. Главные из них – гибкость, удобство и большие возможности. Увы, по умолчанию в Drupal применяется собственный шаблонизатор, но при желании легко подключить smarty. Для этого необходимо загрузить smarty theme engine для Drupal и собственно сам Smarty (ссылку уже давал). После проделывания этих нехитрых операций, ты получишь возможность создавать темы на базе Smarty. Кстати, почему-то готовых тем на основе Smarty не так много, поэтому у тебя есть все шансы стать автором самой красивой и удобной Smarty темы, на которой будут учиться тысячи пользователей.

Совет #6: С чего начинать создание первой собственной темы для Drupal

Рано или поздно перед Drupal’ером встает задача по разработке собственной темы оформления. Я бы сказал, что именно на этом этапе, 90% новичков принимают фатальное решение – “Drupal не для меня”. Отчасти их можно понять, т.к. темизация – одна из самых сложных и непонятных вещей. Нужно приложить усилия, чтобы хорошо освоить данный процесс и применять его в дальнейшем без сучка и задоринки. Чтобы процесс освоения проходил более гладко и понятно, то я бы рекомендовал тебе выполнить несколько простых шагов.

Чтение мануалов. Если уровень английского позволяет, то знакомиться с темизацией стоит после чтения официальной документации (http://drupal.org/documentation/theme). Написано в ней много как полезного, так и бесполезного материала. В любом случае, изучив его, ты однозначно поймешь, как в Drupal работают темы, и познакомишься с другими нюансами этой области. Вторым, обязательным для чтения документом будет цикл статей от Романа Архарова – профессионального Drupal разработчика. Роман написал несколько замечательных статей по Drupal. Среди них есть отличная статья про темизацию.

Изучение темы Zen. Начать разрабатывать новую тему для Drupal с чистого листа – довольно сложный процесс. Новичку вряд ли хватит сил и терпения завершить его до конца. Для облегчения жизни лучше взять за основу тему Zen. Весь код темы хорошо прокомментирован и работать с ним одно удовольствие. Кстати, именно Zen рекомендован разработчиками, приступивших к изучению темизации Dupal.

Совет #7: Shared хостинг или VPS?

Сам по себе Drupal достаточно шустрый, но стоит обвешать его дополнительными модулями и вывести в реальное плавание, как начинаются проблемы с производительностью. Чтобы Drupal летел также быстро, как падает капля дождя с неба, нужно позаботиться о правильной настройке окружающей его среды. Речь конечно о WEB-сервере, СУБД, PHP и т.д. Максимальная производительность возможна лишь при тщательной настройке всех компонент. К несчастью, получить доступ ко многим настройкам, перечисленного ПО, на обычном хостинге нельзя. Приходиться довольствоваться тем, что предлагает хостер.

Если сайт мало посещаем, то все ok. В противном случае, посетители будут часто видеть белый экран смерти, нежели ожидаемый ресурс. Исходя из вышесказанного, советую не использовать shared-хостинг для размещения более-менее посещаемого ресурса. Лучше немного потратить денег и приобрести VPS, где ты будешь главным хозяином и будешь сам определять настройки всех серверных компонент (включая ОС).

Совет #8: Начальная оптимизация

Сразу после установки Drupal нужно приступить к базовой оптимизации. Хоть Drupal и быстр, но если есть возможность что-то ускорить, ей надо пользоваться. Процесс оптимизации Drupal условно можно разделить на три группы:

Базовая. Реализуется средствами движка. Рулить этими параметрами ты можешь самостоятельно из панели администрирования сразу после завершения инсталляции системы.

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

Серверная. Под серверной оптимизацией подразумевается настройка серверных компонент, взаимодействующих с Drupal.

Итак, вначале посмотрим на базовую оптимизацию. В настройках производительности системы (admin/settings/performance) доступно несколько настроек, влияющих на быстродействие. Первое с чего стоит начать оптимизацию – включение кэша. По умолчанию он отключен и администратору доступно два варианта кэширования: нормальный и агрессивный. Самую большую производительность дает агрессивный режим, но не стоит обольщаться. Лучше выбрать «Нормальный». Это оптимальный режим для сайта с большим числом зарегистрированных пользователей. Если же сайт мало посещаем, то в таком случае хорошим выбором станет «агрессивный режим».

Советую обратить внимание на группу настроек «Оптимизация пропускной способности». Она позволяет активировать объединение CSS и JavaScript в единые файлы. Зачем? Дело в том, что многие дополнительные модуля тянут с собой css/js файлы. При загрузке очередной страницы, происходит обращение к нескольким файлам на сервере. А это в свое очередь лишние соединения. Чтобы минимизировать затраты, можно выполнить объединение. В этом случае Drupal будет создавать единый файл с css/js, который и будет загружаться браузером пользователя.

Совет #9: Серверные компоненты

С самого начала важно понять, то быстродействие Drupal напрямую зависит от настройки компонентов внешней среды. К таковым относятся: web-сервер (см. совет 14), СУБД, PHP. Если кто-то один из них работает неэффективно, то ни о какой хорошей производительности не может быть и речи. Настраивать все эти компоненты можно долго, но я хотел бы обратить твое внимание на самые важные настройки.

PHP. Весь Drupal написан сугубо на php, поэтому крайне важно позаботиться о настройке этого интерпретатора. В конфигурационном файле php есть куча директив, но для drupal особенно важной будет php_value memory_limit. Как видно из названия, директива отвечает за объем памяти выделяемой для выполнения сценария. Понятное дело, чем ее больше, тем лучше. Если говорить конкретно в цифрах, то крайне желательно установить значение больше 32M (т.е. больше 32-х мегабайт). Помимо установки объема памяти, не менее важной опцией является max_excecution_time ( максимальное время выполнения сценария). Обычно здесь выставляеят значение от 30 и выше. Чем больше будет время исполнения сценария, тем меньше ты будешь видеть белый экран смерти.

Акселератор для PHP. Как бы там не хвалили PHP за простоту и быстродействие, этот интерпретатор все равно медленный и с этим трудно не согласится. Для выполнения каждого сценария, интерпретатору необходимо сначала считать и разобрать весь код сценария, затем выполнить его и вернуть результаты. Это операция проводится постоянно и на нее тратится самый драгоценный ресурс – время. Для решения этой проблемы были придуманы так называемые PHP акселераторы – программы, ускоряющие выполнение PHP-сценариев. Ускорение достигается за счет кэширования байткода каждого сценария. Для достижения максимальной производительности желательно установить какой-нибудь акселератор. Один из наиболее удачных представителей этой области – eAccelerator. Он прост в установке и настройке и существенно увеличивает реакцию интерпретатора.

СУБД. Чаще всего в качестве СУБД для web-проектов выступает MySQL. Он быстр, бесплатен, кросс-платформенен и обладает всеми необходимыми функциями. По настройке и оптимизации MySQL пишут целые книги. Я не буду лезть в дебри, а сразу посоветую включить кэширование (в mysql).

Совет #10: Альтернативное кэширование

В оптимизации не существует пределов. Всегда найдется узенькое место пригодное для оптимизации. К несчастью (а может наоборот) в Drupal таких мест более, чем предостаточно. Одним словом – работать есть над чем. Одним из таких тормозков - встроенная система кэширования. Она работает хорошо, но для больших проектов ее не хватает. Именно поэтому, членами сообщества Drupal была разработана альтернативная система кэширования. Решений подобного рода несколько, но лучше всех выделяется cacherouter (http://drupal.org/project/cacherouter). Проект CR представляет собой модуль для Drupal и реализует хранение кэша в памяти, посредством возможностей демона memcached или акселераторов (APC, eAccelerator, XCache). Вердикт – рекомендовано для больших проектов.

Совет #11: Views вместо своих запросов

Как-то раз мне попался сайт на базе Drupal. В нем, во многих местах были понатыканы sql запросы. Разработчик использовал их для вывода в блоки различной информации: последние статьи, последние новости и т.д. Способ имеет право на существование, но пользоваться им все же не рекомендуется. Правильней будет воспользоваться модулем Views. Он позволяет создавать различные представления, и самое главное делает их эффективно. Тебе не нужно разбираться в структуре БД. Даже сложные выборки реально сделать путем применения визуального конструктора. Кроме того, при создании очередного представления доступна возможность управлять кэшированием. При создании вьюшек для редко изменяемой информации, эта возможность будет кстати.

Совет #12: Drupal.API

Существует заблуждение, что можно пренебрегать применением API, а использовать старый дедовский способ – прямое выполнение SQL запросов. Конечно, есть ряд задач, решать которые, лучше именно таким способом. Правда, такие задачи скорей исключение. Во всех остальных ситуациях, правильней будет пользоваться Drupal API. Вызывая документированные функции, разработчик может быть уверен, что его действия не повлекут за собой негативные последствия. К примеру, если для добавления нового пользователя существует специальная функция, то ни в коем случае не надо показывать понты и делать это запросом. В случаях, когда функции мало, то желательно посмотреть ее исходник и уже на основании кода посмотреть выполняемые запросы, и только затем на их основе составлять собственные.

Совет #13: Нагрузочное тестирование

Вновь созданный проект лучше сразу подвергнуть жесткому тестированию. Хоть трижды закрути все болты и гайки, а шанс, что сайт не выдержит шквала посетителей - есть всегда. Желательно сразу потратить время на нагрузочное тестирование и на ранних этапах исключить возможные провалы. Для проведения подобных тестов хорошо себя зарекомендовал сервис http://loadimpact.com. Он предлагает различные тесты для проверки web-проекта на устойчивость к нагрузкам. Тесты есть на любой вкус и кошелек. Для серьезного анализа имеется pro версия. Она конечно стоит денег, но тестов в ней больше, а следовательно и пользы от нее ощутимей. Не пугайся, если проект поднимается на общественных началах, то хватит и бесплатного варианта. Во всяком случае, ты будешь уверен, что твой сайт будет уверенно себя чувствовать при заходе на него пятидесяти человек.

Совет #14: Хороший индеец – мертвый индеец

Ни для кого не секрет, что олимп web-серверов уже много лет возглавляет Apache. Это действительно хорошее и качественное программное обеспечение, правда, не слишком быстрое. В связке с Drupal он показывает не совсем хорошие результаты и при большом наплыве посетителей становится самым узким местом. Частично победить тормоза позволяет хардкорный тюнинг, но превратить его в гепарда все равно не удастся. Лучше сразу от него отказаться и забыть как о страшном сне. А чем тогда же пользоваться? Конечно же nginx! В настоящее время, nginx пожалуй самый быстрый WEB-сервер. Того же Apache он обходит уже на старте и практически ничем ему не уступает (за исключением пока не большего количества модулей). На проекте VR-Online мы решили отказаться от Apache и полностью перешли на nginx. Производительность возросла на глаз. При открытии страниц создается впечатление, что на генерирование требуется времени. При использовании Apache об этом можно было только мечтать.

Совет #15: Приручаем nginx

Nginx превосходно подходит для Drupal’овских проектов, но чтобы все правильно и четко работало, нужно уделить время настройке. Тут методом научного тыка не обойтись. Придется пересилить себя и прочитать объемную документацию, а также повторить все полученные знания на практике. Чтобы как-то облегчить себе жизнь, рекомендую скачать конфиг для nginx, специально созданный для Drupal. Предложенный конфигурационный файл содержит все необходимое, для того, чтобы Drupal корректно заработал с nginx. Если перечислить возможности, которые отражены в конфигурационном файле, то получится:

Чистые url;

Мультисайтинг;

Повышенное время выполнения fastcgi;

Поддержка boost;

и т.д.

Совет #16: Готовься к Drupal 8

Не забывай, что разработчики уже давненько трудятся над созданием восьмой верси этого замечательного фреймворка. Восьмая версия будет сильно отличаться от предшественников. Разбираться с внутренностями новой версии лучше начинать прямо сейчас.

Заключение

Drupal – не типичная cms, которую легко настроить в несколько кликов мышкой. Чтобы выжать из него максимум и поднять не типичный проект – придется повозиться. Как следует повозиться и почитать форумы/документацию. После успешного первого проекта он уже не будет казаться таким страшным и странным. Не отступай и не сдавайся! Пробуй, экспериментируй, и я надеюсь, мои drupal’ные советы тебе помогут. Удачи!

Статья опубликована в журнале "Хакер" (http://xakep.ru). Февраль 2011 г.

Ссылка на журнал: http://goo.gl/lzfLnl