Как написать модуль для Друпала?

Введение в модули Друпала

Как говорят сами разработчики:

Когда мы разрабатывали Друпал, стало ясно, что мы хотим иметь систему настолько модульную, насколько это вообще возможно. Модульное построение позволит обеспечить гибкость, адаптивность и непрерывность, что в свою очередь, позволит людям дорабатывать свои сайты под свои нужды и предпочтения.

Модуль Друпала просто представляет собой файл, содержащий набор процедур, написанных на PHP. Когда он используется, код модуля выполняется непосредственно в контексте сайта. Таким образом он может использовать все функции и все переменные и структуры данных основного ядра. Фактически, модуль сколько-нибудь не отличается от обычного PHP-файла: это больше идея, которая автоматически ведёт к хорошим архитектурным принципам и хорошей модели разработки. Модульность лучше всего сочетается с моделью разработки систем с открытыми исходными кодами, потому что иначе будет трудно представить как люди, работающие параллельно, не будут влиять друг на друга.

Идея заключается в том, чтобы иметь возможность запускать произвольный код в заданных местах движка. Этот произвольный код должен иметь возможность сделать то, что нужно для расширения функциональности. Места, где код должен быть выполнен, называются "хуками" (англ. "hook") и они жёстко определены и зафиксированы.

В тех местах, где доступны хуки, движок вызывает код каждого модуля, которые используют данный хук. Это сделано путём просмотра всей директории, где находятся модули. Скажем, ваш модуль называется foo (т.е. расположен в modules/foo.module) и если в нём есть хук под названием bar, движок вызовет функцию foo_bar(), если она присутствует в вашем модуле.

Таким образом, хуки позволяют модулю взаимодействовать с ядром Друпала. Система модулей Друпала основана на концепции хуков. Хук - это php-функция с названием (например) foo_bar(). Здесь foo - имя модуля (значит, полное имя модуля - foo.module), а bar - имя хука. Каждый хук имеет определённый набор параметров и определённый тип возвращаемой переменной. Для расширения возможностей Друпала модуль всего лишь должен предоставлять хуки. Когда Друпалу требуется функциональность модуля, движок определяет, какие модули предоставляют хуки, соответствующие данной ситуации. Найденные хуки вызываются во всех модулях, которые соответствующие хуки предоставили.

Урок "Создание модуля". Друпал 5.х

(оригинал в англ. версии находится здесь.)

Этот урок рассказывает, как создать модуль для Друпал версии 5. Это дополнение к уроку для Друпал версии 4.6. Вы можете уточнять различные детали там. Большинство в этом уроке верно и для Друпал версии 4.7, но всё же вы должны проверить документацию по API-функциям, также как и документацию "как обновить свои модули от одной версии Друпала к другой".

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

Этот урок не предназначен для того, чтобы подготовить вас писать модули, предназначенные для релиза. Этот урок не освещает ни кеширование, ни рассматривает подробно управление доступом или проблемы безопасности. Используйте этот урок в качестве начала, и смотрите другие модули, Настольную книгу Друпала и Стандарты Кода для более детальной информации.

Этот урок требует от вас:

• Базового знания PHP, включая синтаксис и концепцию объектов в PHP
• Базового понимания таблиц баз данных, их полей, записей и синтаксиса языка SQL
• Работающий экземпляр Друпала
• Доступ к Друпалу с правами администратора
• Доступ к веб-серверу

Этот урок не требует от вас какого-либо представления о внутренней работе модуля Друпала. Этот урок не научит вас писать модули для более ранних версий, чем Друпал 4.5.

<?php
/* $Id$ */

; $Id$
name = Module Name
description = "A description of what your module does."

; $Id$
name = On this date
description = "A block module that lists links to content such as blog entries or forum discussions that were created one week ago."

dependencies = module1 module2 module3
package = "Ваша произвольная строка символов для группировки"

function onthisdate_help($section='') {
 
}

/**
* Display help and module information
* @param section which section of the site we're displaying help
* @return help text for section
*/
function onthisdate_help($section='') {
 
  $output = '';
 
  switch ($section) {
    case "admin/help#onthisdate":
      $output = '<p>'.  t("Displays links to nodes created on this date"). '</p>';
      break;
  }
 
  return $output;
} // function onthisdate_help

Модули Друпала: Image

Модуль Image (англ. "Изображение") - общее описание. (Оригинал статьи на странице проекта Image)

Этот модуль позволяет пользователям с надлежащими правами загрузку изображений в Drupal. Миниатюры и картинки дополнительных размеров создаются автоматически.

Изображения могут быть размещены отдельно на главную страницу, могут быть включены в статьи или сгруппированы в галереи.

Модуль Image (начиная с 5.x версии) поставляется с несколькими дополнительными модулями:

• image_gallery.module : используя термины таксономии, организует и отображает ваши загруженные фотографии в виде галерей
• image_attach.module : позволяет легко присоединять тип нод "изображения" к другим видам контента (другим нодам). (несколько слов чтобы разъяснить ситуацию. Модуль Image создаёт отдельный тип контента (ноду) под названием Image ("Изображение"). Модуль image_attach.module позволяет легко присоединять этот тип контента к любым другим.)
• image_im_advanced.module : добавляет расширенные опции обработки изображений ImageMagick, например, такие как наведение резкости к набору графических инструментальных средств ImageMagick.
• image_import.module: упрощение добавления нескольких изображений путем импорта изображений из каталога на сервере.

Модуль Image: ноды типа Image ("Изображение"), присоединённые изображения и галереи изображений. (Оригинал статьи здесь.)

Модуль Image используется для создания и управления изображениями на вашем сайте. Каждое изображение хранится в виде ноды, вместе с автоматически сгенерированными ограниченными производными изображениями от первоначального изображения.

Есть два используемых по умолчанию производных размеров, "Thumbnail (эскиз, миниатюра)" и "Preview (предварительный просмотр)". Миниатюра показывается в тизере для нод типа Image и при просмотре галерей изображений. Изображение размером предварительного просмотра показывается при первом отображении ноды типа Image. Размеры могут быть изменены, а также могут быть определены множество других производных размеров.

Нижеследующие модули в связке с модулем Image позволяют делать больше вещей с вашими изображениями:

• Модуль "Image gallery" (Фотогалерея) позволяет организовывать и отображать картинки в галереях. Вкладка "List" позволяет пользователям редактировать у существующих фотогалерей названия, описания, родительские галереи, и относительное положение, известное как вес. Вкладка "add galleries" позволяет создать новую галерею изображений, определить название, описание, родителя и вес галереи.
• Модуль "Image attach" позволяет изображениям быть присоединёнными к другим нодам: страницам, статьям, или другим пользовательским типам контента. Вы можете указать, какие производные размеры будут отображаться как в тизере, так и при полном просмотре документа, а также вес изображения относительно содержания ноды. Прилагаемое изображение ссылается на ноду с изображением в настоящем размере, позволяя читателям увидеть изображение в полный размер. Поддержка для модуля Views включена.
• Модуль "Image import" позволяет массовый импорт изображений из каталога на вашем веб-сервере.

Вы можете:

• видеть сообщения о работе с изображениями в administer >> settings (управление >> настройки).
• видеть списки и добавлять галереи изображений в administer >> image (управление >> изображения).
• настраивать размеры изображений и файловые директории в administer >> settings >> image (управление >> настройки >> изображение).
• использовать модуль "Image assist" для загрузки и вставки изображений в посты.
• просмотреть справку, прочитать об известных ошибках, и скачать последнюю версию на странице проекта Image.

Модули Друпала: CCK

Модуль CCK (The Content Construction Kit, переводится как Набор для Конструирования типов Контента, в Друпале документы называются ноды (node), содержание нод и есть контент, можно сказать, что термины эти равнозначны, особенно в рамках этой статьи) позволяет вам создавать и править под свои нужды различные поля нод, используя веб-браузер. Версия модуля CCK для Друпала ветки 4.7х позволяет создавать пользовательские типы нод и добавлять к ним различные поля. В Друпале ветки 5.х пользовательский тип нод может быть создан стандартными функциями Друпала (находящимися в ядре, core-функции), и CCK позволяет добавлять различные поля к любому типу нод.

Важно: релиз безопасности 1.6
Модуль CCK 1.6 для веток 4.7х и 5х исправляет две уязвимости, позволяющие межсайтовое исполнение скриптов (XSS, Cross Site Scripting) в nodereference.module.
Все сайты, использующие CCK / nodereference.module должны принять это во внимание и обновиться до данного релиза как можно быстрее.

Извещение безопасности: DRUPAL-SA-2007-019

-------------------------------

Убедитесь, что вы посетили update.php после обновления до новой версии.

Совместимость с модулем Views:

• CCK теперь проектируется для работы с Views версии 1.6 (или выше).
• Из-за изменения некоторых API-функций в последнем релизе Views, CCK v1.4 вызывает сообщения об ошибке при работе с Views 1.6 (http://drupal.org/node/134812). Пожалуйста, обновитесь до последнего релиза CCK, если Вы используете Views 1.6.

Вкратце:
CCK 1.4 <--> Views 1.5
CCK 1.5+ <--> Views 1.6

Внимание: CCK-HEAD содержит находящийся в разработке, экспериментальный и нестабильный код для Друпал 6. Совершенно не готов к использованию, и несовместим с Друпал 4.7 или 5. Вместо него используйте релизы CCK для веток Друпала 4.7.x или 5.x.

-------------------------------

Неколько сотрудничающих проектов предоставляют дополнительные типы полей и виджеты для модуля CCK:

• вычисляемые поля: позволят вам добавлять управляемые PHP "вычиляемые поля" для типов контента CCK
• дата: создаёт поле для даты в формате ISO или unix timestamp
• <a href="http://drupal.org/project/email" title="email module" rel="nofollow">электропочта: проверяемое поле для электронной почты
• Поле для хранения изображений
• ссылка: поле для хранения URL

Эти модули имеют отношение к CCK:

• content template, contemplate: позволяет вам управлять формами и видимостью их различных полей, в том числе тизерами и RSS-потоками
• Модуль Views: предоставляет множество возможностей просмотра контента; CCK предоставляет свои поля для подсистемы модуля Views.

Список модулей для CCK продолжает расти. Полный список зависимых от CCK модулей смотрите в разделе загрузок.

Источник: модуль CCK

$terms = taxonomy_get_tree(1); //$terms will be an array of objects representing taxonomy terms
 
foreach($terms as $term) {
$term_names[] = $term->name; //$term_names will be an array consisting of the name of each taxonomy term
}
 
return $term_names;

function form_weight_form_alter($form_id, &$form) {
  if($form_id == "YOUR_FORM_ID") {
    $form['title']['#weight'] = -10;
  }
}

Модули Друпала: BUEditor

Простой текстовый редактор, предназначенный для облегчения написания кода (вероятно автором BUEditor'а имеется в виду HTML-код).

• Интерфейс редактора и функциональность кнопок полностью настраивается в административной зоне.
• Интерфейс редактора можно настроить отдельно для каждой роли пользователей.
• Возможно создавать графические или текстовые кнопки.
• Кнопки можно настроить для получения фрагментов кода, вставки HTML-тегов, вставки bbcode-тегов и т.д.

Редактор поставляется в конфигурации "default editor" ("редактор по умолчанию"), в которой есть предопределённый заранее набор кнопок. По умолчанию кнопки такие:

1. Insert/edit image (вставить/редактировать изображение): Вставляет HTML-код, необходимый для отображения изображения. Может использовать javascript API модуля IMCE для просмотра файлов, если этот модуль установлен. Возможно редактирование ранее вставленного изображения, если выделенный HTML-код изображения выделен без лишних символов.
2. Insert/edit link (вставить/редактировать ссылку): Вставляет HTML-код, необходимый для отображения ссылки. Это работает так же, как графические вставки.
3. Bold (жирный шрифт): Обрамляет выделенный текст тегом (в HTML этот тег формирует жирный текст).
4. Italic (наклонный шрифт, курсив): Обрамляет выделенный текст тегом (в HTML этот тег формирует курсив).
5. Ordered list (пронумерованный список): Преобразует строки выделенного текста в нумерованный список. Кроме того, можно начать новый список, не выборая никакого текста. Если выбранная область текста является списком, который ранее был создан при помощи этой кнопки, строки текста восстанавливаются в исходное состояние.
6. Unordered list (ненумерованный список): Создаёт маркированный список.
7. Teaser break (разделитель анонсов): Вставляет друпаловский разделитель анонса: <!--break-->
8. Preview (предварительный просмотр): Позволяет осуществить предварительный просмотр выбранного фрагмента текста, или весь текст, если ничего не выбрано. Строки и параграфы формируются автоматически, как это обычно происходит при предварительном просмотре средствами самого Drupal.
9. Help (Справка): Отображает название (а также подсказку или совет) для каждой кнопки редактора.

Источник: BUEditor

if (user_access('access foo')) {
  return 'js: alert("You have the permission to access foo")';
}

Модули Drupal: Code Filter

Это очень простой модуль - фильтр сообщений. Он перехватывает теги ... и </code> ... <code>, внутри которых пользователь может писать код, не задумываясь о том, чтобы экранировать спецсимволы. Кроме того, внутри тега </code> ... <code> Code Filter самостоятельно расцвечивает код.

Примеры использования

Пример использования тега </code> ... <code>

//this is an example of php-code
echo "Hello world!";

Пример использования тега ...


//this is an example of php-code
echo "Hello world!";


Установка

1. Скопируйте папку модуля codefilter в каталог, где у вас хранятся модули Drupal (по умолчанию - sites/all/modules/), таким образом все файлы будут храниться в каталоге sites/all/modules/codefilter.
2. Включите Code Filter на странице управления модулями (admin/build/modules)
3. Перейдите на страницу управления фильтрами ввода (admin/settings/filters). Нажмите кнопку "настройки" того фильтра ввода, для которого вы хотите включить Code Filter, и проставьте флажок напротив фильтра Code Filter на появившейся странице.
4. (по желанию) Перейдите на страницу управления порядком применения фильтров к выбранному формату ввода и измените порядок применения фильтров для урегулирования конфликтов (если они есть).
5. (по желанию) Измените вашу тему оформления, чтобы предоставить стиль div.codeblock для блоков в теге ... .

Автор модуля: John Albin

Источник: Code Filter

Модули Drupal: Flag

Модуль Flag представляет собой гибкую, полностью настраиваемую администратором систему для создания меток (флажков). Используя этот модуль, администратор сайта может представить любое количество флагов для документов (нод), комментариев, или пользователей. Некоторые применения включают реализацию закладок, пометки "важно", пометку "друзья", или флажок "оскорбительное". Благодаря обширной интеграцией с модулем Views, вы можете создавать собственные списки популярных материалов или хранить закладки на важных документах.

Флаги могут быть использованы пользователями независимо, а это означает, что каждый пользователь может пометить пункт индивидуально, или глобально, что означает, что этот пункт является либо помеченым, либо нет, и любой пользователь, изменяя пометку, изменяет ее для всех.

Таким образом, дополнительные флаги (по аналогии со стандартными флажками "Опубликовано" и "Прикреплено") могут быть поставлены на документах или других вещах, а также обрабатываться в системе так, как нравится администрации.

Этот модуль был ранее известен как Views Bookmark.

Возможности

• Создание неограниченного количества произвольных флагов или закладок для пометки контента
• Хорошая интеграция с модулем Views, позволяющая создавать списки наиболее популярных помеченных материалов
• Полная поддержка модуля Token во всех сообщениях и подписях
• Выполняет действие (модуль Actions), когда число пометок материала превышает определенный порог (Модуль Actions в настоящее время включен в ядро Drupal 6, дополнительные модули не требуются)
• Переключение флагов сделано на JavaScript
• Ограничивает отображение флагов в зависимости от типа содержания и роли
• Опционально: может показывать каждый флаг как переключаемый флажок (checkbox) на форме ноды

Каждый флаг предоставляет данные модулю Views, и по умолчанию создает вид для создания списка "Мои закладки". виды по умолчанию мнений являются основными, но легко учитывать, что системный администратор хотел их сделать.

Модуль установится вместе с простыми закладками, и двумя видами для примера, оба представляют собой отдельные страницы 'Мои закладки', а также страницу-вкладку для каждого пользователя, выполненную в виде вкладки над профилем пользователя, с адресом user/x/bookmarks

Рекомендуемые Flag-проекты

• Виды (также переводится как "Представления", он же "Views"): Создание списков помеченных материалов.
• Flag Weights: Добавляет веса для пометок, чтобы сделать пункты сортируемыми.
• Flag Friend: Встроенный флаг, для пометки других пользователей как друзей.
• Flag Abuse: Встроенный флаг для маркировки оскорбительного содержания, а также некоторые административные функции.

Обновление с модуля Views Bookmark

Этот модуль является портом модуля Views Bookmark. Список изменений в API, и инструкции по обновлению можно найти на странице руководства по обновлению модуля Views Bookmark до модуля Flag.

Авторы: Эрл Майлз, Nate Хауг и Mooffie.

Источник: Flag module

ВАЖНО: При обновлении модуля, как до нового официального релиза, или до нового 'Dev'-релиза, не забудьте посетить update.php. И если 'update.php' не предлагает никаких "обновлений", Вы должны очистить кэш Drupal.

Модули Drupal: Google Analytics

Добавляет систему веб-статистики Google Analytics на Ваш веб-сайт.

Этот модуль позволяет добавить следующие возможности учёта статистики сайта:

• Избирательно отслеживать определённые пользовательские роли
• Мониторить, какие файлы скачиваются с Ваших страниц
• Кэшировать код Google Analytics на Вашем локальном сервере для повышения скорости загрузки страниц
• Отслеживать сегментацию пользователей на основе данных их Drupal-профилей
• Поддержка поиска по сайту
• Поддержка Urchin и нового GA

Разработано Ixis.

Источник: Google Analytics

Модули Drupal: Google Custom Search Engine

Система пользовательского поиска (СПП) Google является встроенным поисковым движком, который может быть использован для поиска любого набора из одного или нескольких сайтов. Никаких API-ключей от Google не требуется. Подробнее смотрите тут.

После установки этого модуля, настройте его, указав алфавитно-цифровой идентификатор для Вашей СПП от Google. В противном случае Вы увидите стандартное окно поиска Google на Вашем сайте. После того как Вы разрешили одной или нескольким ролям пользователей искать через СПП Google, страницу поиска можно найти по адресу search/google; также предоставляется блок СПП Google.

Из-за того, что Google и Drupal оба используют переменную "q" в адресной строке, этот модуль требует, чтобы чистые URL (ЧПУ) были включены.

Разработка спонсирована TechSoup Global.

Источник: Google Custom Search Engine

Модули Drupal: Hidden Content

Этот модуль позволяет просматривать разные части документов только для заданной роли или пользователя. Подробные инструкции использования могут быть найдены в разделе /filter/tips на странице документа, для которого этот модуль включён.

От меня: модуль весьма полезен и позволяет скрыть текст от анонимусов, а следовательно, и от поисковых систем. Он становится видным только при регистрации пользователя, или присвоении ему роли, для которой разрешён просмотр скрытого текста. Подобная функция является очень удобной для администраторов, и раздражающей для случайных посетителей, ведь чтобы прочесть текст, им нужно регистрироваться. Но с другой стороны, если вы размещаете ссылку или информацию строго для определённых людей, этот модуль незаменим. Такие популярные движки, как DLE и vBulletin давно имеют подобный функционал.

Источник: Hidden Content

Модули Drupal: IMCE и IMCE Gallery

Узнал я об этих модулях из отличной статьи SadhooKlay.

Поставил себе на блог, на этот сайт, вместе со всеми исправлениями, что были замечены в вышеупомянутой статье. Пример можно посмотреть здесь: http://andyceo.ruware.com/user/1/imce_gallery/1 Вроде пока доволен...

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

Проблема заключается в том, что модуль IMCE создает для каждого пользователя подпапку вида u1, в папке сайта, предназначенной для хранения файлов. Т.е. если у меня 4 сайта, и для каждого создана своя директория файлов, у меня в каждой из этих директорий создается директория для галереи пользователя. Получается не очень хорошо... Галерея, созданная на одном сайте, пользователю нужна на другом, но все файлы, которые пользователь закачал в галерею на "родном сайте", не видны на всех остальных, т.к. в базе данных хранится только имя закаченного файла - IMCE Gallery пытается найти файлы в файловой директории "неродного" сайта, обламывается, и показывает пустую картинку. Не очень хорошо...

Возможные решения мне видятся в следующем:

1. Научить IMCE и IMCE Gallery сохранять изображения в прозвольной папке, а не только в папке файлов сайта
2. Сделать общую директорию файлов для всех сайтов в мультисайтовой связке
3. Переделать IMCE Gallery так, чтобы он в БД хранил полный путь к файлу, тогда из "неродных" сайтов будут видны изображения, сделанные на "родном" сайте

Хочу спросить многоуважаемых посетителей, какой из вариантов лучше всего реализовать, с целью увеличения функциональности IMCE и IMCE Gallery и сохранения концепции мультисайтинга.

Модули Drupal: Image watermark

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

Водяной знак представляет собой графический файл в формате PNG (24 бит) с альфа-каналом, но и другие форматы могут работать.

Возможности:

• Путь до водяного знака настраивается.
• Местоположение водяного знака может быть одним из девяти позиций (любая комбинация из верха, центра, внизу и слева, справа и в центре).
• Можно выбрать, к каким изображениям применять водяной знак (например, предпросмотр и оригинальный (англ. preview, _original) размер, но не миниатюра (англ. thumbnail)).

Новые возможности: (!)

• Сохраняет формат исходного изображения после того, как водяной знак был проставлен
• Поддержка альфа-смешивания
• Накладывает водяной знак лишь тогда, когда загружается новое изображение, не накладывает водяной знак дважды!
• Также накладывает водяной знак на превью-картинку (англ. previews)
• Водяной знак можно масштабировать, может быть установлен процент от ширины изображения и минимальная ширина в пикселях.
• Переключение: Исключает от накладывания водяного знака изображения с конкретными терминами галереи (требуется модуль Image gallery)

Известные ограничения:

• Изменение параметров водяного знака не работает на уже наложенные изображения, новые настройки распространяются только на новые изображения.
• Сохранение настроек модуля Image "сбрасывает" настройки модуля Image watermark, даже если вы ничего не изменили. Это означает, что водяные знаки исчезнут или распространяться на все размеры изображений, когда документ с изображением или галерея просматривается.

Требования

Этот модуль не требует никаких патчей ни к Drupal, ни модулю Image.

Модуль требует графическую библиотеку GD для PHP, сконфигурированную на хостинге.

GD включена по умолчанию в PHP 4.3 и более поздние, и может быть добавлена в предыдущие версии PHP, если PHP компилируется вместе с ней. Для получения более подробной информации см. http://php.net/image

Этот модуль был протестирован с PHP 4.4.0 и PHP 5.1.2, но должен работать и с другими версиями PHP, в которых есть GD.

Использование

Распакуйте каталог модуля Image watermark вместе с подкаталогами и файлами в вашу директорию с модулями. Включить модуль на странице admin/build/modules странице. Затем перейдите на страницу admin/settings/image_watermark, чтобы включить наложение водяных знаков на вновь загружаемые изображения.

Автор

Khalid Baheyeldin из 2bits.com.

Вы можете обратиться к автору за платными услугами по настройке этого модуля, а также по Drupal-консалтингу, внедрению, установке, развитию и настройке Drupal.

Новые возможности были разработаны schnizZzla для BerlinerStrassen.com.

Функция масштабирования начата и портирована на версию 4.7 michael'ом curry (inactivist) от exodusdev.com

Источник: Image watermark

Модули Drupal: ImageCache

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

Требования ImageCache 1.x:

• Поддержка "чистых URL" (ЧПУ)
• Публичный режим скачки файлов

ImageCache 2.0 Beta

Пожалуйста, потестируйте бета-версии ImageCache 2.x. ImageCache 2.x является полностью переписанным, в нём много новых функций и более ясное API. Теперь ImageCache 2.x зависит от модуля ImageAPI, в части обработки изображений.

Источник: ImageCache

print theme('imagecache', $preset, $image['filepath'], $alt, $title,  $attributes); 

print theme('imagecache', 'small', 'test.jpg', 'just a test image', 'test image'); 

Модули Drupal: ImageField

Модуль ImageField обеспечивает загрузку изображений для модуля CCK.

Возможности:

• интеграция с модулем Views
• поддержка одиночного и множественного значения
• ограничения по максимальным размерам изображения
• интеграция с модулем ImageCache

ImageField не предоставляет генерацию миниатюр или производных изображений, как это делает Image. Модуль Views может использовать модуль ImageCache для создания производных изображений от изображений, загруженных с помощью ImageField, но ImageCache может быть трудно настроить и это не очень хорошо задокументировано.

Замечания по совместимости:

• CCK - Убедитесь, что вы используете самую последнюю версию CCK.
• Image - ImageField не совместим с типом контента, предоставляемого модулем Image. Если добавить через модуль CCK поле типа imagefield в тип контента, представленного модулем Image, Image будет удалять все изображения модуля ImageField каждый раз, когда вы будете обновлять документ.

Предварительные релизы: (пожалуйста, потестируйте):

• ImageField 2.0 RC2
• ImageField 1.2 RC1

Вы просто должны проверить эти замечательные, связанные с модулем ImageField проекты:

• ImageCache - Генерация производных изображений для модуля ImageField.
• ImageField Crop - AJAX-примочка для модуля ImageField, предназначенная для обрезания изображений в процессе их загрузки на сайт.
• ImageField Gallery - Галлереи, сгенерированные на основе изображений, загруженных через ImageField.

Первоначальную разработку данного модуля поддерживали:

• Lullabot
• The New America Foundation

Источник: ImageField

Модули Drupal: Legal

Отображает Условия и Соглашения Вашего сайта (проще говоря, Правила сайта) для пользователей, которые хотят зарегистрироваться, и требует, чтобы они согласились с Правилами сайта до завершения регистрации.

Текст Правил сайта должен быть введён только администраторами или другими надёжными пользователями. Функция filter_xss_admin() используется чтобы отфильтровать контент для отображения, это очень хорошо настраиваемый XSS/HTML-фильтр, предназначенный только для использования администраторами.

Примечание: есть конфликт с модулем SecureSite - не используйте Legal и SecureSite на одном и том же сайте.

Обратная связь с автором:

• Сообщить об ошибке / запросить добавление функции
• Новые возможности
• Хотите сказать спасибо

Источник: Legal

Модули Drupal: Module Installer

Этот модуль позволяет загружать и устанавливать модули прямо из админки сайта. Т.е. Вам не понадобиться их сначала скачивать, распаковывать, устанавливать на хостинг... Всё делается автоматически.

Имейте ввиду, что это очень молодой модуль, и он пока не отлажен. Любая помощь в тестировании весьма приветствуется.

Сообщение от команды безопасности: Если ваш веб-сервер может писать в Ваши модули, это является серьёзным нарушением безопасности. Команда безопасности настоятельно рекомендует пользователям не устанавливать этот модуль.

Источник: Module Installer

Модули Drupal: Monthly Archive

Создаёт списки месячного архива документов и предоставляет подобные блоки.

Примечание: Вы должны настроить блок после включения модуля.

В версиях Drupal 4.6 и 4.7, удалите папку more_language, если только Вам не нужен испанский или китайский перевод, чтобы избежать конфликта.

Источник: Monthly Archive

Модули Drupal: Node Auto Term [NAT]

Модуль NAT является модулем-помощником, используемым для построения и поддержания связей типа документ-термин, то есть когда один документ создаётся, автоматически создаётся эквивалентный термин таксономии в любом связанном словаре. Этот модуль представляет собой простой, но эффективный способ создания связей типа документ-документ через модуль таксономии.

Тестирование, тематические запросы и патчи приветствуются :)

Первоначально спонсирован Моше Вейцманом.

Источник: Node Auto Term [NAT]

Модули Drupal: Notify

Модуль Notify позволяет пользователям подписываться на периодические письма, которые включают все новые или исправленные документы и/или комментарии, совсем как письма ежедневных новостей, которые рассылают некоторые веб-сайты. Даже если эта функция не настроена для обычных пользователей сайта, эта функция может быть полезной для администратора сайта, чтобы контролировать содержание новых материалов, и комментариев к постам.

Модуль Notify совместно разрабатывают beginner и RobRoy.

С точки зрения разработчиков, основные приоритеты при разработке перечислены здесь. Итак, если Вы заботитесь о некоторых новых функциях, вы, возможно, захотите посмотреть на это.

Источник: Notify

Модули Drupal: Organic groups

Разрешает пользователям создавать и управлять своими собственными "группами". Каждая группа может иметь подписчиков, и ведёт главную страницу группы, где подписчики общаются между собой. Они делают это путём публикации документов обычных типов: блог, история, страницы и т.д. Блок, показанный на главной странице группы, облегчает создание таких документов. В блоке также приводится краткая информация о группе.

Выборочные групп требуют утверждения, с тем чтобы стать её членом, или даже может быть только-по-приглашению группой. Есть много опций для настройки групп так, как вам нужно.

Группы получают свои собственные темы оформления, язык, таксономию, и так далее. Интегрируется хорошо, и зависит от модуля Views.

Разработчики - этот модуль работает с API нод тщательно. Вы можете ознакомиться с ним для справки.

Демо-сайты: http://groups.drupal.org, http://teamsugar.com/group/620221, http://www.mailfriends.com/og, http://www.mothersclick.com/groups

Источник: Organic groups

Модули Drupal: Scheduler

Этот модуль позволяет опубликовать, а также отменить публикацию документов в заданные даты. Если модуль JSCalendar включен (часть модуля-набора JSTools), всплывающий Javascript-календарь будет использоваться для того, чтобы выбрать дату и время публикации (отмены публикации) документов, в противном случае дата вводится в простом текстовом поле.

Примечание от меня: Этот модуль публикует материалы по расписанию только тогда, когда проходит ближайший по времени cron.php. Если cron.php вообще не настроен на вашем сайте, то этот модуль работать не будет.

В остальном же это достаточно удобный модуль. Уехал в отпуск - перед этим накопил статей, и завёл Планировщик. :) Удобно.

