Это первый из двух постов из серии «Начало работы с Drupal», написанных приглашенным писателем Тобиасом Шёстеном . Тобиас — веб-техник и поклонник открытого исходного кода, который специализируется на стеке LAMP, при этом Symfony и Drupal особенно близки его сердцу. Он пишет код в Vim, проигрывает MUD в gnome-терминал и, естественно, считает, что хорошо сконфигурированный текстовый интерфейс превосходит свой графический эквивалент в любой день недели.
Если вы работаете над чем-то связанным с сетью, практически невозможно пропустить вторжение Drupal в последние несколько лет. Drupal — это основанная на PHP платформа с открытым исходным кодом, созданная тысячами увлеченных разработчиков со всего мира. Известная как Система управления контентом (CMS), Drupal выделяется при создании веб-сайтов, блогов и интранетов. Но это также может быть использовано для гораздо большего. Сегодня Drupal обслуживает 2% всех сайтов в мире , включая некоторые крупные инсталляции, такие как The Economist , MTV и Белый Дом .
Популярный слоган в Drupal-land: «Приходите за программным обеспечением, оставайтесь для сообщества». Это говорит о том, насколько обширным является сообщество. Drupal.org имеет более 648 000 учетных записей пользователей и 10 000 учетных записей разработчиков. И по состоянию на март 2012 года насчитывается более 15 648 дополнений, предоставленных сообществом (модулей взносов), которые доступны для настройки поведения и внешнего вида Dupal, добавления новых функций или изменения и расширения его основных возможностей. Последний DrupalCon в Денвере собрал более 3000 посетителей .
Обучение развитию в Drupal имеет крутой кривой обучения. Я полагаю, что это потому, что он работает совсем не так, как другие системы. Хотя это может быть проблематично для опытного разработчика, существует множество ресурсов, из которых можно извлечь уроки. И я надеюсь, что этот пост даст вам с высоты птичьего полета на многие части Drupal и на то, как они все собираются вместе, чтобы создать одну из величайших веб-систем.
Вклад: Строительные блоки для разработки Drupal
Обычно с расширяемыми системами с открытым исходным кодом у вас есть сообщество, предоставляющее «сторонние» плагины или расширения. В Drupal они называются модулями, а те, которые не поставляются с базовой установкой Drupal, называются модулями вклада (contrib-модулями).
Но вот очень важное различие, которое нужно сделать. Модули Contrib не отделены от Drupal так же, как они используются в других сообществах. Вместо этого это область, где разрабатываются новые идеи и обрабатываются особые варианты использования. Это жизненно важная часть экосистемы — для каждой новой основной версии Drupal некоторые модули contrib подвергаются рефакторингу и становятся частью ядра.
Если вы установите ядро Drupal как есть, вы сможете создавать контент и управлять им до некоторой степени. Но давайте будем честными, вы бы создали довольно дерьмовый сайт. Вместо этого вам следует использовать как модули ядра, так и модули contrib в качестве строительных блоков вашего сайта. Выбрав их, вы сможете создать именно тот сайт и функциональность, которые вам нужны.
Многие в сообществе называют Drupal Framework управления контентом вместо CMS. Это описание лучше отражает, как вам на самом деле нужно создавать CMS самостоятельно, и как Drupal представляет собой набор Legos, который вы можете использовать для этого. Но, как скажет вам любой десятилетний ребенок, вам нужно знать, какие детали вам нужны, прежде чем вы сможете построить потрясающий космический корабль.
Сущности и поля
По определению, CMS — это все о контенте. В Drupal ваш контент упакован в сущности разных типов , от пользователей и комментариев до узлов и таксономий. Это абстрактные типы данных, представляющие одну часть содержимого.
Из ядра Drupal у вас есть пара модулей, таких как user.module и node.module, которые интегрируются с Entity API для предоставления своих собственных типов. Этот API позволяет любому легко создавать пользовательские типы сущностей для особых крайних случаев, используя ловушку info () . Подробнее об этом позже.
По умолчанию ваши сущности могут автоматически извлекаться из хранилища с помощью entity_load () . Однако, если вы также установите сущность . модуль , тогда все сущности также получают полный программный интерфейс CRUD для создания, извлечения, обновления и удаления экземпляров данного типа.
Тип сущности узла является для большинства сайтов центральным типом — это то, что редакторы обычно создают ежедневно. Узлы разбиты в пучках — тип шаблона данных для содержимого. Это могут быть что угодно: статьи, страницы часто задаваемых вопросов, интервью, эпизоды подкастов и т. Д. Все зависит от вашего уникального сайта.
Сущности сами по себе — просто голые, скучные объекты. Чтобы сохранить какие-либо значимые данные в связке сущностей, вы можете добавить в нее поля . Например, для статьи могут потребоваться изображение заголовка и основной текст, а пользователю может потребоваться имя и адрес веб-сайта.
Поля являются примерами работы модулей contrib. Они были введены еще в Drupal 5 модулем CCK. Сообщество имело такой успех, что модуль был быстро адаптирован и сохранен в Drupal 6. Затем он интегрировался в ядро для Drupal 7 с полевым API .
Это работает так, что модули определяют типы полей , например поле изображения, которое затем можно прикрепить к пакету и назвать «заголовочным изображением» для статьи. Когда вы затем создадите статью, будет создано поле для хранения этой действительно крутой картинки с кошкой.
Другие типы полей включают ссылки, адрес электронной почты, географические данные и т. Д. Конечно, вы также можете добавить свое собственное, если обнаружите, что множество модулей contrib не может удовлетворить ваши конкретные потребности.
Представления для списков
Теперь, когда у вас есть отсортированные объекты, вы, естественно, захотите перечислить их и другие данные — будь то список статей на первой странице, список «кто в сети» или облако тегов. Это делается спомощью подключаемого модуля генератора списков Views .
Грубо говоря, представления работают в два этапа. Сначала он берет вашу конфигурацию и строит из нее запрос, который отправляется на сервер. Ваш бэкэнд обычно является базой данных MySQL, но он также может быть веб-службой, файлом XML, FTP-сервером и т. Д. Представления не заботятся — они подключаемые, помните? Во-вторых, он получает результат запроса и преобразует его в список в вашем предпочтительном формате, начиная от ваших обычных HTML <ul> списков и заканчивая JSON и RSS .
Как и в большинстве случаев в Drupal, вы будете создавать свои представления с помощью веб-интерфейса. Но что больше всего интересует нас как разработчиков, так это то, что происходит за кулисами. В случае представлений вы будете в основном настраивать объект представления, состоящий из обработчиков для фильтров, полей и сортировки, стилей для его вывода и различных конфигураций.
Обработчик Views — это, по сути, класс, который может запросить у пользователя конфигурацию, а затем помочь построить запрос. Существуют обработчики полей, которые добавляют данные к тому, что возвращает запрос, обработчики сортировки для управления упорядочением результатов, обработчики отношений, которые извлекают дополнительные данные в связанные таблицы, обработчики фильтров, которые сортируют результаты, чтобы выбрать только определенные, и так далее.
Модули, содержащие новый тип поля сущностей, также часто содержат плагины Views для фильтрации по этим полям, стили для форматирования полей и так далее. Эта модульность означает, что когда у вас есть крайний случай, который не охватывается плагинами по умолчанию, вы можете легко подключиться к представлениям и расширять их любым удобным для вас способом.
В противоположность большинству всего остального в Drupal, Views очень сильно влияют на ориентацию объекта. Ваши представления — это объекты, а их обработчики, стили и плагины — объекты. Все связаны друг с другом с помощью хуков (см. Ниже), которые объясняют структуру данных их отдельного модуля, отношение к другим данным и куда вводить различные объекты для выполнения своей работы.
Как всегда, взаимодействия с базами данных, скорее всего, будут самыми большими узкими местами в ваших приложениях, и из-за этого в Views есть встроенная поддержка кэширования. Он работает в два слоя, где вы можете кешировать необработанные результаты сгенерированного запроса и вывод его тем индивидуально. Конечно, кеширование также является подключаемым, поэтому вы можете расширять и изменять логику, если вас не устраивают параметры по умолчанию.
На
следующей неделе я углублюсь в эти темы.
Экспорт с функциями
Все в Drupal построено через веб-интерфейс. Или, скорее, так как одна из распространенных ошибок для многих новичков — это начать копаться в коде и программировать все свои функции самостоятельно. Это большое нет-нет и идет вразрез спарадигмойDrupal Way. Это подход построения с существующими блоками, где это возможно, чтобы использовать всю работу, которую другие уже сделали и будут продолжать делать в будущем.
Но как вы отправите его, если все, что вы строите, настроено в базе данных? В частности — как вы будете отправлять постоянные обновления на уже развернутый сайт? И нет, строительство на производстве никогда не бывает возможным.
Ответ — это Feature, еще один модуль contrib, который позволяет вам экспортировать конфигурацию базы данных, проводить различие между экспортом и базой данных и сбрасывать конфигурации базы данных в пользу ваших экспортов. Вместе это дает вам все инструменты, необходимые для работы Drupal Way, с простым интерфейсом «укажи и щелкни», сохраняя при этом все преимущества наличия вашего сайта в коде.
Вам также больше не нужно делать тяжелые запросы к базе данных, чтобы собрать вашу конфигурацию, потому что вместо этого они могут быть прочитаны из файла. Конечно, дисковый ввод / вывод также медленный, но с кэш-памятью операций , такой как APC, это уже не аргумент. Вы ведь не используете PHP без кеша кода операции?
Я хотел бы думать, что Features превращает Drupal в одну гигантскую машину для строительных лесов . Определенно в хорошем смысле!
Расширение Drupal
Так что не стоит просто погружаться головой в программирование Drupal. Хотя в некоторых случаях у вас нет другого выбора, кроме как сделать это. Несмотря на мой определенный уклон в сторону Drupal, я, честно говоря, думаю, что для проектов, в которых много таких случаев, вы должны внимательно и внимательно изучить требования и, возможно, рассмотреть другие платформы, на которые можно опираться.
Если вы по-прежнему чувствуете, что Drupal — хороший выбор, тогда вы наверняка охвачены возможностями расширения. Помимо того, что платформа представляет собой набор блоков для сборки, она также имеет хорошую базовую структуру с несколькими точками расширения для пользовательского кода.
В большинстве случаев это означает ловушки — функции обратного вызова, названные в определенном формате. Он основан на магии подстановки строк и множестве вызовов function_exists () . На мой взгляд, это один из самых темных уголков Drupalverse, но, с другой стороны, новичкам очень легко перейти прямо в разработку Drupal.
Чтобы понять, как эти хуки работают на практике, скажем, например, что вы создаете модуль с именем newrelic . В нем вы хотите запускать фрагмент кода для каждого входящего запроса, и для этого вы решаете реализовать hook_boot () . Итак, вы открываете свой файл newrelic.module (базовый PHP-скрипт модуля) и вводите следующее:
<?php
function newrelic_boot() {
echo ‘Hello world!’;
}
И это все — теперь вы расширили Drupal для печати «Hello world!» на каждой странице! Возможно, не самое полезное расширение, но все же, вы поймете смысл.
Полный список всех хуков в ядре Drupal можно найти на api.drupal.org . Также см. Example.module , который представляет собой набор примеров и рекомендаций о том, как вы можете расширить Drupal с помощью своих пользовательских модулей.
Если вы пришли из объектно-ориентированного мира, вы можете запутаться из-за модели данных в Drupal, где основная структура — это произвольный массив. Это делает невозможным кодирование по контракту, и ваш код будет состоять из множества вызовов empty () и isset (), просто для проверки целостности данных. Эта архитектура спагетти была забавно подчеркнута недавней апрельской шуткой.
Но у него есть свои преимущества, особенно когда речь идет о том, насколько просто переопределить основные и дополнительные модули. Скажем, например, что вы хотите перейти на страницу входа в Drupal и заменить ее своей. Затем вы сначала посмотрите, как user.module определяет страницу в своей реализации hook_menu () .
function user_menu() {
return array(
‘user/login’ => array(
‘title’ => ‘Login’,
‘page callback’ => ‘user_page’,
),
);
}
Здесь говорится, что когда кто-то посещает example.com/user/login , будет выполнен обратный вызов user_page () . Если мы хотим заменить это нашим собственным обратным вызовом, нам нужно реализовать hook_menu_alter () .
function newrelic_menu_alter(&$items) {
$items[‘user/login’][‘page callback’] = ‘newrelic_page’;
}
И вдруг, все посещения example.com/user/login приведут к вызову newrelic_page () . Смертельно просто! Этот шаблон hook_x () -> hook_x_alter () очень распространен в Drupal.
Преждевременная оптимизация — это зло.
Drupal — платформа очень общего назначения. Из-за этого было необходимо ввести несколько уровней абстракции, чтобы он соответствовал как можно большему числу вариантов использования. Конечно, во многих случаях это также означает серьезное снижение производительности.
Я согласен с критикой, что Drupal может быть очень медленным. Но я также твердо верю, что вы ничего не можете исправить, и Drupal даже делает это относительно легкой задачей. Как повысить производительность — тема для другой статьи. Лучшее, что вы можете сделать, — это помнить, что преждевременная оптимизация является злом, и вместо этого вам следует сосредоточиться на узких местах позже, когда и если действительно возникнет проблема.
До тех пор — познакомьтесь с вашими строительными блоками и продолжайте создавать леса на своем сайте!