Views — один из самых востребованных модулей для Drupal — позволяет создавать списки документов (представления, view), отфильтрованные по любому сложному алгоритму. На выходе модуль возвращает массив данных, который выводится в шаблоне, соответствующем выбранному администратором типу отображения (display) данных.

Прежде чем говорить об изменении внешнего вида форм, ознакомимся с основами Drupal Forms API — программного интерфейса, используемого для генерации форм. Применение Forms API несколько сложнее создания HTML-форм вручную, так как требует изучения логики его работы, однако его использование обязательно, поскольку Forms API решает ряд важных задач:

• любой разработчик может добавить или удалить элементы в форме, созданной другим разработчиком, не меняя ее исходного кода;
• любой разработчик может добавить дополнительные функции проверки и обработки введенных пользователем данных без изменения исходной формы;
• формы, созданные с использованием Forms API, защищены от атак, связанных с отправкой пользователем модифицированной формы;
• любой разработчик может изменить внешний вид формы, не изменяя ее исходного кода.

Каждая форма в Drupal представляет собой функцию, возвращающую ассоциативный массив. Этот массив должен содержать информацию обо всех элементах формы, функциях проверки (валидаторы, validators) и обработки (сабмиттеры, submitters) введенных данных. Данная функция должна быть расположена в файле модуля, о разработке модуля говорилось в предыдущей статье.

Как и в случае с модулем, разработка которого рассматривалась в предыдущей статье, тема оформления должна иметь уникальное имя, состоящее из строчных латинских букв, цифр и знаков подчеркивания, и это имя должно начинаться с буквы. Тема оформления — это несколько файлов, которые располагаются в папке sites/all/themes/имя_темы относительно корня Drupal.

PHPTemplate при сборке страницы берет информацию из пяти основных файлов: имя_темы.info, page.tpl.php, node.tpl.php, block.tpl.php, template.php. Если же включен модуль comment, для вывода комментариев используется шаблон comment.tpl.php.

Drupal часто ругают за однообразность и узнаваемость дизайна, используемого на Drupal-сайтах. То, что за определенным сайтом стоит CMS Drupal, можно определить не только по URL-адресам специфического вида, узнаваемым путям к папкам модулей и главной странице в виде списка последних опубликованных документов, но и по стандартной двух-трехколоночной структуре сайта, наличию стандартных форм авторизации и поиска, облаков тегов, списков новых документов и других часто используемых блоков.

Однако все эти упреки несправедливы. Здесь можно процитировать старый анекдот: «Вы просто не умеете его готовить». На самом деле к Drupal при должном умении можно «прикрутить» дизайн и верстку любой сложности. Можно до неузнаваемости «темизировать», т. е. изменять внешний вид любого HTML-кода, создаваемого Drupal, — все стандартные формы, блоки, документы и списки. Просто для этого нужно понимать, как Drupal генерирует выходные данные (информация об этом была размещена в моей предыдущей статье), и уметь переопределять этот вывод. Примеров таких детально темизированных сайтов много, в одной из врезок вы можете найти ссылки на некоторые из них.

В этой статье я расскажу о трех этапах темизации, охватывающих практически 100% задач, связанных с изменением внешнего вида сайта: разработка общего шаблона для всех страниц сайта и «кастомных» шаблонов для избранных страниц; разработка шаблонов для разных типов документов и списков; изменение внешнего вида форм (поиск, авторизация и любые другие стандартные и создаваемые внешними модулями формы). Но прежде чем переходить к решению задач, познакомимся с основными используемыми терминами и структурой любой «темы оформления».

Регулярные процедуры Чтобы Drupal периодически выполнял определенные действия, в планировщике задач операционной системы необходимо настроить запуск файла cron.php, который находится в корне каждого Drupal-сайта. При выполнении этого файла будет вызываться хук hook_cron, и в нашем модуле мы напишем его реализацию.

currencies.info В .info-файлах модулей содержится служебная информация, без которой модуль не будет виден в системе. Начинаться любой .info-файл должен со строки ; $Id$ В файлах с PHP-кодом после открывающего тега <?

Система управления сайтом Drupal построена по модульному принципу: компактный набор служебных функций (ядро) расширяется при помощи модулей — файлов с PHP-кодом. Модули должны содержать «хуки» (hooks) — особым образом именованные функции, которые вызываются ядром Drupal при возникновении каких-либо событий. Каждый модуль имеет системное имя, которое должно состоять из латинских букв, цифр, знака подчеркивания (и начинаться обязательно с буквы). Имя хука должно состоять из двух частей: имени модуля и названия события. При возникновении любого события ядро Drupal в каждом из установленных модулей ищет и выполняет соответствующую функцию, т. е. функцию с именем название_модуля_название_события. Например, при возникновении событий, связанных с учетной записью пользователя (регистрация, авторизация, изменение роли пользователя и др.), ядро Drupal вызывает функции, реализующие хук hook_user, поэтому, чтобы модуль с именем **example **мог отреагировать на это событие, в нем необходимо объявить функцию с именем example_user(). Список передаваемых в эту функцию аргументов, пример ее использования и информацию обо всех функциях и хуках, доступных в Drupal, можно найти на странице официальной документации http://api.drupal.org или ее русской версии: http://api.drupal.ru.

Эта статья — продолжение материала, посвященного CMS Drupal (см. PC Magazine/RE, 12/2008). В первой статье подробно рассказано о назначении и возможностях системы, а также приведены примеры сборки сайтов на Drupal с использованием уже существующих модулей. Этот же материал будет больше интересен техническим специалистам, умеющим программировать на языке PHP, знакомых с основами HTML и CSS, и тем, кто хочет познакомиться с методами разработки собственных модулей для этой системы. Перед чтением этого материала рекомендуется освежить в памяти информацию, просмотрев ее первые три раздела.

Способы оптимизации сильно зависят от конкретной задачи и системного окружения. Свою роль в выборе способов оптимизации играют набор используемых на сайте модулей и соотношение трафика от анонимных и зарегистрированных посетителей. Обычно окончательное заключение об эффективности того или иного метода можно дать только после его тестирования на реальном сайте.

По умолчанию Drupal ориентирован на хранение максимума информации в базе данных. Контент, служебные переменные и настройки сайта, кэши данных — все это складывается в БД. Не всегда такая схема может быть эффективна, и Drupal предлагает ряд альтернатив.