Также он позволяет задать время публикации. Т.е. если Вы хотите, чтобы Ваш документ опубликовался в 15:15, то время его создания будет изменено на это время. Однако фактически он опубликуется только тогда, когда выполнится ближайший cron.php после 15:15.

Источник: Scheduler

Модули Drupal: Simple Sitemap

Модуль Simple Sitemap представляет собой альтернативу модулю XML Sitemap и предназначен для генерации карты сайта в соответствии со спецификацями XML сайта Sitemaps.org. Разница между Simple Sitemap и XML Sitemap состоит в том, что Simple Sitemap спроектирован для очень больших Drupal-сайтов с большим количеством документов для индексации.

После установки Simple Sitemap подготовит карту сайта при следующем выполнении скрипта по расписанию (cron.php), вы можете задать через какой интервал времени это будет происходить, что уменьшит число загрузок при создании документа. Кроме того, без каких-либо изменений, Simple Sitemap будет производить XML только для ссылок, которые имеют псевдонимы (алиасы), таким образом модуль реализует два хука, которые позволяют другим модулям добавлять или изменять пункты в карте сайта.

Этот проект был построен ориентируясь на внутренние характеристики сайта New York Observer и теперь предоставляется сообществу, в надежде на то, что другие смогут извлечь из него пользу. Ниже перечень планируемых улучшений:

1. Реализация автоматической отсылки в поисковые системы.
2. Реализация конфигурируемого выбора пунктов, кроме псевдонимов URL.
3. Реализация автоматического взвешивания терминов (взвешивание документов осуществляется с использованием полного чтения документа).
4. Разрешить добавлять дополнительные URL'ы в админской зоне (в настоящее время это можно сделать только с помощью хука).
5. Осуществление контроля данных, вводимых в формы, на страницах администратора.
6. Реализовать XSLT.

Пожалуйста, имейте в виду: так как мы избрали скорость ценой определённой гибкости, сайты, которые получат пользу от использования Simple Sitemap вместо XML Sitemap, должны быть весьма крупными, например такими как New York Observer. Нужно понимать, что в своём нынешнем варианте модуля, вам придётся внедрить предоставленные хуки для указания дополнительного содержания. Мы настоятельно рекомендуем для небольших сайтов и сайтов без поддержки программистов и разработчиков продолжать использовать модуль XML Sitemap, так как он является стабильным, надёжным и легко настраивается.

Источник: Simple Sitemap

Модули Drupal: SimpleMenu

Данный модуль создаёт меню, которое отображается в верхней части каждой страницы. Полоса меню имеет фиксированное местоположение, и использует jQuery для позиционирования меню, а также обработки эффектов меню и добавления совместимости с браузером IE.

Очень полезно для тем оформления, которые не имеют удобного места для меню.

Источник: SimpleMenu

Модули Drupal: Site map

Этот модуль предоставляет карту сайта, что позволяет посетителям получить быстрое представление о вашем сайте. Он также может отображать RSS-ленты для всех блогов и категорий. Drupal автоматически генерирует RSS-ленты, но о некоторых, как кажется, следует знать точно, что они существуют.

Site map может отображать следующие пункты:

• Сообщение, которое будет показано выше карты сайта.
• Последние блоги.
• Все подшивки, которые могут отображаться полностью раскрытыми.
• Любые меню, которые будут отображаться полностью раскрытыми.
• Любые категории, то есть словари, со всеми терминами. При желании можно настроить показ числа документов и RSS-лент в данной категории.
• Предоставляет блок синдикации, с ссылкой "читать ещё", ведущей на карту сайта.

Источник: Site map

Модули Drupal: SpamSpan filter

Модуль SpamSpan скрывает адреса электронной почты, чтобы предотвратить их сбор различными спам-ботами. Он реализует способ, опубликованный на сайте SpamSpan (также доступна немецкая версия). Проблема большинства шифровщиков адресов электронной почты заключается в том, что они полагаются на включённый JavaScript на стороне клиента. Это делает метод недоступным для людей с читалками экрана. Модуль SpamSpan же даст кликабельные ссылки, если JavaScript включён, и будет показывать адрес электронной почты в формате example [at] example [dot] com в случае, если браузер не поддерживает JavaScript или если JavaScript отключен.

Источник: SpamSpan filter

Модули Drupal: Subscriptions

Этот модуль позволяет пользователям подписываться, чтобы узнавать об изменениях в документах или таксономии, таких, как новые комментарии в конкретных форумах, или добавление новых записей в некоторые категории блога. Когда модуль включён, все ноды будут иметь дополнительные ссылки, которые позволят пользователям менять свои подписки. Пользователи увидят вкладку на своём пользовательском экране, через которую смогут управлять своими подписками. Пользователь могут также установить автоматическую подписку, которая уведомит их, если кто-то комментирует посты, которые они внесли. Администраторы могут включить это по умолчанию.

Этот модуль был переписан с нуля в ноябре 2007 г. chx'ом с помощью salvis'а.

Официальная версия модуля Subscriptions по-прежнему 5.x-1.9. Она не поддерживается, и в ней известно несколько багов. Мы напряжённо работаем над версией 2.0, и вы можете помочь нам, опробовав 5.x-2.0-beta11-релиз и сообщив об ошибках.

От меня: Этот модуль НЕ РАССЫЛАЕТ уведомления о новых материалах на почту! Он просто позволяет подписаться на материал, а все уведомления об обновлениях вы сможете просмотреть в своём профиле, когда залогинитесь на сайт.

Источник: Subscriptions

Модули Drupal: Tagadelic

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

Tagadelic предлагает различные способы, чтобы добавлять термины и словари в одно облако тегов. С помощью ссылок, вы можете создавать свои собственные страницы с облаками тегов. Он также предлагает блок для каждого таксономического дерева.

Поскольку на готовые примеры смотреть веселее, чем на PHP-код или уродливые ASCIIart READMEs, мы хотим чтобы вы просто использовали Tagadelic. Пожалуйста, опубликуйте ваш пример в комментариях к этому проекту.

Мы проводим тестирование действительно красивой сторонней системы для сообщения нам ваших пожеланий, чего бы вы хотели видеть в модуле. Пожалуйста, используйте FeVote чтобы голосовать за какую-либо, или добавить свою желанную возможность, которую вы хотите видеть в Tagadelic.

Связанные модули:

• tagadelic_views: Модуль для связи с модулем Views

Источник: Tagadelic

$tagcloud = "";
drupal_set_html_head('<style type="text/css">@import url('.drupal_get_path('module','tagadelic').'/tagadelic.css);</style>');
$vocs= array(4,5,410); //  ids of vocabs for which you want to build a tag cloud
$tagcloud = theme('tagadelic_weighted',tagadelic_sort_tags(tagadelic_get_weighted_tags($vocs)));
print $tagcloud;

Модули Drupal: Taxonomy Access Control. Настраиваем форум в Drupal

Введение

Taxonomy Access Control (TAC) - это замечательный модуль, который позволит Вам разграничить доступ для пользователей к категориям, документам и разделам сайта на основе терминов таксономии (стандартный модуль Drupal Taxonomy). Если говорить точно в терминах Drupal, модуль позволяет назначать права доступа ролям пользователей для терминов терминов таксономии.

Основные возможности модуля:

• Автоматически контролирует доступ к терминам таксономии и к документам сайта (основываясь на принадлежности документа к тому или иному термину).
• Отдельная страница конфигурирования для каждой из ролей пользователей
• Пять видов доступа: Просмотр (View), Обновление (Update), Удаление (Delete), Создание (Create), Отображение списка (List)

Если вы в душе авантюрист, попробуйте ветку модуля 5.x-2.x-dev. В настоящее время она более-менее стабильна, и имеет множество улучшений.

Если вы хотите задавать права доступа к терминам таксономии не к ролям, а к пользователям, попробуйте модуль Taxonomy Access Control Lite (tac_lite).

Итак, со вступлениями покончено, теперь рассмотрим модуль подробнее (версии 5.x-1.1).

Краткое описание

После того, как модуль корректно установлен в Drupal, перейдите на основную модуля - страницу настройки доступа к таксономии (/admin/user/taxonomy_access). Вы увидите список ролей, которые определены в вашей системе:

Нажав на ссылку "Изменить" той или иной роли, вы перейдте на страницу настроек доступа к таксономии для этой роли.

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

Теперь давайте подробнее рассмотрим эту страницу и логику работы модуля.

Подробное описание

На странице задания прав доступа каждой роли, отображаются все категории (словари) с входящими в них терминами и доступными типами полномочий (прав): Просмотр (View), Обновление (Update), Удаление (Delete), Создание (Create), Вывод списка (List) . Ниже приведено их краткое описание:

• Просмотр позволяет пользователю получить доступ к материалу, помеченному данным термином.
• Обновление, Удаление позволяет пользователю обновлять и удалять всё содержимое, помеченное данным термином. Эти полномочия рекомендуется назначать только администраторам содержимого.
• Создание позволяет пользователю создавать и редактировать материал, помечая его текущим термином.
• Вывод списка позволяет пользователю просматривать название данного термина в материале или в списке категорий. Он также управляет доступом к странице таксономии для данного термина. (странице вида "taxonomy/term/*", которая позволяет просмотреть список всех материалов сайта, помеченных данным термином).

Полномочия Просмотр, Обновление и Удаление используются тогда, когда пользователь имеет доступ к материалам. Полномочия Просмотр списка и Создание используются тогда, когда пользователь может просматривать и выбирать термин. (Примечание: В предыдущих версиях Taxonomy Access Control нет настройки права Отображение списка; эта функциональность контролировалась полномочием Просмотра.)

Каждое из прав - Просмотр, Обновление и Удаление - имеют три опции для каждого термина: (A) Разрешить (от англ. Access), (I) Игнорировать (от англ. Ignore), и (D) Запретить (от англ. Deny). Вы должны указать, какие права каждая роль должна иметь для каждого термина.

Полномочия Создание и Отображение списка имеют только две опции для каждого термина: Да (отмечено) или Нет (не отмечено). Укажите, какие права каждая роль должна иметь для каждого термина.

Важно:
Опция Запретить (D), обрабатывается после опции Разрешить (A). Это означает, что опция Запретить (D) перекрывает опцию Разрешить (A). Так, если материал помечен терминами "А" и "В" и пользователь обладает правом Просмотра для термина "А", но не обладает правом Просмотра для термина "В", он никогда не увидит данный материал.

По умолчанию доступ запрещен. Так, если материал относиться к термину "С" и "D" и пользователь обладает полномочием Игнорировать для права Просмотр данных категорий "А" и "В", он не получит разрешения для права Просмотр текущего материала.

(Если вам знаком синтаксис mod_access сервера Apache, то можно сказать, что данные полномочия работают по аналогии с директивой ORDER ALLOW, DENY).

