Содержание статьи
- Совет №1: Каждому проекту — свой Drupal
- Совет №2: Рулим Drupal'ом из командной строки
- Совет №3: Авторизация по OpenID
- Совет №4: Drupal + «ВКонтакте»
- Совет №5: Выбираем продвинутый шаблонизатор
- Совет №6: С чего начинать создание первой собственной темы для Drupal?
- Совет №7: Shared хостинг или VPS?
- Совет №8: Начальная оптимизация
- Совет №9: Серверные компоненты
- Совет №10: Альтернативное кэширование
- Совет №11: Views вместо своих запросов
- Совет №12: Drupal.API
- Совет №13: Нагрузочное тестирование
- Совет №14: Хороший индеец — мертвый индеец
- Совет №15: Приручаем nginx
- Совет №16: Готовься к Drupal 7
- Заключение
- Links
Про него говорят: гибкий и сложный, безопасный и быстрый. Им многие восхищаются, но не все решаются применять в своих проектах. Да, он такой, этот Drupal. Умеет многое, но чтобы получить от него максимальную отдачу, разработчику придется как следует попотеть и разобраться в многочисленных тонкостях. Этот путь тернист и труден, но цель однозначно того стоит. Я начал применять Drupal в своем большом проекте не так давно, но уже успел набить несколько шишек и хочу уберечь от этого тебя. Заинтригован? Тогда приготовься выслушать советы от уже не совсем начинающего Drupal'ера.
Совет №1: Каждому проекту — свой Drupal
Drupal пригоден не только для строительства web-сайтов, но и для разработки web-приложений. Зачастую подобные приложения разрабатываются для внутрикорпоративных нужд. К таким проектам предъявляются совсем другие требования, и типичной сборки Drupal может оказаться мало. Да, все легко допилить и настроить, но иногда беспокоиться об этом не нужно, так как любители Drupal'а уже все сделали.
Из альтернативных «версий» Drupal я могу посоветовать BrainstormBlogger (brainstormblogger.org) и Open Atrium (openatrium.com). Первый проект — это сборка Drupal'а, специально разработанная для быстрого создания блогов. Использовать чистый Drupal для строительства блога — процесс трудоемкий, и не каждый новичок с ним справится. Специально для таких случаев и людей наш соотечественник сделал альтернативную сборку Drupal. Rainstorm Blogger готов к работе прямо из коробки и содержит в себе все необходимые модули (облако тегов и прочее) для развертывания полноценного блога. В случаях, когда нужен простой блог, это идеальный вариант.
Также хочу отметить, что применение Brainstorm blogger не накладывает никаких ограничений. Ты можешь устанавливать дополнительные модули, выполнять автоматическое обновление движка и так далее.
Второй проект, о котором я хочу тебе рассказать — Open Atrium. Он позволяет в кратчайшие сроки поднять систему для совместной работы. Если ты руководишь отделом, то однозначно знаком с подобными проектами. Они позволяют закреплять задачи за определенным сотрудником, планировать время их выполнения, отслеживать процесс завершения, формировать отчеты и прочее.
Большинство таких программ — платные, но в функциональном плане они не сильно выигрывают (или вовсе проигрывают) Open Atrium. Если перед тобой встала задача найти и развернуть подобный софт, то обязательно присмотрись к этому продукту. Он быстрый, функциональный, бесплатный, и при острой необходимости его можно допилить под себя. Набор ключевых функций привожу ниже:
- Система тикетов;
- Блоги;
- Календарь;
- Документы wiki;
- Доска для групповой работы.
Совет №2: Рулим Drupal'ом из командной строки
Удобный web-интерфейс панели администрирования Drupal — это хорошо, но отнюдь не всегда удобно. Как было бы здорово иметь возможность выполнять административные операции прямо из командной строки… А ведь это возможно! Достаточно загрузить и установить пакет drush (http://drupal.org/project/drush). С его помощью администратор drupal'а может выполнять разнообразные действия прямо из консоли:
- Получать информацию о настройках сайта;
- Устанавливать/удалять модули;
- Выполнять обновление движка и так далее.
Из всех возможностей drush я чаще всего пользуюсь функцией обновления модулей. Стандартный процесс загрузки апдейтов славится своей занудностью. Изначально требуется составить список обновившихся модулей, затем зайти на официальный сайт Drupal и перейти на страницу конкретного модуля. Потом загрузить его, переместить в нужную директорию, выполнить скрипт обновления и прочее. Ладно еще, если нужно обновить один модуль, а если их десять, двадцать? Запросто можно сойти с ума! Куда веселее выполнять эту процедуру при помощи 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, LiveJournal, VKontakte, Facebook и некоторые другие. Для зарубежных сервисов (Google, LiveJournal, Facebook) в репозиториях Drupal есть соответствующие модули, а вот для российских — нет. Когда передо мной встала задача прикрутить OpenID-авторизацию, то мне пришлось основательно прошерстить интернет с целью поиска решения. И оно нашлось! Чтобы все было тип-топ, нужно воспользоваться модулем OpenID Extension (http://drupal.org/files/issues/openid_ext_1.zip) от нашего соотечественника. Обрати внимание, данный модуль — не очередной вариант взаимодействия с OpenID. Это просто удобный блок для выполнения авторизации, а также возможность выбора поставщика ID-параметров в нашей стране.
Совет №4: Drupal + «ВКонтакте»
Включить на сайте авторизацию по OpenID, несомненно, полезно, но что если нам потребуется всего лишь обеспечить более простой вход на сайт (без регистрации) пользователям, имеющим аккаунт в социальной сети «ВКонтакте»? Да, можно просто отключить лишних поставщиков в External Form Login, но это не решит проблему. Выполняя вход по VKontakteID, пользователю фактически придется создать новую учетную запись на сайте. При входе он увидит стандартную регистрационную форму, ожидающую заполнения. Да, даже пароль придется придумывать. И лишь после создания аккаунта к нему будет привязан OpenID-идентификатор (в данном случае VKontakteID), и пользователь сможет выполнять вход по нему. Сам понимаешь, такой подход не очень удобен, и воспользоваться им можно не всегда.
Иногда требуется реализовать что-то более простое. Представь, как было бы здорово, если бы пользователь, имеющий аккаунт «ВКонтакте », мог сразу войти на твой сайт. Другими словами, Drupal должен создавать новую учетную запись автоматически на основании полученных данных от «В Контакте». К счастью, добиться такого эффекта не так-то сложно. Примерно полгода назад разработчики популярной социальной сети открыли доступ к OpenAPI-интерфейсу. Благодаря этому пользователи получают возможность выполнять авторизацию на сторонних сайтах, используя учетную запись «ВКонтакте».
Добавить в Drupal поддержку «ВКонтакте OpenAPI» позволяет модуль VK OpenAPI (http://drupal.org/project/vk_openapi). Модуль прост в использовании, и с его помощью легко настроить новую систему авторизации. Помимо авторизации VK OpenAPI может добавить к материалам кнопку «Share», позволяющую пользователям делиться понравившимся материалом.
Совет №5: Выбираем продвинутый шаблонизатор
Одним из самых удачных шаблонизаторов для PHP считается Smarty (www.smarty.net). Во многих современных CMS используется именно он, и на это есть причины. Главные из них — гибкость, удобство и большие возможности. Увы, по умолчанию в Drupal применяется собственный шаблонизатор, но при желании легко можно подключить и smarty. Для этого необходимо загрузить smarty theme engine для Drupal (http://drupal.org/project/smarty) и, собственно, сам Smarty (ссылку ищи выше). После этих нехитрых операций ты получишь возможность создавать темы на базе Smarty. Кстати, почемуто готовых тем не так много, поэтому у тебя есть все шансы стать автором самой красивой и удобной Smarty-темы, на которой будут учиться тысячи пользователей.
Совет №6: С чего начинать создание первой собственной темы для Drupal?
Рано или поздно перед Drupal'ером встает задача по разработке собственной темы оформления. Я бы сказал, что именно на этом этапе 90% новичков принимают фатальное решение: «Drupal не для меня». Отчасти их можно понять, поскольку темизация — одна из самых сложных и непонятных вещей. Нужно приложить усилия, чтобы хорошо освоить данный процесс и применять его в дальнейшем без сучка и задоринки. Чтобы освоение проходило более гладко и понятно, я бы рекомендовал тебе выполнить несколько простых шагов.
- Чтение мануалов. Если уровень английского позволяет, то знакомиться с темизацией стоит после чтения официальной документации (http://drupal.org/documentation/theme). В ней содержится куча как полезного, так и бесполезного материала. В любом случае, изучив его, ты однозначно поймешь, как работают темы в Drupal и познакомишься с другими нюансами этой области. Вторым обязательным для чтения пунктом будет цикл статей от Романа Архарова, профессионального Drupal-разработчика. Роман написал несколько замечательных статей по Drupal (http://pcmag.ru/solutions/detail.php?ID=37518). Среди них есть и статья про темизацию.
- Изучение темы Zen. Начать разрабатывать новую тему для Drupal с чистого листа — довольно сложный процесс. Новичку вряд ли хватит сил и терпения завершить его до конца. Для облегчения жизни лучше взять за основу тему Zen (http://drupal.org/project/zen). Весь код темы хорошо прокомментирован и работать с ним — одно удовольствие.
Совет №7: Shared хостинг или VPS?
Сам по себе Drupal достаточно шустрый, но стоит обвешать его дополнительными модулями и вывести в свободное плавание, как начинаются проблемы с производительностью. Чтобы Drupal «летал», нужно позаботиться о правильной настройке окружающей его среды. Речь идет, конечно, о web-сервере, СУБД, PHP и так далее. Максимальная производительность возможна лишь при тщательной настройке всех компонентов. К несчастью, получить доступ ко многим настройкам перечисленного ПО на обычном хостинге нельзя.
Приходится довольствоваться тем, что предлагает хостер. Чтобы посетители твоего проекта не наблюдали белый экран смерти вместо искомого сайта, я советую тебе не использовать shared-хостинг для размещения более-менее посещаемого ресурса. Лучше потратить немного денег и приобрести VPS, на котором ты будешь хозяином и сможешь сам определять настройки всех серверных компонентов (включая ОС).
Совет №8: Начальная оптимизация
Сразу после установки Drupal нужно приступить к базовой оптимизации. Drupal быстр, но если есть возможность что-то ускорить, ей надо пользоваться. Процесс оптимизации Drupal условно можно разделить на три группы:
- Базовая.Реализуется средствами движка. Самостоятельно рулить этими параметрами из панели администрирования ты можешь сразу после завершения инсталляции системы.
- Расширенная.Для Drupal разработаны специальные модули, позволяющие повысить общую производительность системы (например, посредством продвинутого кэширования).
- Серверная.Под серверной оптимизацией подразумевается настройка серверных компонентов, взаимодействующих с Drupal.
Итак, вначале посмотрим на базовую оптимизацию. В настройках производительности системы (admin/settings/performance) доступно несколько опций, влияющих на быстродействие. Первое, с чего стоит начать оптимизацию, — включение кэша. По умолчанию он отключен и администратору доступно два варианта кэширования: «нормальный» и «агрессивный». Самую большую производительность дает «агрессивный» режим, но не стоит обольщаться.
Лучше выбрать «нормальный». Это оптимальный режим для сайта с большим числом зарегистрированных пользователей. Если же сайт малопосещаем, то в таком случае хорошим выбором станет «агрессивный» режим.
Советую обратить внимание на группу настроек «Оптимизация пропускной способности». Она позволяет активировать объединение CSS и JavaScript в единые файлы. Зачем? Дело в том, что многие дополнительные модули тянут с собой css/js файлы. При загрузке очередной страницы происходит обращение к нескольким файлам на сервере. А это, в свою очередь, лишние соединения. Чтобы минимизировать затраты, можно выполнить объединение. В этом случае Drupal создаст единый файл с css/js, который и будет загружаться браузером пользователя.
Совет №9: Серверные компоненты
С самого начала важно понять, что быстродействие Drupal напрямую зависит от настройки компонентов внешней среды. К таковым относятся web-сервер, СУБД и PHP. Если что-то из этого списка работает неэффективно, то ни о какой хорошей производительности не может быть и речи. Настраивать все компоненты можно долго, но я хотел бы обратить твое внимание на самые важные настройки — настройки PHP. Весь Drupal написан сугубо на PHP, поэтому крайне важно позаботиться о настройке этого интерпретатора. В конфигурационном файле PHP есть куча директив, но для Drupal особенно важной будет php_value memory_ limit. Как видно из названия, директива отвечает за объем памяти, выделяемой для выполнения сценария.
Понятное дело, что чем ее больше, тем лучше. Если говорить конкретно в цифрах, то крайне желательно установить значение больше 32M (то есть больше 32-х мегабайт). Помимо установки объема памяти, не менее важной опцией является max_excecution_time (максимальное время выполнения сценария). Обычно здесь выставляют значение от 30 и выше. Чем больше будет время исполнения сценария, тем меньше ты будешь видеть белый экран смерти.
- Акселератор для PHP
Как бы в народе не хвалили PHP за простоту и быстродействие, трудно не согласиться с тем, что этот интерпретатор все равно медленный. Для выполнения каждого сценария интерпретатору PHP необходимо сначала считать и разобрать весь код сценария, затем выполнить его и вернуть результаты. Эта операция проводится постоянно, и на нее тратится самый драгоценный ресурс — время. Для решения этой проблемы были придуманы так называемые php-акселераторы — программы, ускоряющие выполнение php-сценариев.
Ускорение достигается за счет кэширования байт-кода каждого сценария. Для достижения максимальной производительности желательно установить какойнибудь акселератор. Один из наиболее удачных представителей этого типа программ — eAccelerator (http://www.eaccelerator.net). Он прост в установке и настройке, а также существенно ускоряет реакцию интерпретатора.
- СУБД
Чаще всего в качестве СУБД для web-проектов выступает MySQL. Он быстрый, бесплатный, кроссплатформенный и обладает всеми необходимыми функциями. Но по настройке и оптимизации MySQL пишут целые книги, так что я не буду лезть в дебри, а сразу посоветую включить кэширование (в mysql).
Совет №10: Альтернативное кэширование
В вопросе оптимизации пределов не существует. Но в Drupal таких ограничений более, чем достаточно. И одним из таких тормозов является встроенная система кэширования. Она работает хорошо, но для больших проектов ее не хватает. Именно поэтому членами сообщества Drupal была разработана альтернативная система кэширования.
Решений подобного рода несколько, но лучшим из них я считаю cacherouter (http://drupal.org/project/cacherouter). Проект CR представляет собой модуль для Drupal и реализует хранение кэша в памяти посредством возможностей демона memcached или акселераторов (APC, eAccelerator, XCache). В общем, рекомендовано для больших проектов.
Совет №11: Views вместо своих запросов
Как-то раз мне попался сайт на базе Drupal. В нем во множестве мест были понатыканы sql-запросы. Разработчик использовал их для вывода в блоки различной информации: последние статьи, последние новости и прочее. Способ имеет право на существование, но пользоваться им все же не рекомендуется. Правильнее будет воспользоваться модулем Views (http://drupal.org/project/views).
Он позволяет создавать различные представления, и, самое главное, делает их эффективно. Тебе не нужно разбираться в структуре БД — даже сложные выборки реально сделать путем применения визуального конструктора.
Кроме того, есть возможность управлять кэшированием, создавая очередное представление. При реализации вьюшек для редко изменяемой информации эта возможность будет кстати.
Совет №12: Drupal.API
Существует заблуждение, что вместо использования API можно отдать предпочтение дедовскому способу — прямому выполнению SQL запросов. Конечно, есть ряд задач, решать которые лучше именно таким способом. Но это скорее исключение. Во всех остальных ситуациях правильнее будет пользоваться Drupal.API. Вызывая документированные функции, разработчик может быть уверен, что его действия не повлекут за собой негативные последствия. К примеру, если для добавления нового пользователя существует специальная функция, то ни в коем случае не стоит показывать понты и делать это запросом. В случаях, когда функции мало, желательно все же сначала посмотреть ее исходник, изучить выполняемые запросы и только затем на их основе составлять собственные.
Совет №13: Нагрузочное тестирование
Вновь созданный проект лучше сразу подвергнуть жесткому тестированию. Хоть трижды закрути все болты и гайки, но шанс, что сайт не выдержит шквала посетителей, есть всегда. Желательно сразу потратить время на нагрузочное тестирование и уже на ранних этапах исключить возможные провалы. Для проведения подобных тестов хорошо себя зарекомендовал сервис http://loadimpact.com. Он предлагает различные тесты для проверки web-проекта на устойчивость к нагрузкам. Тесты есть на любой вкус и кошелек. Для серьезного анализа имеется pro-версия. Она, конечно, стоит денег, но тестов в ней больше, а значит и польза — ощутимей. Не пугайся: если проект поднимается на общественных началах, то хватит и бесплатного варианта. Во всяком случае, ты будешь точно знать, что твой сайт уверенно себя чувствует при заходе на него пятидесяти человек.
Совет №14: Хороший индеец — мертвый индеец
Ни для кого не секрет, что олимп web-серверов уже много лет возглавляет Apache. Это действительно хорошее и качественное ПО, хотя и не слишком быстрое. Apache в связке с Drupal показывает не лучшие результаты и при большом наплыве посетителей становится самым узким местом. Частично победить тормоза позволяет хардкорный тюнинг, но превратить его в гепарда все равно не удастся. Лучше сразу от него отказаться и забыть, как о страшном сне. А чем же тогда пользоваться? Конечно же nginx (http://sysoev.ru/nginx)! В настоящее время nginx, пожалуй, самый быстрый web-сервер. Тот же Apache он обходит уже на старте и практически ничем ему не уступает (за исключением количества модулей, которое у nginx пока невелико). Недавно на нашем проекте (http://vr-online.ru) мы решили отказаться от Apache и полностью перешли на nginx. Производительность возросла даже визуально: при открытии страниц создается впечатление, что на генерирование вообще не требуется времени. При использовании Apache об этом можно было только мечтать.
Совет №15: Приручаем nginx
Nginx превосходно подходит для Drupal'овских проектов, но чтобы все четко и правильно работало, нужно уделить время настройке. Тут методом научного тыка не обойтись. Придется пересилить себя и прочитать объемную документацию, а также повторить все полученные знания на практике. Чтобы как-то облегчить себе жизнь, рекомендую скачать конфиг (https://github.com/yhager/nginx_drupal) для nginx, специально созданный для Drupal. Предложенный конфигурационный файл содержит все необходимое для того чтобы Drupal корректно заработал с nginx. Если перечислить возможности, которые отражены в конфигурационном файле, то получится:
- чистые url;
- мультисайтинг;
- повышенное время выполнения fastcgi;
- поддержка boost и так далее.
Совет №16: Готовься к Drupal 7
Не забывай, что разработчики уже давненько трудятся над созданием седьмой версии этого замечательного фреймворка. Совсем недавно вышел первый (на момент написания этих строк) релиз-кандидат, и я бы рекомендовал тебе его потестировать при возможности. В новой ветке реализованы интересные фичи, которых так давно не хватало Drupal'у.
Заключение
Drupal — не самая простая CMS, которую легко настроить в несколько кликов мышкой. Чтобы выжать из него максимум и поднять нетипичный проект, придется повозиться. Точнее — как следует повозиться. Однако после первого успешного проекта Drupal уже не будет казаться таким страшным и странным. Не отступай и не сдавайся! Пробуй, экспериментируй и, я надеюсь, мои drupal'ные советы тебе помогут.
Удачи!
Links
- drupal.org — официальный сайт сообщества Drupal: здесь тебя всегда ждет последняя версия CMF, актуальная документация, обширный репозиторий модулей;
- www.drupal.ru — русскоязычное сообщество Drupal: пожалуй, старейший ресурс о Drupal в рунете. Есть активный форум, свежие новости, большое количество людей, готовых оказать первую помощь;
- http://contentmanagementsystems.info/ — отличный русскоязычный ресурс о Drupal: сниппеты, FAQ, статьи о CMF Drupal;
- vr-online.ru — бесплатный электронный журнал для программистов и всех тех, кто интересуется околокомпьютерными вопросами.
С недавнего времени на сайте появился раздел, посвященный Drupal. Пока статей немного, но уже есть, что почитать.