Параметры (A) Разрешить / (I) Игнорировать / (D) Запретить и Выделить / Снять выделение:
Рядом с заголовком каждого словаря есть поля, содержащие варианты привилегий, которые могут быть установлены для индивидуальных терминов. Выбирая одну из этих опций, используя выпадающий список, можно установить данный вариант для всех терминов словаря.
Выбор "--" не позволит автоматически назначить полномочия всем терминам словаря;
Внимание: Это не изменит "Значение по умолчанию".

Значение по умолчанию:
Данная опция автоматически устанавливает полномочия роли для любых новых терминов, которые будут добавлены в данный словарь.

Теперь полезно вспомнить, что на этой странице мы задаём права на просмотр для какой-то _одной_ роли. А что, если пользователь принадлежит не одной, а нескольким ролям? В этом случае, пользователь получает права доступа даже тогда, когда доступ был разрешён только для одной какой-то роли. Права доступа текущего пользователя складываются из всех прав доступа его ролей. Параметр Разрешить перекрывает параметр Запретить. Это отличается от ситуации назначения прав доступа к материалам (к материалам, входящим в несколько категорий), обрабатывающих ОДНУ ПОЛЬЗОВАТЕЛЬСКУЮ РОЛЬ, как отмечалось выше.

Форматы вывода: Правка / Удаление материала заблокированы даже в тех случаях, когда пользователь обладает полномочиями типа Обновление / Удаление, а также если пользователю не разрешено использовать формат фильтра в котором был сохранен материал.

Использование Taxonomy Access Control для управления доступом к форумам (создание приватных форумов и т.п.)

Т.к. в Drupal категоризация форумов осуществляется через стандартный модуль таксономии, существует возможность использовать модуль Taxonomy Access Control для ограничения доступа определённым ролям пользователей к тем или иным разделам форума, тем самым создавая разделы, видимые строго определённым ролям пользователей.

Для этого, вы должны для каждой роли в словаре Forums (Форумы) назначить тот или иной вид доступа к тому или иному термину. Термины в словаре форума есть не что иное, как разделы форума.

Подробнее о модуле Taxonomy Access Control и некоторых других, предназначенных для управления форумом, можно прочитать в статье "Private forums in Drupal: Forum Access vs. Taxonomy Access vs. Taxonomy Access Control Lite" на английском языке или же ознакомиться с переводом этой статьи на русском языке: «Приватные форумы в Drupal: Forum Access, Taxonomy Access или Taxonomy Access Control Lite?»

Источники: Официальная страница модуля Taxonomy Access Control на сайте drupal.org

Модули Drupal: Taxonomy Force All

При активации данного модуля он предоставляет параметр 'all' в ссылках терминов таксономии.

Для примера, давайте представим что у Вашего сайта есть такой словарь:

Vocab

• Term 1
  • Term 2
  • Term 3
• Term 4
  • Term 5
  • Term 6

Если вы перейдёте на страницу taxonomy/term/1, то вы увидите все документы, связанные с термином Term 1 в списке, но НЕ увидите документов, связанных с терминами Term 2 и Term 3.

Если вы хотите видеть все документы, связанные с терминами Term 1, Term 2 и Term 3, на одной странице, вам нужно зайти на страницу taxonomy/term/1/all.

По умолчанию, параметр 'all' нигде не установлен в ядре Drupal. Этот модуль решает это, просто перегружая хук-функцию hook_init(), которая срабатывает, если запрашиваемая страница является подобной taxonomy/term/x, и преобразует запрос в taxonomy/term/x/all.

Источник: Taxonomy Force All

Модули Drupal: Token

Лексемы (англ. tokens) - это маленькие кусочки текста, которые могут быть помещены в большие крупные документы через простые псевдонимы, например такие, как и %site-name или [user]. Модуль Token предоставляет центральный API для модулей, использующих эти лексемы, и подменяет их собственными значениями лексем.

Заметим, что модуль Token сам по себе не предоставляет каких-либо видимых пользователю функций, он просто даёт сервис по использованию лексем для других модулей.

Модули, которые используют модуль Token и предоставляют лексемы через API: Organic Groups, Pathauto, eCommerce, и Ubercart. Полный список модулей, которые используют Token.

Token совместно поддерживается eaton и greggles.

Источник: Token

Модули Drupal: Views

Важно: модуль Views версии 2 альфа не является полнофункциональным. Он не имеет возможности проапгрейдить собой предыдущие версии, и он не будет работать на сайте, который имел установленный на нём модуль Views версии 1, предварительно не деинсталлированный командой 'uninstall'. В нём отсутствуют много возможностей, но вы можете поиграться с ним, по крайней мере. На текущий момент похоже, что Views версии 2 не работает на PHP4.

Модуль Views обеспечивает гибкий метод для разработчиков Drupal-сайтов контролировать, как и какие форматы списков документов будут отображаться на сайте. Традиционно, в Drupal жёстко закодированы большинство из этих форматов списков, в частности, это проявляется в том, как отформатированы списки таксономии и последних изменений на сайте (трекере).

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

Вам нужен модуль Views, если:

• Вам нравится, как отформатирована главная страница по умолчанию, но Вы находите что хотели бы отсортировать документы иначе.
• Вам нравится вид по умолчанию страниц таксономии и терминов, но Вы находите что хотели бы отсортировать документы иначе, например, по алфавиту.
• Вы используете /tracker, но хотите ограничить его так, чтобы он показывал документы определённого типа.
• Вам нравится идея модуля Article, но он не отображает статьи так, как Вам бы хотелось.
• Вы хотите иметь способ отображения блока с 5-ю последними сообщениями определённого типа.
• Вы хотите реализовать возможность для пользователя видеть непрочитанные им сообщения форума.
• Вы хотите ежемесячный архив, похожий на типичный архив блогов Movable Type/Wordpress, которые показывают ссылку в виде "Месяц, YYYY (X)", где YYYY - год, а Х - число постов в этом месяце, и отобразить их в блоке. Ссылки ведут к простому перечню документов за этот месяц.

Модуль Views может гораздо больше, чем то, о чём мы только что написали, но это были некоторые из самых очевидных примеров использования Views.

Источник: Views

<?php
//load the view by name
$view = views_get_view('sample_view');
//output the view
print views_build_view('embed', $view);
?>

<?php
//load the view by name
$view = views_get_view('faq_topics');
//output the top three items in the view with the node title as an argument
print views_build_view('embed', $view, array($title), false, 3);
?>

    // load the context-node's 'metadata'
  global $current_view;
    // * define the context-node's NID as the argument
  $current_view->args[0]=$node->nid;
    // * select the name of the view to embed as $view1
  $view1 = views_get_view('issue_view');                     
    // * define this section for CSS
    print '<div class="issue_view">';
    // * display a subtitle for the view section
    print '<h2>' . t($node->title . ' Issues') . '</h2>';
    // send $args to the View's Argument Handler and display $view1 in the context-node
    print (views_build_view('embed', $view1, $current_view->args, false, false)); 
    print '</div>';

    // load the context-node's 'metadata'
  global $current_view;
    // * define the context-node's NID as the argument
  $current_view->args[0]=$node->nid;
    // * select the name of the view to embed as $view1
  $view1 = views_get_view('issue_view');                     
    // * define this section for CSS
    print '<div class="issue_view">';
    // * display a subtitle for the view section
    print '<h2>' . t($node->title . ' Issues') . '</h2>';
    // send $args to the View's Argument Handler and display $view1 in the context-node
    print (views_build_view('embed', $view1, $current_view->args, false, false)); 
    print '</div>';
 
    // * select the name of the view to embed as $view2
  $view2 = views_get_view('how-to_view');                     
    // * define this section for CSS
    print '<div class="how-to_view">';
    // * display a subtitle for the view section
    print '<h2>' . t($node->title . ' How-to') . '</h2>';
    // send $args to the View's Argument Handler and display $view2 in the context-node
    print (views_build_view('embed', $view2, $current_view->args, false, false)); 
    print '</div>';

Модули Drupal: Views Tagadelic

Этот модуль реализует плагин для модуля Views, который добавляет поле "View Type" на странице модуля Views, и блок под названием "Tagadelic" (в дополнение к "Teaser", "Full Page" и т.д.). Когда выбран документ, он возращается от модуля Views как блок модуля Tagadelic в таком же виде, как и напрямую от модуля Tagadelic. По меньшей мере одно поле для словаря следует добавить в списке полей.

ИНСТРУКЦИИ:

1. Установите этот модуль, а также модули Views и Tagadelic
2. Создайте вид (View) (который имеет словарь в списке)
3. Выберите вид типа "Tagadelic"
4. Затем Вы можете включить страницу вида, или включить блок вида и поставить блок в любом месте

В ПЛАНАХ:

1. Добавить проверку на ошибки чтобы убедиться, что поле словаря было добавлено.
2. Будет более уместно если этот модуль будет называться views_tagadelic, поскольку он расширяет модуль Views, а не Tagadelic, но автор начал разработку с названия tagadelic_views.

Данный модуль частично поддерживается через CivicActions.

Источник: Views Tagadelic

Модули Drupal: XML Sitemap

XML Sitemap создаёт карту сайта в соответствии со спецификацией sitemaps.org. Этот проект заменяет собой модуль Google Sitemap, написанный Мэтью Лоар в рамках Google Summer of Code 2005. Пожалуйста, более ранние версии этих модулей ищите там.

Этот модуль был написан для того, чтобы разрешить внешним модулям добавление поддержки новых видов ссылок и поддержки поисковых систем. Включённые в поставку модули поддерживают следующие поисковые системы и типы ссылок:

• XML Sitemap. Ссылки с внешних карт сайта и отправленные администратором URL-адреса.
• XML Sitemap: Node. Документы и связанные с документами ссылки, возвращаемые внешними модулями.
• XML Sitemap: Term. Ссылка на термины таксономии и связанные с таксономией и терминами ссылки, возвращаемые внешними модулями.
• XML Sitemap: User. Ссылки на профили пользователей и зависимые от профилей ссылки, возвращаемые внешними модулями
• XML Sitemap: Engines. Поддержка следующих поисковых систем:
  • Google
  • Yahoo!
  • Ask
  • Moreover

Источник: XML Sitemap

XML Sitemap: как сообщить поисковым системам об обновлении сайта

Модуль XML Sitemap (ранее Google Sitemap) автоматически создаёт файл sitemap.xml в соответствии со спецификациями sitemaps.org. Это позволяет поддерживающим этот стандарт поисковым системам (в том числе Google, Yahoo!, И Microsoft) построить наилучший индекс вашего сайта.

Модуль имеет несколько опций, которые позволяют администратору сайта настраивать генерацию карты сайта, отправлять карты сайта в Google автоматически, и вести лог загрузки этих карт.

Вы можете:

• Изменить параметры конфигурации на странице управления >> настройки>> gsitemap (administer >> settings >> gsitemap).
• Посмотреть вывод карты сайта на примере The Onion и OurTahoe.org.
• Узнать больше о стандарте sitemaps.org(http://www.sitemaps.org/).
• Посмотреть последние замечания, прочитать об известных ошибок, и скачать последнюю версию на странице проекта XML Sitemap.
• Найти старые версии на странице проекта Google Sitemap.

Установка gsitemap на друпал версии 4.7

Автор: marafa

Установка

1. Создайте аккаунт Google для вебмастеров по адресу https://www.google.com/webmasters/
2. Скопируйте распакованную директорию gsitemap в каталог ~/www/drupal/modules/
3. Включите модуль в админке (administer/modules)
4. Настройте модуль на странице управление/настройки/gsitemap (administer/settings/gsitemap)

Настройка

1. Добавьте Ваш сайт в аккаунт Google по адресу: https://www.google.com/webmasters/sitemaps/siteoverview?hl=en
2. Подтвердите Ваши права на сайт, загрузив указанный html файл (обычно google*??????.html) в корневой каталог Вашего сайта
3. Убедитесь, что чистые ссылки (ЧПУ) включены на странице Управление сайтом/настройки (adminsiter/settings)
4. Отправляйтесь обратно на страницу Ваших сайтов в аккаунте Google для вебмастеров и нажмите "Add Sitemap" ("Добавить карту сайта")
5. Впечатайте URL http://www.domain.tld/gsitemap

Примечания

1. На этом этапе карта сайта должна быть уже загружена в Google.
2. Терпеливо дождитесь, когда google-бот для придёт на Ваш сайт и проиндексирует его. Как правило, это происходит менее чем за 24 часов.

gsitemap с отключенными ЧПУ

Автор: diego belotti

Если Вы не можете включить поддержку чистых ссылок (ЧПУ) на Вашем веб-сайте, то для того, чтобы иметь возможность использовать gsitemap, Вы можете создать и загрузить на сайт парочку следующих скриптов.

Самый простой вариант:

     print file_get_contents(
         "http://www.diegobelotti.com/?q=gsitemap"
     );

А этот вариант требует, чтобы у Вас в корне сайта был доступный для записи файл gsitemap.xml:

    $url="http://www.diegobelotti.com/?q=gsitemap";
    $xml=file_get_contents($url);
    $point=fopen('gsitemap.xml', 'w');
    if(fwrite($point, $xml))
   {
       print "xml created!";
   }
   else
  {
      print "ERROR";
  }
  fclose($point);

Просто впечатайте свой URL вместо моего!

Затем предоставьте Google ссылку на сам php-скрипт в первом случае и на файл gsitemap.xml во втором. Второй скрипт должен запускаться не реже чем ежедневно, чтобы сохранять актуальным xml-файл. Вы можете включить его в свой cron-файл.

Надеюсь это кому-то поможет!

Подробнее [итальянский только! :-( ] на моем веб-сайте

Это хорошее решение!

Автор: Tim-R

Спасибо! :)

Это решение работает на Drupal 5.x с модулем XML Sitemap, но вместо http://www.yoursite.com/?q=gsitemap в скрипте придётся поставить следующий адрес: http://www.yoursite.com/?q=sitemap.xml.

UPDATE:

Инструмент Google для вебмастеров принимает карты сайтов, используя стандартную адресацию Drupal. Я ввёл "?q=sitemap.xml" и карта сайта была загружена! :)

Источник: http://drupal.org/handbook/modules/gsitemap

Модули Drupal: i18n (Internationalization)

Это набор модулей для добавления многоязычности в Drupal-сайты. Обеспечивает возможность размещения перевода содержания сайта - документов и таксономии, перевод интерфейса для анонимных пользователей с помощью модуля Locale и автоматическое определение языка браузера. Предоставляет блок для выбора языка и управляет связями между переводами документов и терминов таксономии.

Читайте полный обзор функций в новом Справочнике по Интернационализации.

Разработка и написание документации к модулю спонсировано Development Seed

Обновление для Drupal 6:

• Большинство модулей были модернизированы для Drupal 6. Тестеры и рецензенты приветствуются.
• Заметим, что некоторые старые возможности и зависимости были сняты и заменены новыми многоязычными возможностями Drupal 6. Этот модуль не будет претендовать на то, чтобы заменить имеющиеся возможности ядра Drupal, но будет опираться на них и расширять их.
• Большинство обновлённых скриптов все ещё не тестировались. Поэтому, не рекомендуется обновлять существующие сайты, если только у вас нет копии данных вашего сайта, и Вы действительно хотите помочь в их тестировании.
• Есть несколько модулей, которые Вы не сможете включить, потому что они ещё не помечены как совместимые с Drupal 6. Причина заключается в том, что они всё ещё не обновлены, некоторые из них ждут пока обновятся другие модули, от которых они зависят. Не пытайтесь редактировать информационный файл (.info), так как это не сработает.
• И ещё раз: Не пытайтесь обновлять скрипты на работающих сайтах.

Источник: Internationalization

Модули Drupal: interwiki

Этот фильтр предоставляет упрощенную разметку текста статьи, вики-подобный синтаксис формирования ссылок на статьи или на результаты поиска на многих широко известных энциклопедических и справочных сайтах Интернета. Например, [w:public relations] создает гиперссылку на статью, посвящённую связям с общественностью (public relations) в Wikipedia, [dict:public relations] создаёт ссылку на словарное определение этого термина, и [google:public relations] ссылается на результат поиска фразы в Google. Модуль также позволяет легко ссылаться на тезаурус, аукцион eBay, SourceWatch (политическая энциклопедия), а также по желанию могут быть самостоятельно добавлены дополнительные ресурсы. Модуль использует ту же таблицу "interwiki", что использует программное обеспечение MediaWiki, на котором работают Wikipedia, SourceWatch, dKosopedia, и ряд других популярных вики.

Источник: interwiki

Локализации модулей Друпал. Autosave

На этой страничке я буду выкладывать переводы модулей, которые мне довелось переводить в ходе работ.

1. Autosave 5.x-1.2

Автоматически записывает документ в процессе его создания. Очень удобная штука. Создает при записи новую ревизию документа.
Скачать перевод - autosave_ru_0.zip

А пока все! Я новичёк!

AboutAirportParking.com - Drupal превращает деловую возможность в Действительность

После двух лет существования AboutAirportParking.com получил полный Drupal-ремонт. Мы переехали со старой инсталляции Flexinode на Drupal 4.7, который был сделан стажёром чуть более чем за месяц, в 2006 году, к самостоятельно темизированной инсталляции Drupal 5, перезапущенной в июне 2008 и существующей до настоящего момента. Как представлено в обзоре стартапа на Mashable.com "About Airport Parking.com помогает Вам найти лучшее место для парковки в аэропорту, с ценами, картами, пользовательскими обзорами и прочим."

AboutAirportparking.com был перезапущен с системой полного бронирования парковки, дополненной комментирующими обзорами, доступом к управляемому редактированию, страницами аэропорта и парковки с возможностью поиска, интеграцией карт от Google, расписанием рейсов, обновляющемся в режиме реального времени, и с подтверждением бронирования через электронную почту и факс. С заказной темой, он также не очень напоминает Drupal.

Drupal действительно хорошо развился как оболочка разработки, с его FormAPI и замечательной модульной платформой. У нас была возможность создать систему бронирования, дополненную особыми датами (blackout dates, т.е. в периоды праздников, фестивалей, сезонных пиков, и других подобных мероприятий или событий, гостиницы/авиарейсы не обязаны обслуживать по установленным тарифам), ограничением бронирования, многочисленными типами бронирования и интеграцией Authorize.net (позаимствовав некоторый код из модуля eCommerce). Посредством замечательного FormAPI, позволяющего изменять формы, мы упростили регистрационный процесс в ходе проверки, и создали собственный поиск, чтобы помочь нашим пользователям в нахождении лучшей возможной брони. Проверьте нашу Питсбургскую парковку, как хороший пример, иллюстрирующий всё вышеизложенное.

Трудный выбор

Для увеличения производительности мы создали собственные типы контента программно, вместо реализации их через CCK. Это позволило нам создать множество взаимосвязанных функций между записями аэропортов и парковок, вне зависимости от взаимодействий CCK -полей. Структура таблицы базы данных получилась более простой, чем та, которую предложил бы CCK, чтобы позволить управлять полями. Кроме того, темизация собственных типов материалов, в противоположность CCK, была намного более простой.

Это могло бы послужить аргументом для многих продвинутых разработчиков, переходить с CCK на собственные типы материалов, но это может быть сложной темой. Управление вставками, обновлениями, редакциями и удалением материалов через модуль требует написания достаточно большого кода, но с того момента, как наши разработчики получили опыт управления собственными типами материалов и опыт работы с API, мы не потеряли много времени. Кроме того, с тех пор инфраструктура развивается, и добавить новое поле не более трудно, чем создать новый столбец в базе данных, и записать несколько строк FormAPI для обновления формы создания документа. Правда, наши главные управляющие не могут добавлять новые поля через веб-интерфейс, как в CCK, но это прекрасно, так как мы, разработчики, всё равно никогда не доверяли им в том, что они смогут сделать это правильно.

Следует запомнить одну хорошую вещь: любой собственный тип контента может быть расширен модулем CCK, и это не означает, что теперь это единственная стратегия. Вскоре мы планируем сделать именно так, добавив поддержку фотографий парковочных мест, что будет реализовано с помощью CCK-модулей ImageField и ImageCache.

Основные моменты: API

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

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

Используя хук профиля пользователя, мы показываем разные страницы профиля обычным пользователям, которые видят всю информацию о бронировании, и владельцам участков (парковочных мест), которые видят инструменты и отчеты, чтобы управлять своим участком. Используя функционал обратных вызовов при темизации, мы создаем пользовательскую приборную панель, которая позволяет владельцам участков редактировать свою информацию, информацию об участке, ссылки для назначения особых дат и создавать повторно используемые шаблоны, фильтры отчётов, и они будут включены в профиль настолько же быстро, как подключение другого файла в теме.

Наши разработчики широко использовали автозаполнение, встроенное в FormAPI, чтобы создать отчеты с автозаполняемыми полями для бронированных номеров или листинги имён/ фамилий.

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

Основные моменты: модули

Да, у всего типичного должны были быть модули, которые мы использовали для того, чтобы создать этот сайт, такие, как Views, CCK, Pathauto, Gmap для карт аэропортов и парковочных мест, TinyMCE для визуального редактирования, XMLSitemap, Global Redirect и Meta Tags для помощи в SEO, Coder и Devel во время разработки. Я также хотел осветить несколько других модулей.

Начиная с того, что управление информацией о сотнях парковочных мест непрактично для маленькой группы, мы хотим открыть технические страницы парковочных мест, которые будут отредактированы владельцами. Так как может быть один или более владельцев участка, мы установили и сконфигурировали модуль Nodeaccess. Хорошее решение, чтобы предоставить право редактировать документ многим пользователям.

Так как комментарии с оценками являются открытыми для посетителей, после перезапуска мы начали получать спам. К счастью, Mollom выполняет задачу отфильтровывания спама.

Page Title является маленьким модулем, который позволяет Вам корректировать заголовок страницы, чтобы отличаться от обычного заголовка документа. Это хорошая практика SEO. Remember Me помогает улучшить постоянство входов в систему и другой модуль, который сэкономил мне много кода - MimeMail модуль. Мы должны были прикрепить формат PDF к электронной почте для того, чтобы наша факсимильная функциональность заработала, и MimeMail был ключевым решением для вложений в электронную почту. Великолепно.

Что дальше?

Есть много возможностей для того, чтобы продолжать по-максимуму использовать Drupal, поскольку AboutAirportParking.com расширяется. Впереди - окончательная интеграция модуля MailHandler, чтобы получать и принимать комментарии от пользователей, которые использовали систему бронирования.

Мы также смотрим в сторону разработки партнёрской системы, чтобы позволить партнёрам использовать нашу систему бронирования, таким образом модуль Services выглядит убедительно, или же мы можем просто использовать XMLRPC, включённый в ядро Drupal.

Затем, после этого, бизнес может подтолкнуть разработку большого количества сообществ и партнёрских программ. Но для Drupal всё ещё будут оставаться способы принять в этом участие.

Заключение

Это правда, что AboutAirportParking.com не будет очередным сайтом, изменяющим мир, но является ясным примером того, как Drupal может принести коммерческие идеи в действительность быстро и эффективно.

Источник: AboutAirportParking.com - Drupal turns a business opportunity into Reality

Big Ideas @ Berkeley использует Drupal, чтобы помочь студентам изменить мир

Инициатива The Big Ideas @ Berkeley была официально запущена в июле 2005. Ее задача состоит в том, чтобы обеспечить финансирование, поддержку и поощрение междисциплинарных команд из студентов и аспирантов университета UC Berkeley, которые имеют "большие идеи".

Летом 2006 года, Big Ideas @ Berkeley решил перезапустить свой сайт с помощью гибкой, открытой системы управления контентом Drupal. Big Ideas @ Berkeley работал с Робом Баррека и компанией ChipIn, чтобы разработать Drupal-модули, которые позволят студентам легко создать свои собственные собирающие пожертвования страницы, публиковать обновления, которые будут очерчивать представленные проекты, принимать пожертвования также хорошо, как и сохранять связи с потенциальными и настоящими споносорами, с помощью записей в блоге проекта.

Переделанный при помощи Drupal 4.7 и целого ряда отличных модулей, предоставленных сообществом, новый сайт был запущен в декабре 2006 года. В числе используемых модулей есть следующие: Views, CCK (а также imagefield), Imagecache, Actions, Workflow, Mailhandler, Simplenews, Forward, TinyMCE and Image Assist.

Собственные разработки под Drupal

В дополнение к этим уже разработанным модулям, перечисленным выше, также было добавлено немного собственного кода, а также был разработан ряд собственных модулей. Подчеркнём следующее:

• Патчи для модуля Workflow, которые позволяют отредактировать и присваивать веса статусам, также предоставляющие некоторые улучшения для Workflow API
• Новые собственные действия, которые были запрограммированы в модуле Actions, для отправки индивидуальных сообщений о пожертвованиях по электронной почте, при изменения статусов Workflow
• Собственный модуль администраторских и студенческих панелей, позволящих различным ролям видеть проекты до их утверждения и разрешающих просмотр проектов по различным критериям
• Вспомогательный модуль для модуля Simplenews, создающий "Письмо для активного студента". Этот модуль синхронизирует список подписок со списком пользователей, которые имеют проекты в статусе активной работы
• Модуль аутентификации CalNet университета UC Berkeley, позволяющий студентам использовать их CalNet-аккаунты, чтобы войти в Drupal-сайты университета
• Пользовательский модуль пожертвований, позволящий организаторам проекта принимать пожертвования через систему GiveToCal
• Расширенный модуль Mailhandler, читающий уведомления о пожертвованиях, отправленных через GiveToCal и автоматически обновить CCK-поле, являющегося термометром пожертвований проекта (фухх!)

Трудности

• Система пожертвований GiveToCal оказалась достаточно жесткой, и единственный способ, которым Drupal-сайт может быть уведомлен о недавнем пожертвовании, была электронная почта. К счастью, у нас был модуль Mailhandler для работы, способный регулярно проверять электронную почту, заведённую специально для писем о пожертвованиях, и отпарсить сумму пожертвования, название пожертвования и ID проекта, так что мы смогли обновлять термометр пожертвований.
• Другая небольшая трудность заключалась в том, чтобы очищать 2-этапную подтверждающую работу, в которой университет UC Berkeley нуждался в процессе сохранения проекта. При использовании модулей Workflow и Actions, стандартная последовательность отправки проекта выглядит следующим образом:
  1. Студент отправляет свой потенциальный проект "большая идея" (со всеми скрытыми CCK-полями, за исключением описания и выпадающего списка из терминов таксономии), который автоматически принимает статус "Запрос на утверждение проектного резюме" и администратор по электронной почте получает уведомление, говорящее о просьбе утвердить проект.
  2. Затем, администратор либо утверждает проект, присваивая ему состояние "Проектное резюме утверждено", переходя к шагу (3), или говорит, что его необходимо доработать, присваивая проекту статус "Проектному резюме требуется доработка", требуя от авторов повторить шаг (1). Для дальнейшей работы студент уведомляется о решении администратора.
  3. Проекты, которые прошли первый этап и получившие статус "Проектное резюме утверждено", имеют целый ряд новых CCK-полей, которые становятся видимыми. Тогда студенты заполняют эти поля, и затем отправляют проект в следующее рабочее состояние "Запрос окончательного утверждения, чтобы быть опубликованым" и администратор уведомляется по электронной почте снова.
  4. Аналогичный с шагом (2), происходит процесс утверждения, разница заключается только в том, что на этот раз проект имеет около 15 полей, заполненных студентами, вместо первоначального одного поля описания в шаге (1). Если проект утвержден пойти "в жизнь", ему будет присвоен статус "Активен / Опубликован", и его будет видно на сайте, по электронной почте студенту придёт уведомление об окончательном утверждении.
  5. Есть еще две разновидности рабочего статуса "Опубликован": "Финансирован / Опубликован" и "Прошлые / Опубликован". Когда проект достигает своей целевой суммы пожертвований, он будет размещен в первом рабочем состоянии, а когда проект подходит к концу (к дате окончания), он будет во втором статусе. Таким образом, старые/финансированные проекты не загромождают просмотр проектов в статусе "Активный", см. http://bigideas.berkeley.edu/projects/13/all/6 в качестве примера.
• Доводка модуля ChipIn для использовании в Big Ideas @ Berkeley. Чтобы увидеть это в действии, взгляните на страницу продвижения проекта - http://bigideas.berkeley.edu/promote/32 - и нажмите СОЗДАТЬ ВИДЖЕт (CREATE WIDGET). Для того, чтобы прилепить новый логотип, перенаправить кнопку Пожертвовать! (Donate!), и сделать виджет, тянущий данные из моего собственного проекта, мне необходимо освежить навыки в Flash/ActionScript. Это был замечательный опыт работы с потрясающим виджетом (следующая версия ChipIn.com в настоящее время разрабатывается на Drupal 5 и будет иметь ещё лучший построитель виджетов), спроектированным Кевином Хьюджом в ChipIn.

Подробнее о Big Ideas @ Berkeley

Рынок Больших Идей Университета Беркли (Big Ideas @ Berkeley), сайт, разработанный компанией ChipIn, поддержанный проектом CommerceNet и администрируемый университетом UC Berkeley, позволяет выпускникам, корпоративным и основным партнерам, друзьям и семьям поддержать студентов и аспирантов университета Berkeley, которые увлекаются решением крупных глобальных, региональных, и местных проблем, таких, как чистая энергетика, охрана окружающей среды, здравоохранение, снабжение чистой питьевой водой, публичная политика, и технологическое производство. Сторонники могут поддержать проект "Big Ideas" следующими способами:

• Сделать финансовые или материальные (натуральные) взносы для специфических проектов,
• Спонсировать ежегодный конкурс "Медведи, преодолевающие границы" ("Bears Breaking Boundaries") на лучшую студенческую идею,
• Помогать в сборе средств (с использованием ChipIn) от своих друзей и коллег,
• Предоставлять студентам консультационную помощь и связи с потенциальными партнерами.

"Это абсолютно ПОРАЗИТЕЛЬНО! Невероятно хорошо построенный, и один из наиболее новаторских студенческих сервисов, которых я видел за всё время моего присутствия здесь". — Ilan Gur, Ph.D.

С контактами авторов статьи, и официальными контактами Big Ideas @ Berkeley можно ознакомиться на странице оригинала (английский язык).

Источник: Big Ideas @ Berkeley uses Drupal to help students change the world

Drupal: Как добавить произвольные meta-теги и другие теги в head-область HTML-страницы

Дорогие друзья-друпаловоды, вы наверняка знаете, что иногда бывает необходимо прописать для страницы нужные мета-теги. Создать произвольный meta-тег нам может понадобиться, когда мы будем подключать и настраивать библиотеку phpMyID к Drupal, или, например, когда нам нужно будет подтвердить своё право владения веб-сайтом для некоторых сервисов, разместив на главной странице проверочный мета-тег.

Сформулируем задачу: необходимо вывести проверочные теги сервисов Яндекс.Вебмастер, Инструменты для веб-мастеров от Google, Yahoo! Site Explorer и Webmaster Tools от Microsoft Live Search (MSN) на главной странице сайта. Нужно нам это для того, чтобы вышеописанные сервисы могли подтвердить моё владение сайтом. (Ну а для тех кто совсем ничего не знает и не понимает, поясню, что вышеописанные сервисы предоставляют владельцам сайтов интересную информацию о проиндексированности сайта, количестве поисковых запросов, по которым находится ваш сайт, количество ссылок на ваш сайт и другую подобную и очень интересную инфу. Для того, чтобы получить её, вам необходимо зарегистрироваться на вышеописанных сервисах и подтвердить право владения своим сайтом, разместив проверочные мета-теги на главной странице, или разместить предложенный файл на сайте. Я выбрал метод с мета-тегами, т.к. на мой взгляд, он удобнее.)

Сформулируем задачу в общем виде (мало ли какие теги нам понадобиться выводить в head-области), и мы получим заголовок этого поста: Как добавить произвольные meta-теги и другие теги в head-область HTML-страницы:

<html>
  <head>
    <title>Тестовая страница</title>
    <meta name="robots" content="index,follow" />
    <meta name="verify-v1" content="ApEbWaOK3CfB1B0vwz1aXiPM4AyF25WXJcivNFmEKtQ=" />
    <meta name="ПРОИЗВОЛЬНАЯ_МЕТА" content="ПРОИЗВОЛЬНЫЙ_КОНТЕНТ_МЕТЫ">
    <ПРОИЗВОЛЬНЫЙ_ТЕГ>КОНТЕНТ_ПРОИЗВОЛЬНОГО_ТЕГА</ПРОИЗВОЛЬНЫЙ_ТЕГ>
  </head>
  <body>
ВСЯКАЯ ВСЯЧИНА
  </body>
</html>

Теперь задумаемся о решениях. Скажу сразу, что решения разрабатывались для ветки Drupal 5.x, но я думаю, что их можно использовать практически в неизменном виде и для других версий.

Самый очевидный путь - это прописать эти теги в файле page.tpl.php вашей темы. Этот путь имеет тот недостаток, что в будущем вы, возможно, захотите использовать файл page-front.tpl.php для главной страницы, или предпочтёте использовать тему, которая написана на другом движке шаблонов (например на Smarty), и вообще, у вас может быть мультисайтинг, и вы используете одну и ту же тему для совершенно разных сайтов, тогда как мета-теги должны быть заданы для каждого сайта строго свои. Конечно, мы можем в файле page.tpl.php или page-front.tpl.php поставить условие, которое будет проверять домен сайта и в зависимости от него выдавать нужные теги, но это всё чересчур сложно. Нас же интересует метод типа "сделал и забыл".

Второй, менее очевидный путь - это написать свой .inc-файл для модуля Meta Tags (он же в прошлом NodeWords). Этот путь нам посоветовал уважаемый andypost@drupal.org. Цитирую:

Модуль nodewords имеет свой API и свои хуки
расширяется элементарно - созданием .inc файлика с парой функций в папке tags
весь функционал реализован именно таким образом - разобраться совсем не сложно - достаточно посмотреть текущую реализацию

Минусы этого подхода - вам надо скачивать, устанавливать и настраивать этот модуль, плюс ещё писать нужный .inc-файл для него и положить его в соответствующую папку модуля (папку tags). Однако этот метод уже лучше, чем редактирование темы, т.к. даёт большую гибкость. Я пытался разобраться в формате .inc-файлов для модуля Meta Tags, но что-то неудачно, и написать собственный файл мне не удалось. Обращаюсь с просьбой ко всем, кто знает как написать .inc-файл для поддержки нужного тега этим модулем, отпишитесь в комментах с текстом этого файла.

Третий путь был какой-то замутный, с использованием CCK. Я нашёл его на русскоязычном портале drupal.ru: META-теги (Есть ли решение?). Цитирую уважаемого edhel:

Можно без доп. модуля ручками запрограммить такое: с помощью CCK добавить поле "ключевые слова" и модулек свой из ~4 строчек с хуком nodeapi. Если $op=='view' && $page, то добавить в заголовок ...

Этот вариант, опять же, не прокатывает - слишком громоздкий, требует огромного стороннего модуля CCK и программирования. Но идея интересная, из-за идеи и включил этот вариант в статью. Может кто загориться и реализует :)

Четвёртый вариант, предложил уважаемый marazmus:

Сделайте область (регион) там, где нужно расположить метатеги - оформите ее в template.php и пропишите ее вывод в page.tpl.php.

Затем достаточно будет сделать блок, ввести туда нужные метатеги (не забыв использовать фильтр Full HTML или PHP), и включить этот блок в нужное время в нужном месте - положив блок в свежеоформленную область.

Правда, при этом нужно будет помнить, что в этот блок нельзя пихать "визуальные" теги, но это уже издержки гибкости. Зато мы можем описать (запрограммировать или прописать через пути друпала), когда и где должен появляться этот блок. Еще плюс - блоков можно насоздавать много, для разных случаев.

Кроме того, по умолчанию блоки оборачиваются в тег div с CSS-классами и id, что недопустимо в head-области документа по стандарту HTML. Поэтому, чтобы обойти это, придётся в теме писать файл block-...tpl.php для того блока, который будем выводить.

Тоже решение, однако опять же, несколько замутное. Городить такой огород, да ещё и помнить потом про него... Не наш метод! :)

Ваш покорный слуга, наконец-то, предлагает Вам пятый и, на мой взгляд самый гибкий и удобный метод. Заключается он в следующем:

1. Создаём PHP-блок на странице управления блоками (/admin/build/block). PHP-блок это такой блок, в котором в качестве фильтра указывается обработчик PHP. Лучше всего его создавать из-под учётной записи администратора.
2. Вводим в тело блока следующий код:

   drupal_set_html_head('<meta name="verify-v1" content="fmX1YhAzQ20sKTBkoEAa3W+h432WiBjtbyM78gi0V/o=" />'); //for Google
   drupal_set_html_head('<meta name="y_key" content="ec64d4a23b420294" />'); //for Yahoo
   drupal_set_html_head('<meta name="yandex-verification" content="6dcc2d578ba99b72" />'); //for Yandex

   
   Разумеется, вместо моих тегов в функцию drupal_set_html_head() Вы должны вставить свои теги.

   Функция API Drupal drupal_set_html_head(), делает как раз то, что нам надо - отсылает любой переданный с её помощью HTML-код в head-область формируемой странички.

3. Сохраняем наш блок.
4. Идём в настройки этого только что созданного блока и выставляем там следующие значения:

   Название: Оставляем название пустым обязательно!, чтобы Drupal не отображал его. (то самое название, что должно было бы показываться пользователю)

   Описание блока: посылаем произвольные теги в head-область, или любое другое описание, что вы хотите

   Настройки видимости для пользователя: Пользователи не могут управлять видимостью блока - ставим галочку тут

   Настройки видимости для ролей: anonymous user - ставим галочку тут

   Установки видимости для страницы: Показывать только на перечисленных страницах: (т.е. показываем блок только на главной странице)

5. Сохраняем блок.
6. На странице списка блоков (/admin/build/block) нашему блоку выставляем следующие параметры:

   Область сайта, в которой будет отображаться блок: Заголовок (Header)
   Вес: самый минимальный -10

7. И после этого наживаем Сохранить блоки.

На этом всё - наша задача решена. Если Вы всё сделали правильно, то после сохранения, спустя некоторое время, когда у вас на сайте обновится кеш для анонимных посетителей (если Вы используете кеширование для своего сайта), введённые Вами мета-теги отобразятся на сайте, и Вы сможете подтвердить права владения Вашим сайтом для Google или Yandex, например. Эти теги будут отображаться только на главной странице и только незарегистрированным пользователям, в соответствии с нашими настройками.

Почему это работает? Если блок не генерирует никакого содержимого, то Drupal не отображает его. Наш блок не генерирует вообще ничего. Он просто выполняет PHP-код, который работает с API Drupal, обеспечивая модификацию head-области страницы до её отсылки в браузер пользователя, в результате же выполнения кода никакого контента не генерируется, и следовательно, блок не будет отображён и не будет портить нам дизайн.

Благодарности:
Благодарю всех откликнувшихся в этой теме пользователей Drupal.ru
Спасибо этому посту, за то, что навёл меня на идею использовать функцию drupal_set_html_head().

PS: Столько способов сделать одно и то же! На мой взгляд, всё это показывает, насколько система Drupal гибкая. Когда я искал собирал инфу о проблеме, набрёл на статью на официальном сайте о том, как один чел сделал это всё через редирект, а точнее через модуль path_redirect - он как бы создал проверочный файл (центр вебмастеров Google требует для подтверждения собственности на сайт вставить в него определённую мету, или создать файл в корневой директории на сервере) и редиректился с него на главную страницу своего сайта с кодом 302. Пишет, что сделал он это "элегантно, всё в друпале, никакого фтп, никаких закачек файлов на сервер". Так что нам ещё один метод в копилку...

PPS: Сервисы для вебмастеров:

• Яндекс.Вебмастер
• Инструменты для веб-мастеров от Google
• Yahoo! Site Explorer
• Webmaster Tools от Microsoft Live Search (MSN)

PPPS: Важная информация для всех пользователей предложенного решения и Drupal 5.8!!!
Ввиду бага - regression in 5.8 from 5.7 theme(blocks,all) broken - so no header alteration possible в Drupal 5.8, решение НЕ РАБОТАЕТ! Чтобы оно заработало, необходимо скачать обновлённую dev-версию Drupal 5-й ветки (я брал версию от 17 июля 2008 г.), в которой сделаны патчи, закрывающие данный баг, и обновить следующие файлы:

• modules/block/block.module
• modules/block/block.info
• themes/engines/phptemplate/phptemplate.engine

Тогда всё заработает как и прежде.

Drupal: баг или фича?

Обнаружил одну интересную особенность в CMS Drupal.

У меня есть два аккаунта: администратора (самого первого пользователя системы), и обычный аккаунт, из-под которого можно только создавать и редактировать блог.

Зашел я под обычным аккаунтом, создал статью... все хорошо. захожу вполедствии под обычным аккаунтом, вижу ссылку "Изменить" - нажимаю - действительно, могу редактировать документ. Все хорошо...

Но однажды, зайдя под администратором, обнаружил неточности в статье и поправил их. Сохранил. После этого, захожу под обычным аккаунтом и вижу, что изменить статью, ранее мной созданную, уже не могу - нет ссылки "Изменить".

Поразмыслив, пришел к выводу, что во всем виноват модуль Autosave: он автоматически создает ревизию документа во время его правки. Наверняка он ставит новой ревизии в качестве автора текущего пользователя - т.е., в моем случае, админа. И когда я захожу уже под обычным аккаунтом, я уже не могу исправить ревизию, созданную администратором.

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

Возможные варианты фикса этой фичи :) :

1. исправить модуль Autosave, чтобы когда модератор или администратор правил посты пользователя, ревизии записывались бы с их авторством (т.е. автором ревизии проставлялся бы автор ноды)
2. Исправить Друпал, и модуль blog, с тем чтобы при решении, давать редавтировать эту ноду или не давать, в качестве автора любой ревизии брался бы именно автор ноды, а не ревизии.

Любой из этих способов немного не верный... первый - тем, что логичнее текущую ревизию сохранять под авторством того автора, который ее делает, а второй - тем, что при решении, можно или нет исправлять ту или иную ревизию, логичнее брать автора именно ревизии, а не ноды...

И как тут быть?

Drupal: удаляем/переносим посты и прочее имущество одного пользователя к другому

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

Внимание! Предупреждение! Если Вы приняли решение использовать любой нижеследующий код, то вся ответственность за его результаты и последствия будет лежать на Вас и только на Вас! Автор предлагает всё нижеследующее только как свой собственный опыт и не гарантирует корректной работы кода в Вашем конкретном случае. НЕ ЗАБУДЬТЕ СДЕЛАТЬ РЕЗЕРВНУЮ КОПИЮ ВАШЕЙ БАЗЫ ДАННЫХ ПЕРЕД ИСПОЛЬЗОВАНИЕМ ЛЮБОГО НИЖЕСЛЕДУЮЩЕГО КОДА!

Будем делать это мы посредством выполнения SQL-запросов - так будет быстрее всего. Поэтому сначала мы подготовим соответствующие запросы к базе данных. Имейте в виду, что имена таблиц в запросах я указал в фигурных скобках (как это принято в среде разработчиков Drupal), вам же нужно будет заменить имя таблицы в фигурных скобках на реальное имя таблицы с Вашим префиксом или постфиксом, если запрос вы будете выполнять непосредственно на сервере (через phpMyAdmin, например).

/* меняем автора документов (нод) */
UPDATE {node} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';
UPDATE {node_revisions} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';
 
/* меняем автора комментариев */
UPDATE {comments} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';
 
/* если используется модуль IMCE_Gallery, меняем автора (владельца) галлерей: */
UPDATE {imce_gallery} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';
UPDATE {imce_gallery_items} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';
 
/* обновляем историю просмотров документов */
UPDATE {history} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';
 
/* если используется модуль LiveJournal CrossPoster, делаем привязку LiveJournal-дневника к новому пользователю: */
/* Внимание! Если дневник наверняка не принадлежит новому пользователю, НЕ ДЕЛАЙТЕ ЭТОГО! */
/* Иначе вы можете дать доступ стороннему человеку к чужому дневнику! */
UPDATE {ljxp} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';
 
/* присваиваем роли старого пользователя новому: */
UPDATE {users_roles} SET uid='#OLD_UID#' WHERE uid='#NEW_UID#';

После того, как вы выполнили эти запросы (естественно, вам нужно заменить '#OLD_UID#' на uid Вашего старого пользователя, а '#NEW_UID#' - на uid нового), Вам необходимо подкорректировать синонимы, связанные со старым пользователем, на новые. Этот шаг я делал вручную, мне понадобилось изменить синоним на самого юзера, на его блог и на его галлерею (IMCE_Gallery).

Те, кто использует модуль IMCE_Gallery, используют и модуль IMCE. А IMCE, как известно, позволяет пользователям иметь своё собственное хранилище файлов на Вашем сайте, и предоставляет удобный доступ к нему. Когда пользователь загружает какой-либо файл, он сохраняется в его собственной папке. По умолчанию IMCE создаёт папки вида u5, u1, u134, где буква u означает user, а число непосредственно сразу за буквой - это uid юзера. Таким образом, если наш старый пользователь создал документ и в него вставил картинку или файл, то путь до этой, например, картинки, будет примерно таким: files/u5/my_picture.gif. Разумеется, этот файл будет отсутствовать в директории файлов нового пользователя (т.к. файл пока никто не копировал из старой директории в новую). Если же файлы из пользовательской директории старого пользователя, переместить в пользовательскую директорию нового пользователя, то все файлы и картинки, закачанные старым пользователем, перестанут загружаться (т.к. путь до них прописан с использованием старой директории: files/u5/my_picture.gif). Для того, чтобы всё было корректно, нам необходимо поправить пути до файлов во всех документах старого юзера.

Найти и посмотреть ноды, в которых используются старые пути для файлов, можно с помощью запроса:

/* смотрим документы, которые используют старые пути в своём контенте */
SELECT `body`, `teaser` FROM {node_revisions} WHERE `body` LIKE '%/#OLD_DIRECTORY#/%' OR `teaser` LIKE '%/#OLD_DIRECTORY#/%';

Заметьте, что вместо #OLD_DIRECTORY# вы должны вставить пользовательскую папку Вашего старого юзера. Так, например, если у вас старый пользователь имеет uid=5, IMCE настроен сохранять файлы в директории вида uномер_пользователя, то старая папка будет u5. Обратите внимание, что в запросе папка обрамлена слешами: /u5/, это нужно для того, чтобы найти именно пути, а не какую-то другую часть поста.

Для этого составим и выполним следующие SQL-команды, с использованием замечательной функции MySQL REPLACE():

/* меняем пути до файлов в новой директории. (предварительно скопировав их из старой директории в новую) */
UPDATE {node_revisions} SET `body` = REPLACE(`body`,'/#OLD_DIRECTORY#/','/#NEW_DIRECTORY#/'), `teaser` = REPLACE(`teaser`,'/#OLD_DIRECTORY#/','/#NEW_DIRECTORY#/') WHERE `body` LIKE '%/#OLD_DIRECTORY#/%' OR `teaser` LIKE '%/#OLD_DIRECTORY#/%';

Не забудьте поменять #OLD_DIRECTORY# на имя пользовательской папки Вашего старого юзера, а #NEW_DIRECTORY# - на имя пользовательской папки Вашего нового юзера.

Возможно, после всех этих операций Вам понадобиться сбросить кеш Drupal, чтобы ноды закешировались заново:

TRUNCATE TABLE {cache};

Мне же этот шаг не понадобился, всё было хорошо.

Код для регенерации анонсов (teasers) у всех документов (nodes) Вашего сайта

Когда я делал последний шаг, я немного ошибся и выполнил несколько неправильный запрос, в результате которого у меня все анонсы стали равны основному содержанию - вместо тизеров отображались полные версии статей. (В статье-то я, конечно, указал уже корректный запрос).

Выход из такой ситуации - пересоздать (переписать) все документы на сайте. Вручную делать это, конечно же, не хотелось, поэтому, после довольно долгого гугления, был найден следующий код:

echo 'Fixing the latest node revision teasers for these published items:<br />';
$result = db_query(db_rewrite_sql("SELECT n.nid, n.status, n.vid, r.body, r.format FROM {node} n LEFT JOIN {node_revisions} r ON n.vid = r.vid WHERE n.status = '1' ORDER BY n.nid DESC"));
while ($node = db_fetch_array($result)) {
     $teaser = node_teaser($node['body'], $node['format']);
     db_query(db_rewrite_sql("UPDATE {node_revisions} n SET n.teaser ='%s' WHERE n.vid='%d'"), $teaser, $node['vid']);
    echo $node['nid']." / ".$node['vid']."<br/>";
    }

Код взят отсюда: Fix Node Teasers

Он был написан для Drupal 4.7, но подходит и для Drupal 5.8. Я совсем немного подкорректировал его - поставил
в первой строке.

Самый простой и быстрый способ выполнить его - это под суперадмином создать страницу (ноду) на вашем сайте, разместить в теле страницы этот код (включая теги  ) и сохранить её. Обязательно уберите галочку "Опубликовать"! Тем самым вы сделаете невидимой эту страницу для всех, кроме автора, т.е. в нашем случае, на эту страницу никто не будет иметь доступа, кроме админа.

На этом вроде бы всё. Не забывайте делать резервную копию Ваших данных перед любыми экспериментами! Делать её после уже может быть поздно! Пишите в комментариях Ваши вопросы и замечания, отвечу всем по мере сил. Спасибо за внимание и удачи, друпаловоды! :)

Information.dk - Ещё один сайт газеты, основанный на Drupal

Information является ежедневной независимой газетой, распространяемой по всей Дании, а также в Европе. Она выходит шесть дней в неделю с тиражом 22 000 экземпляров и имеет около 100 000 читателей. До недавнего времени сайт газеты, information.dk, был основан на самостоятельно написанной CMS. С 28 августа 2007 года сайт работает на Drupal. Дизайн и CSS были сделаны Йенсом Кристофферсеном, а всевозможные хаки Drupal были сделаны Йохсом Венером. Проектом руководил Николай Тиссен, директор нового медиа.

Тестируем: luftskibet.information.dk

Сайт information.dk является результатом разработки, длившейся примерно полгода, но, прежде чем мы начали эту работу, мы запустили блог, luftskibet.information.dk ("luftskibet" переводится с датского как "дирижабль"), разработанный на Drupal.

Мы сделали это, чтобы набить руку и получить определённый опыт в разработке Drupal-сайтов, до погружения в разработку основного сайта. "Luftskibet" был разработан в Drupal 4.7, запущен 4 октября 2006 года и с этого времени является родиной для блогов наших журналистов. Одной из вещей, которых мы достигли в результате нашего тестового исследования, было изучение полной терминологии Drupal. Некоторые вещи, которые мы сделали для "Luftskibet", сегодня будут сделаны в несколько другом стиле, но тем не менее, это был действительно хороший способ, чтобы начать. Наш опыт с "Luftskibet", а также визит - любезно организованный Кеном Рикардом и Стивом Йелвингтоном - в The Savannah Morning News, убедил нас в том, что Drupal это тут путь, по которому пойдёт и наш главный сайт.

Первоначально "Luftskibet" был основан на WordPress, но его было довольно легко портировать на Drupal благодаря модулю миграции с Wordpress на Drupal. Это означает, что мы не имели представления о том, насколько сложным будет портирование главного сайта.

Главный сайт

Разработка главного сайта началась в феврале 2007 года.

Импорт данных

Импорт нашего архива первоначально была одной из наших самых серьёзных трудностей. Наш архив восходит к 1997 году и состоит из более чем 180 000 статей, но, как выяснилось, это было гораздо проще, чем мы ожидали. Статьи в нашей старой системе также хранились в MySQL, так что мы просто сделали базу данных MySQL на нашем рабочем сервере, выделенном для разработки, прошлись по статьям в базе данных, используя php, и создали документ (ноду) для каждой статьи, сменив подключение к базе данных, и использовав функцию Drupal'а node_save(), чтобы вставить все статьи в базу данных. После того, как мы поняли, как построена структура документа (ноды) в Drupal, импорт оказался не столь болезненным, как мы опасались.

Импорт данных из бумажной версии газеты

Бумажный вариант газеты Information производится в SaxoPress. Как только статьи готовы к печати, они экспортируются на наш веб-сервер как xml-файлы (почти NIFT-формат, но не совсем) с изображениями в формате jpg. Первоначально мы надеялись разработать NIFT-модуль, но поскольку у нас есть собственный тип документов, и потому что xml, генерируемый нашей системой не является совместимым со стандартным форматом NIFT (требующий много разного рода уродливых хаков), невозможно было сделать достаточно абстрактный код, чтобы выложить действительно полезный модуль в общий доступ. Если Вы заинтересованы в этом коде, вы можете связаться с Йохсаном Венером.

CCK

Наши статьи имеют свой собственный тип материалов. Мы не разрабатывали новый модуль, мы просто используем CCK. Первоначально тип материалов точно отражал структуру печатных статей. Но для того, чтобы сделать подзаголовки и другие текстовые форматы более подходящими для использования в Интернет, мы продублировали некоторые из полей, так что ими теперь можно манипулировать и использовать на главной странице и при формировании списков, в то время как на странице просмотра можно сохранить исходное содержание. Кроме дублирования текстовых полей (используя поле CCK типа textfield), мы также включили поля для вставки изображений (поле CCK типа imagefield) для альтернативных изображений и изображений только для главной страницы.

Таксономия

Первоначально тип материалов, предназначенный для размещения статей, имел лишь один словарь, отражающий редакционные столы газеты. Но когда мы приступили к разработке других разделов сайта, мы выяснили, что нам необходимо более широко использовать таксономию, чтобы публиковать и отображать содержимое так, как мы хотели. Поэтому мы сделали словарь "Жанр" ("Genre" по-английски, в этом словаре были такие термины, как, например, "Заметка" ("Note"), "Обзор" ("Review"), "Редакционная колонка" ("Editorial"), "Хроника" ("Cronicle") и т.д.) и словарь "подразделов", содержащий документы наиболее общих тем, для него мы сделали свободный ввод тегов. Незадолго до старта мы выяснили, что подзаголовки статей можно использовать в качестве ещё одной категории со свободным вводом тегов, поскольку колонки часто использовали одни и те же подзаголовки в течении всего времени. Поэтому мы преобразовали его из обычного текстового поля в таксономию.

Первая страница

Наша главная страница сделана при помощи модулей Panels и Views, и не в последнюю очередь благодаря великолепному модулю Дэвида Страуса PressFlow Preempt Panels. Panels позволяет нам сделать более сложную разметку нашей главной страницы. Прежде чем мы обнаружили модуль PressFlow Preempt Panels, загрузка нашей сравнительно сложной главной страницы занимала целую вечность. Спасибо Дэвиду Страусу за его супер-модуль для кэширования панелей. Подробная информация о модуле может быть найдена на странице http://drupal.org/project/pressflow_preempt_panels

Публикация лучших статей сделана с помощью удобного модуля Node Queue. Это очень простой, но эффективный способ обработки и расстановки приоритетов новостей.

Views

Наши разделы сайта (например, раздел "Культура") первоначально были сложными элементами модуля Views, которые показывали статьи из одной или более категорий, при этом исключая статьи из других категорий, сортируя выводимые статьи по дате. Это в конце концов привело к низкому быстродействию наших разделов. Мы не знали, что делать, поэтому мы связались с Дэвидом Страусом, потому что мы были очень впечатлены его работой - модулем PressFlow Preempt Panels. Последовав его совету, мы создали три новых модуля, по одному для каждого раздела, используя хуки API нод, чтобы вставить статьи в отдельную таблицу, если они удовлетворяют условиям, которые мы первоначально задали для элемента модуля Views. Он назвал это materialized views - вдохновившись примером Oracle. Это работает очень хорошо. Снова замечательная работа Дэвида Страуса.

Это не означает, что нам не нравится модуль Views. Мы используем его во многих других разделах сайта - почти везде, кроме трёх вышеперечисленных разделов и главной страницы. Использовать модуль Views означает для нас сэкономить много времени, потраченного на разработку, потому что не-программисты могут довольно легко построить нужные страницы, для построения которых в другом случае потребовалось бы время для написания кода. Поэтому большая от нас благодарность Эрлу Майлсу и другим специалистам, работающими над Views. Views - это очень важный вклад.

Изображения

Поскольку у нас есть только цифровые права на изображения, которые мы используем в работе в течении двух недель, мы вынуждены были сделать изображения исчезающими. Мы реализовали это в теме. Если статья старше двух недель, картинка и её подпись не отображается.

Мы используем фантастический модуль Imagecache практически для всех наших изображений, за исключением изображений в профиле пользователя и изображений, сделанных специально для главной страницы. Но поскольку мы выяснили, что огромные по размеру, подготовленные для печати картинки, поступающие из нашей редакционной системы, слишком большие для нашего загруженного веб-сервера, мы предварительно масштабировали их с помощью applescript и "Image Event".

Premium

Для контроля доступа мы используем самостоятельно доработанный вариант модуля Premium. Этот модуль работает прекрасно, но потому, что у нас есть несколько видов подписки, нам нужно было доработать его, чтобы обеспечить для подписчиков, которые подписываются на всю неделю, несколько других привилегий, чем для тех подписчиков, кто подписывается только на выходные.

Sphinx

Одной из наших самых серьезных задач являлся поиск. Использование встроенного в Drupal модуля поиска, чтобы проиндексировать 180 000 статей, оказалось невозможным. С нашими объемами данных, стандартный поисковый модуль просто не в состоянии был это сделать. Поэтому, после нескольких недель отчаяния, другая датская газета делает Drupal-проект, ориентированный на Sphinx. Сфинкс является самостоятельной поисковой системой, предназначенной для полнотекстового поиска, а также хранилищем данных на основе MySQL (SphinxSE). Для того чтобы заставить Sphinx работать как хранилище данных, он должен быть скомпилирован вместве с MySQL. Мы попытались это сделать, но наша попытка не увенчалась успехом. К счастью, наша хостинговая компания смогла это сделать. Тогда как стандартный модуль поиска, встроенный в Drupal, работает около месяца, чтобы построить индекс для нашей базы данных, Sphinx делает это за пару минут. Он работает очень быстро, как индексирование, так и поиск.

Большое спасибо отправляется Андрею Аксёнову, отцу-основателю проекта Sphinx. Это действительно фантастический проект!

Обратная сторона

Мы используем тему Garland для администрирования. Помимо встроенных администрационных страниц, мы сделали страницу, позволяющую осуществить некоторые действия, с помощью модуля Actions. Мы используем её, чтобы показать все статьи одного дня на одной странице. Мы также сделали небольшой блок (сгенерированный с помощью модуля Views), показывающий все неопубликованные материалы. Эта страница даёт людям возможность помечать статьи, и расширяет возможности предварительного обзора и восприятия наших статей.

Другие модули

Следуя примеру газеты The New York Observer, мы используем модуль Related Links. Модуль blockcache помогает нам улучшить производительность почти всех страниц, за исключением главной.

Чтобы сделать дружественные к SEO и пригодные для быстрого копипаста короткие ссылки, мы используем сказочный Pathauto.

Также мы используем:

• Actions
• Auto assign role
• Captcha
• Find URL Alias
• Flag content
• Global redirect
• Printer friendly pages
• Simplenews
• Suggested terms
• Tagadelic
• XML Sitemap

Мы создали около 15 собственных модулей для обработки импорта, пользователей (мы используем электронную почту в качестве имени пользователя, а также нам необходимо отдельное имя пользователя, которое отображалось бы на сайте), пользовательских страниц (как для подписчиков, так и для журналистов и обычных Drupal-пользователей, поэтому мы нуждались в некоторых настройках), привилегий для подписчиков, веб-трекера, поиска, интеграции с сайтами-блогами т.д.

Оборудование (Гики, внимание!!)

В случае если кого-либо это заботит, наш сайт работает на операционной системе CentOS сервера HP dl140g3 с четырёхъядерным процессором частотой 1,6 ГГц от Intel, сервер имеет 5 Гб памяти и два жёстких диска SAS 15 K по 73 Гб каждый, объединенённых в дисковый массив RAID1.

Теперь мы передаём слово Йенсу, нашему дизайнеру и верстальщику:

Работа над дизайном information.dk

Немало внимания было уделено разработке дизайна нового сайта. Мы быстро поняли, что должны отойти от простого изменения уже существующих шаблонов, чтобы получить то, что хотим, чтобы придать сайту газеты хороший вид. Особенно важно было отойти от шаблонов на главной странице, блогоподобного формата записи статей "новейшие в начале" (формата "река новостей", как Дэйв Винер бы назвал его).

Разметка главной страницы

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

Одним из очень важных аспектов, однако, было решение об использовании разметки на основе сетки. Типичный пример использования сеточной разметки - сайт NYTimes.com, но обновлённый сайт Timesonline.co.uk и, недавно, Guardian.co.uk являются заметными примерами другого подхода.

Основной разметкой, используемой для information.dk, является достаточно простая шестиколоночная сетка. Каждая колонка имеет ширину 140px (+ 20px промежуток между колонками), и они комбинируются всевозможными методами. На данный момент мы используем три различных ширины для содержания (в том числе для рекламы) на главной странице: 140px (один информационный модуль), 300px (два модуля + интервалы), и 460px (три модуля + интервалы). Основная колонка шаблона для раздела сайта и статьи имеет ширину 620px (четыре модуля + интервал).

Таким образом, как показано выше, главная страница состоит из трёх основных областей. В самом верху идут свежие статьи за сегодня (сюрприз!), и эта зона также является важной для всех и всего "свободной зоной", где мы показываем некоторые из наиболее динамичных разделов сайта (обновления блога, последние комментарии и т.д.) Средний раздел в основном предназначен для показа двух списков статей только для подписчиков. Идея здесь заключается в том, чтобы обеспечить наиболее простой обзор сегодняшних материалов. Нижний раздел в гораздо большей степени является "медленным" разделом, включающим в себя "Лучшее" - сборник луших статей. Разные принципы организации материалов существуют совместно на одной сетке.

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

Продолжаем разметку: Разделы и статьи

Сложность разметки главной страницы контрастировала с относительной простотой страниц основных разделов сайта и статей. Шаблон статьи был разработан таким образом, чтобы повысить удобочитаемости. Это было важно для нас, поскольку газета известна своими длительными углубленными статьями. Мы тратим много времени для нахождения правильного баланса шрифтов, размеров, различных выделений, а также на размещение изображений, внешних ссылок и т.д.

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

Разделы были довольно простыми (списки с разбивкой на страницы в нижней части), но требовали определенного внимания к тому, как статья представляется в качестве элемента списка. Мы используем автоматически обрезанные квадратные эскизы (когда доступно изображение), которые дают неожиданно хорошие результаты. С квадратной формой очень легко работать, и придаёт странице непротиворечивый вид, то, что в ином случае было бы трудно достигнуть, захоти мы интегрировать эскизы пейзажев и портретов в дизайне. Первоначально успешного использование Flickr'ом (и другими сайтами обмена фотографиями) квадратных эскизов натолкнул нас в этом направлении, и я подсчитал, что более 80% этих автоматически обрезанных изображений полностью пригодны к использованию. Что касается остальных, менее элегантно обрезанных эскизов, так было бы хорошо иметь простую встроенную функцию редактирования.

Напоследок: небольшой комментарий к разработке CSS-файлов в Drupal

Некоторые дизайнеры и составители CSS-файлов жаловались на то, как Drupal генерирует код. Такая простая вещь, как добавление списка в блок, и Drupal выплёвывает DIV-классы способные запутать кого угодно. Как избавиться от этого?

С моей точки зрения, есть две проблемы, связанные со стилем выходного кода Drupal. Одной из них является элегантность: множество разработчиков CSS хотят оставлять вещи достаточно простыми и чистыми, и Drupal со своим подходом "чем больше тем лучше" может вызвать немало разочарований. Ещё большее раздражение (О да, я еще до сих пор раздражён :-) вызвывает тот факт, что Drupal в некоторых отношениях заставляет вас отказаться от контроля. Вы не можете свободно определять имена идентификаторов и классов, вы не всегда можете контролировать, как именно будут организованы классы и суб-классы и, в некоторой степени, это может повлиять на иерархию классов, которую вы запланировали. В конце концов, эта относительная потеря контроля над кодом требует некоторого времени чтобы адаптироваться, особенно, если вы идете от простого образца к конечной вёрстке. На более практическом уровне, в силу того, что зачастую количество генерируемых идентификаторов DIV'ов и классов часто поражает, становится труднее правильно использовать иерархии, когда вы применяете стили к элементам. Это может привести к потере вида, что, конечно, очень разочаровывает, увеличивает ошибки и т.д. Это также делает такие вещи, как кросс-браузерность требующими больше времени.

Вначале мы пытались решить эту проблему с помощью программирования. Если генерируемый Drupal'ом код был или "слишком подробным", или "слишком отвратительным", чтобы работать с ним, мы хотели упростить код. Это, конечно же, не могло долго хорошо работать. Не только потому, что мы потратили бы слишком много времени на работу таким образом, мы также получили бы в конечном итоге систему, трудную в обновлении.

Единственным правильным решением этой проблемы было просто учиться и жить в стиле Drupal. Это не всегда может быть приятно, но если вы потратите достаточно времени, разрабатывая темы, вы в конечном итоге поймёте, как работать с кодом.

Передаём слово обратно Йохсу:

Актуальные проблемы

После того как мы успешно разрешили свои первоначальные мелкие ошибки и глупости, мы готовы взять на себя новые задачи.

Первое, что нам необходимо улучшить "Поиск". Мы нуждаемся в более развитых функциях поиска. Прямо сейчас поиск не заботится о скобках. Было бы неплохо иметь такую же, или, может быть, даже большую функциональность а-ля модуль Faceted Search.

Еще одна задумка заключается в том, чтобы предоставлять определенный тип дневного просмотра, так что вы сможете увидеть все статьи на определенный день в одном списке. Статьи имеют дату публикации (используется модуль Date), но сегодня на самом деле у нас нет "редакций". Это то что нам нужно будет сделать.

Наконец наш блог-сайт "luftskibet" установлен отдельно от основного сайта. Мы хотели бы - как графически, и не в последнюю очередь из-за пользователей - интегрировать эту установку с нашим главным сайтом, используя мультисайтинг.

Источник: Information.dk - Another Drupal Newspaper Site

Впечатления о Первом семинаре по CMS Drupal в России

Как я уже говорил, 24 апреля 2008 года я приехал в Москву на Первый семинар по CMS Drupal в России. Я выступал в роли докладчика, мой доклад называется "Drupal для stand-alone блоггинга и социальных сетей". Все подготовленные мной материалы (доклад и презентацию в формате Open Office) я приложил к этому посту. Читайте далее и узнайте о семинаре из первых уст! :)

Однако прежде чем продолжить, хочу выразить благодарность своей компании СтройИнжиниринг и лично директору Осипову Олегу Витальевичу за отправку меня командировкой на это значимое событие, в качестве докладчика, от лица отдела веб-разработок "Прометей". Также выражаю благодарность компании Мастерхост, благодаря которой всё это состоялось, и всем докладчикам и благодарным слушателям этого семинара - благодаря вам, всё прошло отлично. Спасибо докладчикам за интересные доклады, слушателям за интересные вопросы, и всем-всем-всем за чудесную атмосферу.

Отдельная и особая благодарность выносится Позднееву Александру и его семье за кавказское гостеприимство, лично Саше за неземную способность ориентироваться в Москве, вкусную еду (ну а это больше его маме), фотосъёмку во время конференции и услуги гида и проводника. :) Позднеич, без тебя моё пребывание в Москве было бы гораздо более скучным и рабочим, это точно.

Итак, теперь мои впечатления о событии. Сам семинар (или конференция, как я это мероприятие раньше называл) начался с вводного в Drupal доклада Александра Графова, и вся первая часть семинара до перерыва прошла, я бы сказал, с некоторым напряжением. Нам, как докладчикам, было непонятно, что за аудитория перед нами собралась и каковы её интересы и уровень знакомства с Drupal, и потому было непонятно, на чём же делать акцент. Слушателям, в свою очередь, было неясно, грубо говоря, разбегаться сейчас или подождать, может что ещё полезного скажут :). Лишь во второй части, после доклада Акжана Абдулова об особенностях хостинга под Drupal и во время доклада Александра Гоголева об особенностях поисковой оптимизации в Drupal, слушатели оживились и начали активно задавать вопросы, а дальше пошло-поехало.

Я замыкал первую часть семинара, мой доклад был последним до кофе-брейка. Честно говоря, я ориентировался больше на менеджеров и руководителей компаний, и когда готовил доклад, и когда его читал. Дело в том, что мой доклад был посвящён блоггингу и социальным сетям в Drupal, культура ведения корпоративных блогов у нас в России не развита, и я хотел докладом убить сразу несколько зайцев: протолкнуть среди руководителей компаний идею о корпоративном блоге, заинтересовать их системой Drupal как удобной и легко расширяемой платформой для построения блогов, показать на этом примере преимущества этой системы и, собственно, показать процесс создания блога на платформе Drupal. Для этого я вначале доклада сделал исторический экскурс в тему блогов и социальных сетей. Замечу, что дав почитать доклад одному руководителю, он сказал, что доклад интересный и что с удовольствием завёл бы блог вообще и на Drupal в частности. При этом он читал только первую часть и совершенно пропустил всё остальное (кусочки кода и детальное описание того, что надо сделать чтобы создать блог).

Однако, этот расчёт оказался неверным - т.к. собственно руководителей и менеджеров, а также топ-менеджеров, на мой субъективный взгляд, на семинаре оказалось меньшинство. Практически вся аудитория была технически подкована (особенно ярко я это понял после того, как попросил поднять руки всех, кто знает о технологии OpenID и больше двух третей зала подняли руки, тогда как у меня в Ульяновске, про это не знал практически никто) и уже понимала, почему блоги - это мейнстрим. Поэтому первая часть моего доклада, как мне кажется, прошла несколько скучновато, плюс ко всему, у меня оставалось мало времени. Во второй части доклада я постарался показать, как тот или иной модуль позволяет решить ту или иную проблему, и включал этот модуль. Совершенно не осталось времени на то, чтобы сообщить какие-то технические изыски, а жаль, т.к. таковые у меня были припасены, поэтому я поступаю следующим образом. Т.к. кроме презентации, я сделал обстоятельный доклад (как в общем-то, и положено докладчику), я выкладываю на своём блоге и презентацию, и доклад, в котором подробно расписаны некоторые моменты, и особенно - я бы хотел заострить на этом внимание, установку OpenID сервера. Также, я постепенно, по частям, опубликую этот доклад, возможно с некоторыми поправками, на этом блоге.

Также для себя сделал вывод, касающийся публичных выступлений - нужно больше спрашивать аудиторию, о том, что ей хотелось бы узнать и услышать от тебя, потому что... ну в общем, далеко не всё, что ты приготовил, аудитории актуально. Бывают поправки по ходу, порой достаточно серьёзные. Да и вообще, неплохо бы знать уровень и ожидаемый интерес тех людей, которые слушают тебя, это позволяет гораздо лучше расставить акценты и увеличить отдачу от собственного труда :) . Самое интересное, что во время репетиции доклада в Ульяновске, со мной случился тот же самый урок - вместо того, чтобы рассказать о блогах и установке блога на Drupal, я рассказывал о самом Drupal - т.е. не совсем о том, что я запланировал изначально, но то, что желала аудитория. Ну что ж, в первый раз не понял, во второй раз я уже нужные выводы сделал, спасибо семинару.

Также спасибо всем тем, кто обратился ко мне с вопросами после доклада, я был рад отвечать на ваши вопросы, и они помогли мне сориентироваться в потребностях блоггеров и новых тенденциях - подкастах - видео-, аудио-, и скринкастах.

Ну а теперь о выводах поразвёрнутей. Если честно, то не смотря на в целом успешное мероприятие, не вижу смысла проводить семинары часто, а тем более каждый месяц, как кто-то предлагал. Дело в том, что данные конференции должны носить глобальный характер, они должны формировать тенденции, в которых планируется работать дальше, определять направление развития. Раз в месяц можно проводить тусовки местного значения, чтобы рассказать о проделанной работе и испросить совета у бывалых. Не говоря уже о том, что каждый месяц никто из других городов приезжать не будет, а потому слишком частые мероприятия теряют свою уникальность, всеохватываемость и "всероссийскость", а потому обречены быть местной тусовкой. Ввиду всего вышесказанного, не вижу смысла проводить всеобщую конференцию чаще чем раз в год. Раз в год, но на несколько дней, и большим масштабом!

Это было о частоте и длительности сроков проведения, теперь немного об организации. Считаю, что данное мероприятие следует делить на секции, или группы - скажем, секция "Drupal в бизнесе" - и там читаются доклады для руководителей, топ-менеджеров и прочих достаточно далёких от технических подробностей людей, секция "Программирование в стиле Drupal" - рассказывает о создании модулей, развитии их и программировании под Drupal, а секция "Drupal для не-программистов" - позволит людям, не желающим возиться с программированием, узнать что-либо для себя полезное в плане построения сайтов на Drupal, не утопая в технических подробностях.

Третье. Я узнал много нового для себя на этом семинаре, особенно в том, что касается SEO и разработке собственных модулей. Буду стараться и дальше наращивать свой девелоперский потенциал, и как знать, может уже на Второй всероссийской конференции по Drupal буду делать доклад по этой теме. ;)

Конечно, этот мой отчёт получился каким-то суховатеньким, что никак не отражает тёплую атмосферу всего семинара, и особенно его неофициальной части в ресторане "Весёлый кружник". Огромные стойки с пивом, вкусная еда и интересный интерьер делали нас всех весьма общительными :) Андрею Постникову выражаю огромную уважуху за то, что приехал аж из самого Харькова, из Украины, и за помощь во время чтения моего доклада. Так же второй наш зарубежный герой - Андрей Подлюбный, приехавший из Европы, привет тебе и спасибо за неформальную встречу после семинара, надеюсь, будем работать. Конечно, спасибо Акселю за организацию и идеологическое вдохновение всех нас, его жене Нине за прекрасную улыбку и обаяние, она была практически единственной девушкой (ну, разумеется, не считая девушек - наших уважаемых организаторов - сотрудников Мастерхоста) на семинаре (была ещё одна девушка, она сидела в заднем ряду с белым ноутбуком на коленках, если ты, та самая девушка, сейчас читаешь этот пост, отзовись в комментах!), Акжану Абдуллову за расслабленное поведение и поддержку, как техническую так и моральную, и всем-всем-всем остальным, с кем, к сожалению не довелось не то, что пообщаться, а даже - в прямом смысле - перемолвиться словом :) Надеюсь, не в последний раз видимся, и -

Удачи и большое спасибо всем!

PS: Не забудьте сходить по рекомендованным мной ссылкам - вы получите впечатления о событии из первых рук докладчиков и слушателей, а кое-где и организаторов.

Как делали сайт журнала "Популярная наука" (Popular Science Magazine, PopSci.com)

Небольшое предисловие от меня. Я нашёл эту статью давно, на сайте drupal.org. Она оказалась очень полезной, и я думал, что её кто-нибудь переведёт. Однако этого не случилось, и я решил сделать это сам. Пусть эта статья будет ответом всем скептикам, которые не верят в Drupal - на самом деле, вы просто не умеете его готовить. Также, статья будет весьма полезна всем тем, кто планирует вести большие проекты на Drupal.

Статья породила множество комментариев и вопросов (на английском языке), авторы же любезно на них ответили. Пока что я просто читаю эти комментарии, и если найду их полезными и немного времени, то напишу статью-сборник из этих вопросов-ответов, переведённых на русский язык.

По итогам анализа разработки сайта для журнала "Популярная Наука", представленного на конференции DrupalCon 2008 в Бостоне Кевином Бриджесом (Kevin Bridges, cyberswat), Лаура Скотт и другие сотрудники pingVision вместе с Меган Миллер и Джоном Махони из PopSci.com, представляют исследование подходов к разработке сайта PopSci.com. Мы приветствуем Ваши вопросы и отзывы.

В феврале 2008, Popular Science, пятый старейший регулярно выпускаемый ежемесячный журнал, возобновил свое присутствие в Интернете с помощью сайта корпоративного уровня, основанного на Drupal и разработанного студией pingVision.

Основанный в 1872 году журнал Popular Science, являющийся журналом всего нового и перспективного, был свидетелем, сообщал и оценивал многочисленные научно-технические разработки, начиная со времени рассвета электроэнергии и заканчивая последними нововведениями сегодняшней информационной эпохи - достижений, которые легли в основу современного образа жизни, работы, игр, путешествий, общения, способов понимания и взаимодействия с миром. В самом деле, архивы журнала Popular Science отражают прогресс человечества за последние 135 с лишним лет.

До этого года, присутствие журнала Popular Science в Интернете обеспечивали по преимуществу проприетарные системы управления веб-контентом. При планировании этого обновления, команда журнала Popular Science хотела перевести управление онлайн-версией журнала в мир с открытым исходным кодом. Они приняли решение о Drupal в качестве веб-платформы и выбрали студию pingVision для разработки.

Ниже вы прочтёте краткий, "галопом по европам" обзор о том, как pingVision разрабатывала сайт для удовлетворения строгих требований сотрудников журнала Popular Science.

Цели и задачи сайта

До перезапуска, сайт журнала Popular Science использовал различные системы для публикации и управления содержанием сайта. Одна из целей нового сайта заключается в том, чтобы привести эти разрозненные сайты к единому пользовательскому интерфейсу вместе с повышением удобства использования и функциональности. Неотъемлемые качества Drupal - гибкость и расширяемость - отвечает поставленным журналом Popular Science функциональным требованиям и практичности. Одна из больших проблем была, однако, в преобразовании и импорте накопленного за несколько лет контента из CMS Vignette 7 и нескольких блогов TypePad.

Другой проблемой являлась интеграция сайта с несколькими сторонними сервисами, в том числе торговой системой ценных бумаг, видео сервисами и услугами хостинга, а также сервисами рекламы.

В ходе разработки нового сайта PopSci.com, мы воспользовались различными сторонними модулями, и создали ряд собственных модулей, в их числе - Drupal Markup Engine для отображения контента за пределами документов (нод) и Node Carousel для отображения контента.

Наконец, масштабируемость являлась главной задачей, так как PopSci уже имеет большую базу активных пользователей. Благодаря сбалансированной распределённой нагрузке на несколько серверов вычислительного кластера, на котором размещается сайт, в сочетании с использованием Memcache, PopSci.com после обновления смог выдержать нагрузку в среднем 60 страниц в секунду, с пиком из более чем 1,1 млн. просмотров страниц за 24 часа - новый рекорд для Popular Science.

Типы материалов (контента)

Для редакторов PopSci.com было важно, чтобы они полностью контролировали размещение материалов и могли бы управлять ими не только в режиме полного просмотра, но и в режиме анонса. Они хотели иметь возможность разбивать на страницы большие статьи и размещать любое количество изображений или просто связанных блоков в документе. Размещение материалов также должно было быть достаточно интеллектуальным, чтобы работать в режиме совместимости с контентом, импортируемым из Vignette и Typepad. Большинство из этих требований удалось добиться при создании нового модуля под названием Drupal Markup Engine, или DME. DME работает совместно с типами контента, которые были созданы для этого проекта с помощью модуля Content Construction Kit (CCK), предоставляя пользовательский, расширяемый фильтр ввода.

Статьи (Articles)

Статьи являются основным типом материалов на этом сайте. Все посты из блогов TypePad и статьи из Vignette были объединены как статьи в Drupal.

В статьях широко используется модуль DME. Изображения можно разместить в любом месте в статье, используя DME. Если явно не указано с помощью DME, где именно располагать картинку в теле статьи, она автоматически отображается в верхней части этой статьи и в режиме полного просмотра, и в режиме анонса.

Используя DME, изображения также могут быть размещены непосредственно для режима анонса. Такой подход обеспечивает максимальную гибкость работы с изображениями через Drupal, и с изображениями из наследуемого контента, который не потребует вмешательства человека, чтобы закончить обновление.

DME также используется для того, чтобы разместить блок со ссылками на похожие статьи (он будет содержать ссылки на материалы в полях CCK Node Reference, или материалы похожими терминами таксономии), на содержание и установить количество страниц для статьи.

Структура статьи

• Article Images -- поле Node Reference, указывающее на изображения, используемые в статье.
• Associated Photo Gallery -- поле Node Reference, указывающее на фотогалереи.
• Body -- тело статьи.
• Category Badge -- Изображение для таксономии, которое будет применяться в качестве графического значка этой статьи (типа бейджик).
• Credit -- Автор статьи.
• DEK -- краткое описание статьи.
• Primary Category -- термин первичной таксономии, для сайта представленной основными навигационными зонами.
• Related Articles -- поле Node Reference, предназначенное для размещения ссылок на схожие статьи.
• Tags -- поле для ввода тегов (обычное поле для ввода терминов словаря с автозаполнением).
• Title -- Название статьи (поле предоставлено ядром Drupal).
• V7id -- ID оригинальной статьи в CMS Vignette 7, таким образом, возможны перекрестные ссылки. Это было полезно для перенаправления старых ссылок на новое содержимое в Drupal. [См. дискуссию по поводу импорта ниже]
• Video Link -- поле Node Reference, указывающее на соответствующие видеоролики.

Свежий номер (Current Issue)

Тип материала "свежий номер" представляет собой номер журнала. Он используется для хранения изображений обложек журналов вместе с их датами. Этот тип материалов используется в различных промо-материалах на всём сайте.

Структура свежего номера

• Cover -- изображение, представляющее обложку журнала.
• Issue Date -- дата публикации этого номера.
• Title -- название (поле предоставлено ядром Drupal).

Похожее (Featured Tout)

Featured Tout является типом материалов, созданным для использования исключительно в модуле Node Carousel, управляемым в свою очередь Node Queue. Featured Tout просто требует от редакторов журнала Popular Science создать графику соответствующего размера. Это можно увидеть на главной странице http://popsci.com/.

Структура Featured Tout

• Associated Article -- поле Node Reference, указывающее на "расхваливаемую" статью.
• DEK -- краткое описание этой статьи.
• Index Display Link -- слово, используемое в качестве ссылки.
• Title -- Название (поле предоставлено ядром Drupal).

Изображения (Images)

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

Структура изображений

• Credit -- автор изображения.
• DEK -- краткое описание изображения.
• Photo Gallery Link -- поле Node Reference, указывающее на фотогалерею. Если изображение ссылается на галерею, оно проявляется в этой фотогалерее.
• Photo Gallery Weights -- Это поле содержит последовательность пар чисел, где каждая пара представляет фотогалерею и вес изображения в этой фотогалерее.
• Primary Category -- термин первичной таксономии, для сайта представленной основными навигационными зонами.
• Title -- Название статьи (поле предоставлено ядром Drupal).
• V7id -- ID оригинального изображения в CMS Vignette 7, таким образом, возможны перекрестные ссылки. Это было полезно для перенаправления старых ссылок на новое содержимое в Drupal. [См. дискуссию по поводу импорта ниже]
• Video Link -- поле Node Reference, указывающее на соответствующие видеоролики.

Фотогалерея (Photo Gallery)

Фотогалерея является типом материалов, предназначенный для сбора изображений и материалов, которые будут отображаться для конечного пользователя в качестве фотогалереи. Изображения присоединяются к фотогалерее путём редактирования изображения - нужно ввести название галереи в соответствующем поле Node Reference. Галереи представлены в виде Node Carousels, что придаёт им глянцевости и интерактивности.

Структура фотогалереи

• Category Badge -- Изображение для таксономии, которое будет применяться в качестве графического значка этой галереи (типа бейджик).
• Credit -- Автор галереи.
• DEK -- краткое описание галереи.
• Icon -- поле Node Reference, указывающее на картинку, которая используется во время просмтора анонса галереи.
• Primary Category -- термин первичной таксономии, для сайта представленной основными навигационными зонами.
• Tags -- поле для ввода тегов (обычное поле для ввода терминов словаря с автозаполнением).
• Title -- Название галереи (поле предоставлено ядром Drupal).
• V7id -- ID оригинальной галереи в CMS Vignette 7, таким образом, возможны перекрестные ссылки. Это было полезно для перенаправления старых ссылок на новое содержимое в Drupal. [См. дискуссию по поводу импорта ниже]

Пользовательское Видео (User Video)

Материал типа Video позволяет размещать видеоролики на сервисах YouTube и OnStream. Мы разработали собственный медиа-модуль, который создает поле CCK Media Profile, которое может быть прикреплено к любому документу, что позволяет редакторам и администраторам ограничивать используемые сервисы на основе типа материала.

Собственный медиа-модуль отличается от существующего модуля Embedded Media Field тем, что предоставляет большую гибкость - например, позволяя пользователям загружать видео на сервисы прямо из Drupal.

Структура Video

• Category Badge -- Изображение для таксономии, которое будет применяться в качестве графического значка этого видео (типа бейджик).
• Credit -- автор видео.
• DEK -- краткое описание видео.
• Primary Category -- термин первичной таксономии, для сайта представленной основными навигационными зонами.
• Tags -- поле для ввода тегов (обычное поле для ввода терминов словаря с автозаполнением).
• Title -- Название видео (поле предоставлено ядром Drupal).
• Video Link -- Размещённое видео через расширение файла привязывается к медиа-модулю.

Импорт данных

Часть мотивации, чтобы переместить существующее содержимое в Drupal заключалась в том, чтобы избежать возрастающей сложности и расходов, связанных с CMS Vignette. Набор данных для Vignette занимал 1.66GB базы данных на Oracle, - и это не включая более 15000 изображений, размещённых в документах Vignette, которые также должны были быть импортированы в новый сайт.

Первый шаг в процессе миграции состоял в том, чтобы использовать MySQL Migration Toolkit для передачи данных в MySQL. Мы написали собственный модуль, который использует cron (запуск скриптов по расписанию), чтобы пропустить данные из БД Oracle через API Drupal, деля их на приемлемые куски. И, наконец, мы импортировали изображения путем извлечения их ссылок из БД Oracle, и через шелл-скрипт выполняя ряд команд wget, чтобы загрузить изображения.

Каждый документ, импортированный в Drupal, был помечен тегами с помощью модуля Yahoo Terms, который, несмотря на некоторые нерегулярные результаты, сделал хорошие стартовые метки для огромного количества не помеченных данных из CMS Vignette.

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

Некоторое время в процессе импорта было посвящено работе со ссылками, которые были сгенерированы CMS Vignette, для того, чтобы статьи, привзанные к своему старому адресу от CMS Vignette, можно найти в новой архитектуре Drupal. Для того чтобы добиться этого, в ходе импорта мы взяли соответствующий Vignette ID для каждой единицы информации, импортируемой из Vignette в Drupal, и разместили его в специально заведённом для этого поле CCK конечного документа Drupal. Чтобы найти эти статьи в Drupal, был написан хук, который работает с модулем Custom Error, он ищет старый Vignette ID в строке URL, когда возникает 404 ошибка, и возвращает корректный код переадресации. Не только здесь мы использовали редирект, до тех пор пока использовались старые ссылки, но в очень короткое время Google обновил свои результаты поиска с указанием новых путей.

Поиск

Конструкция и дизайн результатов поиска на PopSci требовала того, чтобы результаты поиска были сгруппированы по типу материала, с закладками, позволяющими отсортировать результаты по релевантности, времени добавления, количеству просмотров, рейтингу, и количеству комментариев. Кроме того, пользователи должны иметь возможность подписки на rss-ленты с результатами.

Мы достигли этой функциональности путем разработки расширенной версии стандартного модуля поиска Drupal, отображения различных результатов в блоках разбитого на страницы контента, с AJAX-вкладками для доступа к другим сортировкам результатов поиска.

Каждый поиск кешируется, ему присвается хэшированный номер (ID), и связывается с пользователем, выполнившим этот поиск, позволяя сберегать время поиска в будущем.

AJAX-вкладки (AJAX Tabs)

Во многих случаях дизайнерские работы, что мы получали, требовали сделать вложенный набор вкладок (табов), которые могли бы функционировать как фильтр того материала, который отображается на определенной странице. Это было в значительной степени реализовано с помощью компонента Tabs из модуля Javascript Tools. Вместе с тем, для вкладок с большими объёмами данных, отображаемых на главных страницах основных категорий и в результатах поиска, необходимо было собственное решение (оптимизированный код), чтобы иметь возможность работать и реагировать быстро при больших объемах данных.

Производительность

Естественно, был произведён тщательный отбор аппаратного обеспечения для размещения сайта журнала Popular Science, но настоящим лидером оптимизации этого проекта стал модуль Memcache, который интегрирует Drupal с Memcached и библиотекой PECL Memcache. Прямо "из коробки", этот модуль работал очень хорошо для нас, за исключением работы с псевдонимами URL: полная загрузка страницы генерировала больше 700 запросов для определения псевдонимов URL. Направление этих запросов через Memcache дало нам необходимую скорость, чтобы сохранить первоначальную среднюю нагрузку в примерно 60-70 просмотров страниц в секунду.

Модули, разработанные сообществом

Подлинная мощь Drupal заключается в людях, которые участвуют в этом проекте. Эти модули были предоставлены со стороны сообщества и помогли сделать работу, которую мы сделали, возможной:

• Администрирование
  • Abuse -- позволяет пользователям помечать материалы и комментарии к ним, как оскорбительные, для последуещего просмотра администратором.
  • Avatar Approval -- создает рабочий процесс для модерации пользовательских аватаров.
  • Custom Error -- позволяет администратору сайта создавать собственные страницы ошибок для ситуаций 404 (не найдено), и 403 (отказано в доступе), без необходимости создания документов для каждой из них.
  • JQuery Update -- упрощает модернизацию jQuery в Drupal 5. JQuery 1.0.1 входит в Drupal 5, однако он не очень хорошо поддерживается в сообществе jQuery.
  • Path Auto -- автоматически генерирует синоним URL для различных видов содержания (документов, категорий, пользователей), не требуя от пользователя вручную указывать путь для синонима.
  • Update Status -- проверяет один раз в день сайт drupal.org, чтобы узнать, существуют ли новые официально опубликованные версии Drupal и любых модулей, которые вы используете.
  • URL List -- создает список URL-адресов документов в виде /q=urllist.txt (или /urllist.txt для чистых URL) для последующей отправки в поисковые системы, такие, как Yahoo! Site Explorer.
• Пользователи: доступ и аутентификация
  • Account Reminder -- посылает заново приветственное письмо для пользователей, которые зарегистрировались на сайте, но пока еще не вошли в систему.
  • Login Toboggan -- предлагает ряд изменений в системе управления пользователями Drupal во внешнем модуле.
• CCK
  • Content Construction Kit ( CCK ) -- позволяет Вам создавать и настраивать поля к документам с помощью веб-браузера.
  • CCK Taxonomy Fields -- словари таксономии будут отображаться как поля, которые могут быть добавлены к типам материалов, используя CCK.
  • Date -- гибкое поле "дата/время" для модуля CCK.
  • Fivestar -- добавляет чистый, привлекательный виджет голосования в документы (ноды) Drupal 5.
  • ImageField -- обеспечивает загрузку изображений для CCK.
  • Link -- предоставляет поле CCK, которое позволяет добавить полную ссылку на ваш тип материала.
• Коммерция/реклама
  • AdSense -- предоставляет владельцам сайта средства, чтобы заработать прибыль от посетителей, размещая объявления от компании Google AdSense или SiteSearch на своих сайтах.
• Разработчик
  • API -- реализация генератора спецификаций и документации Doxygen, настроенный для выдачи в соответствии с основным кодом Drupal.
  • Coder -- позволяет просматривать код и помогает при обновлениях.
  • DBA -- предоставляет администраторам Drupal прямой доступ к таблицам базы данных Drupal из стандартного пользовательского интерфейса Drupal.
  • Devel -- набор модулей, содержащий полезные утилиты для разработчиков модулей и тем.
  • Javascript Tools -- предлагает интегрированный набор Javascript- и AJAX-модулей и общий набор методов для расширения тех возможностей, которые имеются в ядре Drupal (drupal.js) для разработки Javascript- и AJAX-модулей под Drupal.
  • Simple Test -- фреймворк для автоматизированного запуска тестов модулей в Drupal.
• Фильтры ввода/редакторы
  • Filter by node type -- Позволяет администратору ограничивать, какой фильтр ввода доступен для пользователя, через редактирование прав доступа для роли пользователя. Модуль, однако, не позволяет администраторам задавать форматы ввода отдельно для каждого типа материалов.
  • HTML Corrector -- корректирует HTML-код, введённый в поле ввода материала.
• Медиа
  • ImageCache -- инструмент для динамической обработки и кэширования изображений.
  • Taxonomy Image -- позволяет администраторам сайта связывать изображение с термином таксономии.
• Безопасность
  • CAPTCHA -- простой тест в виде "вопрос-ответ", наиболее часто помещаемый в веб-формах, для того, чтобы определить, является ли посетитель сайта человеком или роботом.
• Интеграция со сторонними продуктами
  • Import Typepad / MoveableType -- позволяет импортировать TypePad-контент, из файла-экспорта TypePad.
  • Memcahce -- для совместного использования Memcached и библиотеки PECL Memcache с Drupal.
  • Omniture -- интегрирует систему мониторинга статистики Omniture Site Catalyst с Drupal-сайтом.
  • Service Links -- позволяет администраторам добавить ссылки на ряд таких социальных сервисов, как сайты социальных закладок, сайты для поиска по блогам и т.д.
  • XML Sitemap -- создаёт карту сайта в соответствии со спецификациями sitemaps.org.
  • Yahoo Terms -- предоставляет другим модулями интерфейс для использования сервиса Yahoo Term Extractor.
• Почта
  • Mime Mail -- модуль для компонента Mime Mail.
  • Send -- добавляет возможность (ссылку) "сообщить другу" для любого типа материалов, отслеживает свои действия в системе CiviCRM (если она установлена), и ведет историю отправленных элементов.
• Отображение содержимого
  • Node Carousel -- простой в использовании способ отображения документов, используя библиотеку jCarousel для jQuery.
  • Node Queue -- позволяет администратору произвольно добавлять документы в группы, для любых целей.
  • Site Map -- предоставляет карту сайта, которая даёт посетителям общее представление о вашем сайте.
  • Views -- представляет собой гибкий метод для разработчиков Drupal-сайтов контролировать, как будут представлены списки материалов.
  • Views Bookmark -- гибкая система закладок, которая может полностью настраивается администратором.
• Содержимое
  • Meta Tags -- позволяет вам установить некоторые метатеги отдельно для каждого документа, какого-либо вида (элемента модуля Views) или страниц, сгенерированных с помощью модуля Panels.
  • Scheduler -- позволяет опубликовывать и снимать с публикации документы в указанное время.
  • Similar Terms -- пытается определить смысл, контекст документа, показывая блок со ссылками на другие материалы схожего содержания.
• Связанные с темами модули
  • Simple Menu -- создаёт меню, которое отображается в верхней части каждой страницы.
• Утилита
  • Token -- токены (лексемы) - это маленькие кусочки текста, которые могут быть помещены в более крупные документы через простые обозначения, например такие, как %site-name или [user].
• Оценка/рейтинг
  • Voting API -- помогает разработчикам, которые хотят использовать стандартизированное API и методы для хранения, поиска, и сведения голосов, отданных за тот или иной документ Drupal.

Источник: Popular Science Magazine (PopSci.com) Case Study

Мой блог переехал с WordPress на Drupal

После почти что полутора месяцев тестинга, перевел свой сайт с Вордпресса на Друпал. Вызвано это тем, что начал активно изучать CMS и CMF системы, и Друпал приглянулся своей логичностью, простотой и продуманностью. Надо сказать, что Вордпресс тоже ничего, но на мой взгляд у Друпала гораздо шире спектр возможностей, особенно мне нравится возможность устроить мультисайтинг, а также возможность тюнинга под самые разные задачи.

Сам переезд занял четверо суток :) И это была задача не из лёгких.

Но обо всем немного позже....

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

Порывшись в каталоге модулей для Друпала - http://drupal.org/project/Modules/category/64 , я нашёл то что мне нужно - модуль перехода с Wordpress на Drupal. Он называется wp2drupal, взять его можно с блога автора Borek Bernard.

Однако он был написан для Друпал версии 4.7, и напрочь отказывался запускаться под 5.1. Почитав тему на официальном сайте, посвящённую wp2drupal, оказалось, что в модуле находятся ошибки, на которые добрые люди написали патчи.

В этой же теме лежали работы, посвящённые переводу этого модуля под 5.1 версию Друпала.

Должен заметить, что мне так и не удалось запустить этот модуль под 5.1 версией. Я установил версию 4.7, импортировал данные из базы данных Вордпресса, и затем получившиеся таблицы импортировал в Друпал, практически в неизменном виде. Единственное, пришлось подправить значения некоторых ссылок на ноды: т.к. у меня путь к посту складывался из имени категории и имени самого поста, а также поправить таблицу sequences вручную, чтобы она содержала данные, соответствующие импортированным записям.

Ещё одна засада, как оказалось, скрывалась в том, что модуль wp2drupal использует PHP 5, и мне пришлось ставить себе на локальную машину PHP 5 чтобы запустить модуль. Это, кстати, было одной из причин, почему я не стал ставить этот модуль на хостинге - у меня на хостинге на момент написания этой статьи PHP 4.

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

Ну что ж, вы не испугались, были предупреждены обо всём (или почти обо всём) и до сих пор сохранили желание переехать. Тогда, слушайте - процедура такая:

1. Качаем Друпал 4.7.
2. Качаем модуль wp2drupal и немного правим его под свои нужды.
3. Включаем модули blog, path, wp2drupal, если ещё не включены.
4. Осуществляем перенос.
5. Обновляем таблицы в своей версии Друпала 5.1
6. Правим таблицу sequences в своей версии Друпала 5.1.

Для особо ленивых я привожу файл, распаковав который, Вы получите Друпал 4.7 и установленный и уже поправленный мной модуль wp2drupal. После установки Друпала 4.7 на Вашу машину (залив дамп базы данных и произведя необходимые настройки - включение модулей path и wp2drupal), вы сможете сразу же импортировать свою базу Вордпресса.

Рекомендую, конечно, сначала все делать на своей локальной тестовой машине, и только потом - на хостинге. Я же лично на хостинге не устанавливал Drupal 4.7, только импортировал уже готовые таблицы с локальной машины.

Скачать drupal4_7withwp2drupal.7z

PS. Если будут какие-то вопросы, задавайте здесь в комментариях - отвечу.
PPS. Нашёл ещё один модуль, посвящённый переезду с Wordpress на Drupal. Называется Wordpress Import. Зарелизен 4 января 2008 года.

Мультисайтинг на Друпале - это круто!

Импульсом к написанию этой статьи стала потребность в мультисайтинге, идеей чего я озаботился сразу после прочтения статей

Мультисайтинг – как и зачем , автор jerboa7,
Мультисайтинг - это просто, автор Макс Кириленко,
а чуть позже к ним присоединился и Mультисайтинг. В который раз. :) автора andron13

и усвоил мысль, что если хочешь потом сделать мультисайтинг, то лучше его делать сразу.

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

1. Установка Друпал
Паркуем на хостинг наш домен сайт1. Этот домен будет указывать на какую-то директорию на Вашем сайте, которая для него будет являться базовой. В эту директорию на хостинге копируем Друпал - распаковываем его из архива.
Заводим новую БД на хостинге. Её будет использовать Друпал. Завели? Теперь у нас есть База Данных:

Имя БД: БД_сайт1
Пользователь БД: юзер_БД_сайт1
Пароль пользователя: пароль_БД_сайт1

У пользователя юзер_БД_сайт1, само собой, должны быть выставлены привелегии, позволяющие ему полный доступ к базе данных БД_сайт1.

Также у Вас есть файл settings.php, находящийся в подпапке sites/default/settings.php. В нем прописываются все необходимые параметры базы данных, нужные для работы Друпал. Заполните его, в соответствии с инструкциями, расположенными в нем в комментариях, и описанными ниже.

Строка доступа к базе данных, выглядит так:


$db_url = 'mysql://юзер_БД_сайт1:пароль_БД_сайт1@localhost/БД_сайт1';


Еще мы должны задать префикс таблиц. Это означает, в самом простом случае, что к имени таблицы в БД будет приписываться в начале некий префикс:


$db_prefix = 'префикссайт1_';


т.е. таблица с именем, скажем, sequences будет префикссайт1_sequences. Я рекомендую в конце префикса ставить знак подчёркивания "_", чтобы отделять префикс от собственно имени таблицы.

Префикс можно не задавать:


$db_prefix = '';


однако я не рекомендую этого делать. Подумайте о возможной SQL атаке? Или просто о попытках взломать ваш сервер. Хакеру не трудно будет догадаться, что Вы используете Друпал. Ну а с какими именами Друпал создаёт таблицы, тоже хорошо всем известно. Поэтому Вы затрудните доступ к Вашим таблицам, если вначале каждой пропишите префикс из случайной последовательности символов.

А теперь информация для самых ретивых: задавая префикс таблиц не в виде


$db_prefix = 'префикссайт1_';


а в виде


$db_prefix = 'префикссайт1.';


Вы на самом деле указываете Друпал, что он должен обращаться к базе данных "префикссайт1", вместо БД_сайт1! Поэтому будьте предусмотрительны при выборе разделителя префикса и имени таблицы. Самое удобное, на мой взгляд, использовать "_" - знак подчёркивания.

Однако и это ещё не все о префиксах. Друпал позволяет для каждой из таблиц задать отдельный префикс. Выглядит это так:


$db_prefix = array (
'default' => 'main_',
'users' => 'shared_',
'sessions' => 'shared_',
'role' => 'shared_',
'authmap' => 'shared_',
'sequences' => 'shared_',
);


Зачем это надо? Если Вы ставите 1 сайт и уверены, что больше Вам никогда не понадобиться, то не забивайте себе голову. Ну позволяет это Друпал, ну и позволяет, Вам-то что?

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

Итак, сайт1 мы поставили, запустили, работает - все замечательно! И вот в один прекрасный день...

2. Возникает потребность в новом сайте на Друпале, хотим организовать его на том же хостинге. Имя сайта - сайт2.
Паркуем на хостинг наш новый домен сайт2. Домен должен указывать на ту директорию, в которую вы ранее скопировали/поставили Друпал (в нашем примере - на директорию с сайт1).

Если после парковки домена при переходе на него мы попадаем на сайт1. (Так должно быть, если этого не происходит, значит что-то сделано не так.)

Создаём директорию sites/сайт2, копируем в него файл settings.php и правим его в соответствии с нуждами нашего сайт2:

задаем параметры доступа к БД,
прописываем другой (не такой как у сайт1) префикс таблиц для сайт2.

Переходим опять по нашему новому адресу сайт2 - и видим, что Друпал сыпется ошибками. И правильно, ведь никаких таблиц в БД сейчас нет. В БД сейчас есть только таблицы для сайт1. Друпал думает, что у нас уже установлен сайт2, и пытается сгенерировать главную страницу, но обламывается. Вот так вот, сгенерив страницу с ошибками, Друпал кэширует её. Если вы попробуете перейти опять по новому адресу, то увидите страницу с ошибками опять. Однако нам пока главная страница не нужна.

Перейдём на страницу установки Друпала для сайта2, т.е. перейдем на сайт2/install.php - скрипт установки отработает, создав нужные таблицы и прописав все необходимые связи между ними. Если какие-то таблицы уже существуют, они перезаписаны не будут, и никаких повреждений в них не будет, однако Друпал сообщит об ошибке при создании этих таблиц.

Перейдём на главную страницу свежесозданного сайта - сайт2. Видим опять всяческие сообщения об ошибке. Это отображается закэшированная ранее страница. Обновите ее - и о чудо! - видим первую страницу Друпала для сайта2 с инструкциями.

Т.е. у нас получилось два сайта, использующие одни и те же скрипты и одну и ту же БД, но разные таблицы в БД. Очень удобно.

А теперь помните, что если бы в качестве разделителя префикса таблиц указали не знак подчёркивания, "_", а точку - ".", то Друпал обращался бы не к базе данных "БД_сайт1", а к базе "префикссайт2"? Это можно использовать, если вы хотите чтобы для разных сайтов использовалась разная БД, но был один и тот же пользователь БД и пароль (такая задача часто возникает при объединении таблиц, о чем речь пойдёт дальше). Конечно можно просто задать разные параметры для БД для сайт2.

Но давайте представим, что у Вас...

3. Возникает понимание, что некоторую информацию сайта1 и сайта2 неплохо бы объединить. Например сделать общих пользователей.

Вот здесь-то и проявляется вся гибкость и мощь Друпала, здесь-то мы и осознаем в полной мере, насколько удобно задавать разным таблицам разные префиксы, и как Друпал умеет работать с разными БД.

Сделать общим можно все! Начиная от пользователей и заканчивая документами (нодами). Но если общих пользователей я ещё могу понять и принять, то делать общие документы между сайтами я не вижу смысла - тогда чем будет отличаться один сайт от другого? Только дизайном? Поэтому, после некоторого тестинга, я пришёл к выводу, что объединить без ущерба нарушения целостности БД и психики можно:

1. Пользователей,
2. Роли пользователей и права ролей
3. Профили пользователей
4. Переводы ядра и модулей
5. Словари
6. Термины в словарях
7. Фильтры сообщений - насчет этого уже не уверен, т.к. таблица filter_formats привязывается к кэшу (поле cash), а таблица filters использует id фильтра из таблицы filter_formats, таким образом, обе таблицы фильтров привязаны к конкретному сайту.

Т.е. вообще все таблицы и модули, в которых нет жёсткой привязки к документам (нодам).

Также сразу скажу, что задача объединения словарей и терминов в них (модуль таксономии) может возникнуть только на очень тесных и близких по тематике сайтах. Я объединил словари и попробовал использовать в таком режиме документы, это оказалось очень неудобным и нецелесообразным. Поэтому мы не будем это рассматривать в этой статье. Остальные же вещи, удалось объединить очень даже удобно.

Итак, чтобы сделать общих пользователей, нам нужно сделать для сайтов общие таблицы пользователей. Допустим, что у нас уже есть сайт1, и новый сайт сайт2, и мы осознали что неплохо было бы, если пользователь зарегистрировался на каком-либо из этих сайтов, имел бы доступ и к другому.

За пользователей у нас в Друпале отвечают следующие таблицы:

'authmap'
'sessions'
'sequences'
'users'

Таблица users - непосредственно хранит данные пользователя.
Таблица sequences - хранит служебную информацию Друпал. Для каждой таблицы, в sequences сохраняется её имя, и следующее значение первичного ключа. (Если вообще планируете сделать что-то общее для каких-то двух сайтов, таблицу sequences рекомендую делать общей при любом раскладе).
Таблица sessions хранит информацию текущих сессий пользователя.
Таблица authmap я не знаю пока чего хранит.

Помимо вышеперечисленных таблиц, для пользователей существуют роли:

'role'
'users_roles'

При этом в таблице role хранится для каждого сайта информация о ролях пользователей, а в таблице users_roles - информация, какой пользователь к какой группе (роли) принадлежит. Скажу сразу, что если Вы хотите сделать так, чтобы роли для каждого сайта были абсолютно независимы, то Вам не нужно делать общей таблицу role. Таблицу users_roles можно сделать общей, если Вы делаете общих пользователей. Я же, потестив немного, нашёл, что очень удобно когда роли пользователей общие для всех сайтов, т.к. не нужно по 10, или сколько у вас там сайтов, раз заводить одни и те же роли: вот этим пользователям можно то, а этим это.

Profile module. Если у Вас включён модуль профилей для пользователей, тогда его таблицы тоже имеет смысл сделать общими:

'profile_fields' - хранит информацию о полях профиля
'profile_values' - хранит информацию поля.

Locale module. Модуль локализации. Одна из удобнейших возможностей - использовать общую таблицу локализации, т.к. переводы всего и вся можно залить один раз и потом просто выбирать из админки нужного сайта.

'locales_meta'
'locales_source'
'locales_target'

BUEditor Module. Это я привел чисто для примера. Любой модуль, не использующий привязку к документам, может быть объединён. Строго говоря, то же верно и для любого модуля, жёстко привязанного к документам, просто в нем надо найти таблицу связей для модуля и документов, и не делать её общей. Для модуля BUEditor таких таблиц нет, поэтому смело объединяем:

'bueditor_buttons'
'bueditor_editors'

Что нужно, чтобы использовать на сайт2 эти таблицы, которые уже поставлены и работают для сайт1? Ответ очень прост: надо просто прописать префикс сайт1 для этих таблиц: "префикссайт1_", в файле настроек settings.php для сайт2:

$db_prefix = array (
'default' => 'main_',
'authmap' => 'префикссайт1_',
'sessions' => 'префикссайт1_',
'sequences' => 'префикссайт1_',
'users' => 'префикссайт1_' и т.д. если объединять будете что либо кроме пользователей.


Также, сайт1 и сайт2 должны использовать одну и ту же БД.

Теперь из админки сайт2 доступны пользователи (и еще что-нибудь, если еще что-нибудь объединяли) сайт1. И пользователи на сайтах общие.

Всё!

Ах да... еще одна деталь. Если Вы будете мультисайтить большое количество сайтов, то для этого может быть целесообразно разделить сайты по разным базам данных. В этом случае схема будет такой: создаем столько баз данных, сколько у нас сайтов, и еще одну общую (shared) и при этом пользователь для всех этих БД должен быть один и тот же. В качестве префиксов указываем префиксы с точкой, например так: "сайт1.". Т.е. в нашем случае можно сделать так:

БД с именем shared (общая для всех сайтов) -

'authmap'
'sessions'
'sequences'
'users'
'role'
'users_roles'
'profile_fields'
'profile_values'
'locales_meta'
'locales_source'
'locales_target'
'bueditor_buttons'
'bueditor_editors'

БД с именем сайт1 (БД для сайт1) -
содержит все таблицы, кроме тех, что в таблице shared
БД с именем сайт2 (БД для сайт2) -
содержит все таблицы, кроме тех, что в таблице shared

В файле settings.php Вы прописываете значения (для сайт1):

$db_url = 'mysql://юзер_БД:пароль_БД@localhost/сайт1';
$db_prefix = array (
'default' => 'сайт1.',
'authmap' => 'shared.',
'sessions' => 'shared.',
'sequences' => 'shared.',
'users' => 'shared.',
//Роли общие
'role' => 'shared.',
'users_roles' => 'shared.',
//Profile module
'profile_fields' => 'shared.',
'profile_values' => 'shared.',

//Locale module :
'locales_meta' => 'shared.',
'locales_source' => 'shared.',
'locales_target' => 'shared.',
//BUEditor Module :
'bueditor_buttons' => 'shared.',
'bueditor_editors' => 'shared.'
);

Первая Всероссийская Конференция по CMS Drupal и всё такое :)

Друзья, спешу сообщить, что я еду докладчиком на Первую Всероссийскую Конференцию по CMS Drupal. Долго готовился к докладу по теме "Drupal для stand-alone блоггинга и социальных сетей", потому записей в блоге не делал. Сразу после того, как вернусь домой, опубликую доклад и презентацию у себя на блоге, также все материалы конференции будут выложены в открытый доступ на Друпал.ру и сайте спонсора акции - компании "Мастерхост".

Примерно через час у меня поезд, а завтра я сразу с вокзала и на конференцию. Хорошим темпом идёте, товарищи! :)

Из того, что накопилось. Сегодня тщетно пытался сдать налоговую отчётность в бумажном виде в своей налоговой. Не принимают. Однако прямо из налоговой инспекции можно за деньги сдать декларацию через интернет им же. Вот скоты всё-таки, а? Не знают, как ещё можно облегчить себе работу по высасыванию средств из карманов граждан. Консультант сказал, что из Москвы спустили приказ, чтобы всех предпринимателей посадить на сдачу деклараций через интернет. На вопрос "А можно ли сдать по почте?" уклончиво отвечают что желательно всё-таки через интернет, а на вопрос сообщить номер закона, по которому они не принимают отчётность в бумажном виде, ответили, что такого закона нет.

Ну ладно, это всё лирические отступления, и хрен с ними, мне же пора схватить сумку и бежать на поезд.

Увидимся :)

Сенат Штата Нью-Йорк - новый сайт на Drupal

После победы на выборах в Сенат Штата Нью-Йорк, впервые за почти 50 лет, Демократическая партия обратились к Advomatic с просьбой быстро развернуть новый сайт на Drupal. Были многочисленные проблемы, которые предстояло преодолеть, и их требования заставляли выйти за грани возможного в некоторых областях, таких, как разграничение прав доступа и общий порядок действий (workflow). В конце концов, этот сайт, является свидетельством того, что может быть достигнуто командой разработчиков, путем целенаправленной разработки и экспериментирования, используя мощность и гибкость Drupal и его сообщества.

Мультисайтовая структура

Ранее, каждый сенатор контролировал свою собственную маленькую вотчину в сети (часть одного сайта), используя проприетарный, написанный на ASP сайт, со слабыми связями между частями. Сенат хотел продолжить эту практику, т.е. сенаторы по-прежнему должны были контролировать свои собственные подсайты, однако их содержимое должно было проще разделяться между сайтами, и чтобы была возможность размещать выбранные статьи отдельных сенаторов в основном разделе сайта.

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

Мы просмотрели несколько предлагаемых решений и модулей, позволяющих развернуть такой сайт, и в итоге решили реализовать собственный метод, похожий на тот, что мы применили для Air America Radio, по причине уникальных требований. Это решение состояло в создании типа материала "Сенатор" ("Senator"), на который могут ссылаться все другие типы материалов, и эта ссылка будет использоваться для группировки. Например, раздел сайта, посвященный сенатору Малькому А. Смиту (Malcom A. Smith) группирует все его материалы, со специальным заголовком, специализированным навигационным меню, блогом и т.д.

Дизайн, созданный нашими дорогими Амандой Люкер и Джеком Хаазом (Amanda Luker and Jack Haas), аппелировал к двум основным темам, в зависимости от принадлежности к партии. Мы просто добавили выпадающее поле с вариантами "Синий" и "Красный", первоначально с целью включения этой информации в глобальную переменную $custom_theme по мере необходимости. В конце концов мы решили просто печатать это значение в css-классе для тега body, так как было проще переключать оформление с помощью CSS, чем использовать две разные темы. Мы использовали Cufon для замены изображений на сайте.

Навигационное меню

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

В конце концов, мы решили использовать поле Link для меню, которое будет напечатано путем переопределения $vars['primary_links'] в phptemplate_preprocess_page(). Тогда мы просто проверяем путь, чтобы увидеть, находимся ли мы на странице, ссылающейся на сенатора, и в этом случае делаем переопределение. Мы также реализовали токен для этого, так что мы можем заполнить меню такими полезным путями по умолчанию, как, например, [senator]/blog и [senator]/gallery.

Так как было много других случаев, для которых нам необходимо было знать, загружается ли специфическая страница, ссылающаяся на сенатора, мы положили все отслеженные аргументы в статическую переменную во время выполнения hook_init(), так что мы легко смогли бы обнаружить этот случай: вызов nyss_senator() возвращает либо FALSE, либо ссылающуюся на сенатора ноду.

Миграция данных

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

Первоначальные данные были в базе данных Microsoft Access, что принесло ряд проблем при миграции. Во-первых, первоначальный дамп базы данных был поврежден, поэтому при миграции около трех четвертей всего контента вернулось со странными символами. После изучения ситуации, почему апострофы превращаются в символ a€™  (помимо всего прочего), мы узнали, что данные были повреждены, когда первоначальный продавец делал бекап базы данных. Как правило, функция PHP iconv() смогла бы преобразовать из кодировки Latin-1 в требуемую UTF-8. Однако, данные были повреждены сами по себе, что означало, что нам был необходим новый бекап. Несколько часов спустя мы получили новую резервную копию, которая и была надлежащим образом перекодирована.

Были и другие проблемы, связанные с исходными данными: не было уникальных полей в строках базы данных для картинок и PDF-файлов, они хранились встроенно, (что означало, что мы должны были изменить эти данные "на лету", в соответствии с нашей новой консолидированной папкой /files, а также преобразовать их в подходящие файловые объекты для последующего хранения в поле filefield). Потом была проблема редактирования 300 страниц Конституции Штата, как единой ноды.

Эти трудности были легко преодолимы, и в скором времени мы получили работающий сайт. Интересно, что в исходной проприетарной CMS не было ничего близкого к функции Drupal check_plain(), а это означало, что в прошлом некоторые продвинутые редакторы сенаторов пришли к таким фантазиям, как отображение заголовка страницы в виде JavaScript-бегущей строки...

Редакторские права

Имея 12000 документов, размещенных в разделах более чем для 60 сенаторов, не все из которых хорошо работали друг с другом, мы должны были решить следующую задачу: распределение ролей и уровней доступа для редакторов на сайте. Это не решалось в лоб: все они должны были иметь возможность редактировать содержимое своих сенаторов, но не других сенаторов. Кроме того, если у одного сенатора было несколько редакторов, они должны были иметь возможность изменять работы друг друга, и нам также пришлось учитывать то, что некоторые редакторы работали на разных сенаторов.

Для этого мы использовали hook_node_access_records и hook_node_grants, чтобы обрабатывать доступ. Мы создали область доступа для возможных id сенатора в поле field_senator в документе, и отобразили ее на офисных редакторов, прикрепленных к сенатору. Они, в свою очередь, были прикреплены с помощью поля типа user_reference (предоставляется модулем CCK), с выбором из списка пользователей с ролью "Офисный редактор" (список пользователей был сделан модулем Views). Наконец, мы подправили вызов функции меню для node/[nid]/edit для проверки прав доступа, чтобы не показывать людям без соответсвующих прав вкладку на редактирование, ведущую вникуда.

Flag FTW

Мы интенсивно использовали модуль Flag на сайте. Это не только размещение материалов в карусельке на главной странице (которая была создана с помощью jQuery Cycle) и для других блоков на главной странице, но и похожие карусельки и закладки на страницах сенаторов, галереях, и других местах на сайте.

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

Хлеб и Масло (т.е. наши основные средства)

Представления (модуль Views), конечно, наполняют сайт нашими материалами. После создания и доводки блоков и страниц с представлениями, мы экспортировали их все для лучшей производительности. Не было никаких серьезных проблем на этом этапе, за исключением нескольких запросов, которые не возможно было создать через стандартный пользовательский интерфейс (UI). В этих немногих случаях, мы использовали hook_views_query_alter. Кроме того, поскольку многие из представлений требуют аргумента (который ссылается на сенатора), а у нас был свой токен для указания пути к сенатору, который не обязательно совпадал с названием, мы были вынуждены написать наш собственный обработчик аргумента для представлений, который мы привязывали в PHP-блок проверки аргумента, случае необходимости.

Поскольку требовался сайт любой сложности, нам необходимо было внедрить ряд пользовательских блоков. Мы усовершенствовали систему на нескольких сайтах, о которых мы здесь продолжим, что позволило увеличить гибкость системы пользовательских блоков Drupal, с целью легко контролировать появление блоков с помощью кода, а не только встраивая в административную форму такие вещи, как видимость блока на определенной странице. В основном, при создании нового блока, мы определяли его видимость как 2 (то есть, видимость блока на страницах контролируется PHP-кодом), и задавали в нем вызов своей функции, с параметром $delta. Тогда, если в будущем мы примем решение переместить один или несколько блоков на другую страницу, мы можем изменить настройки в функции, вместо того, чтобы конфигурировать каждый блок в отдельности. Для дальнейшего облегчения конфигурации, а также для того, чтобы воспользоваться Drupal только в момент загрузки файлов, мы создавали соответствующие функции темы автоматически, как только добавлялся новый пользовательский $delta, загружая, если требуется, новый файл theme_custom_block_$delta.tpl.php.

Есть много мелочей, что потребовались для создания этого сайта, о которых я хотел бы рассказать вам, и их там было значительно больше, чем я могу рассказать без превращения данного обучающего примера в длинный роман. Я даже не коснулся Комитетов (Committees), Законодательства (Legislation), или проекта Открытые Данные (Open Data).

Команда разработки Advomatic была великолепна! Я помогал Джонатану ДеЛейглу (Jonathan DeLaigle), Аманде Люкер (Amanda Luker), Джеку Хаазу (Jack Haas), и Марко Карбоне (Marco Carbone). Смотрящими за проектом были Фред Гултц (Fred Gooltz) и Дилан Клеар (Dylan Clear). Отдельный привет EchoDitto, который нес ответственность за ранее управление проектом и за первые наброски проекта/спецификации. Также, Крейг Лейнофф (Craig Leinoff) первым из офиса Сената прибежал к нам, чтобы помочь разработать сайт и получить его готовым к запуску.

Я рад видеть все большее восхваление добродетелей Open Source от нашего правительства, и горжусь тем, что мы помогли снабдить Сенат Штата Нью-Йорк надежным Drupal-сайтом.

Аарон Винборн является разработчиком из Advomatic. Кроме разработки, Advomatic также предлагает широкий спектр других Drupal-услуг, включая обслуживание и кластерный хостинг. Помимо оказания помощи в производстве таких сайтов, как Сенат Штата Нью-Йорк, Воздух Америки, а также Mozilla, Аарон также вносит большой вклад в сообщество Drupal, включая такие модули, как Embedded Media Field (встроенное поле для медиа) и Views SlideShow (слайдшоу на основе модуля Views). Он написал книгу "Drupal Multimedia", опубликованную издательством Packt Publishing, и играет ведущую роль в проекте Google Summer of Code, чтобы помочь выпустить модуль Media. Вы можете почитать его дневники на сайтах Advomatic и AaronWinborn.com.

Источник: Статья The New York State Senate, английский язык.