Мультисайтинг для Друпала 6, часть 1

picture_2.jpg

Итак, мультисайтинг - что это такое и зачем он нужен?

Если сказать коротко - мультисайтинг нужен как для разработчиков сайтов, так и для пользователей:
1. Для разработчиков сайтов. Мультисайтинг избавит Вас от изнурительной повторяющейся работы. Если у Вас один сайт, Вам не нужен мультисайтинг. Но если сайтов несколько - тогда без мультисайтинга Вы будете вынуждены для каждого сайта отдельно устанавливать одни и те же модули, обновлять каждый сайт по отдельности и так далее. А ведь всё это колоссальная трата времени, которой при желании легко можно избежать.
2. Для пользователей. Когда при мультисайтинге объединяются записи баз данных, серьёзно облегчается работа с посетителями сайтов, и при этом самим посетителям связки сайтов гораздо удобнее, легче и комфортнее при посещении Ваших сайтов.

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

Один единственный раз установив Друпал, Вы можете поддерживать несколько сайтов на движке Друпала, и каждый Ваш сайт будет иметь свои собственные настройки, структуру и контент.

Конфигурация каждого Вашего сайта задаётся в подкаталогах папки sites. Каждый такой подкаталог обязательно должен иметь файл settings.php, который и определяет настройки сайтов. Самый лёгкий способ создать дополнительный сайт - это скопировать туда папку default и изменить настройки в файле settings.php так, как Вам это нужно. Имя новообразованной папки определяется адресом URL сайта. Например, настройки конфигурации сайта www.nam.by могут быть определены в файле 'sites/nam.by/settings.php' (префикс 'www.'может быть пропущен, если пользователи могут иметь доступ к Вашему сайту, как к http://nam.by/).
Ваши сайты не обязаны иметь разные домены. Вы также можете использовать поддомены и подкаталоги для новых сайтов. Например, example.com, sub.example.com, или sub.example.com/site3 - все они могут быть определены как независимые сайты на Друпале. И настройки конфигурации для этих сайтов устанавливаются в файле settings.php по следующим путям:

sites/default/settings.php
sites/example.com/settings.php
sites/sub.example.com/settings.php
sites/sub.example.com.site3/settings.php

Когда Друпал ищет настройки конфигурации сайта (к примеру www.ru.wikipedia.org/wiki ), то поиск производится по директориям в следующем порядке:

sites/www.ru.wikipedia.org.wiki/settings.php
sites/ru.wikipedia.org.wiki/settings.php
sites/wikipedia.org.wiki/settings.php
sites/www.ru.wikipedia.org/settings.php
sites/ru.wikipedia.org/settings.php
sites/wikipedia.org/settings.php
sites/default/settings.php

Это была первая вводная статья, продолжение во второй части. Если Вам что либо не понятно, оставляйте свои комментарии, я обязательно постараюсь Вам помочь.

С уважением, Ёж

Мультисайтинг для Друпала 6, часть 2

pic10.jpg

Итак, продолжаю перевод официальной документации Друпала 6.

Если Вы используете нестандартный порт, то номер порта будет рассматриваться как более глубокий поддомен. К примеру: http://www.example.com:8080/ будет загружаться из sites/8080.www.example.com/.

Каждый сайт Вашей связки может иметь свои собственные модули и темы, дополнительно к тем, которые установлены изначально в папках modules и themes. Для того, чтобы использовать дополнительные модули и темы только для какого-либо одного сайта, Вы должны добавить подкаталоги modules и themes в папке для настроек этого сайта. К примеру, если sub.example.com использует специальный модуль или тему, которые не должны быть доступны на других сайтах, они должны быть установлены в соответствующие папки:

sites/sub.example.com/:
settings.php
themes/custom_theme - в папку themes записываете тему
modules/custom_module - в папку modules записываете модуль

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

С уважением, Ёж

Друпал. Настройка темы

drupal.jpg

Эта статья посвящается настройке темы для Друпала. Статья рассказывает о некоторых полезных механизмах работы с движком PHPTemplate.

node.tpl.php - это файл шаблона для вывода Ваших нод (или документов). Этот шаблон определяет не только то, как Вы будете выводить саму ноду, но и то, как она будет отображаться в списке тизеров (анонсов). А ведь порою крайне необходимо делать это по-разному. Например, возьмите Ваши анонсы статей на главной странице. Вы пишете блог, и на главной странице анонсы постов блога - и под каждым таким анонсом надпись "Все записи блога". И эта надпись повторяется десять раз на главной странице - просто ужас, иголки встают дыбом. То же самое можно сказать о надписи "Добавить комментарий". Нелогично оставлять комментарий к статье, прочитав лишь её анонс. Информацию об авторе статьи тоже можно убрать с главной страницы - особенно это касается личных блогов - зачем на главной странице десять раз повторять одно и то же имя автора?

Для разного отображения тизеров и полных нод можно использовать логические переменные $page и $is_front. Переменная $is_front равна True(1) в том случае, если отображается главная страница сайта. Так как её использовать, чтобы создать шаблон для тизеров на главной страницы? Очень просто - открываю файл node.tpl.php в своей теме, и прописываю в самом его начале следующую строчку:

<?php if ($is_front): include "node-front.tpl.php"; return; endif; ?>

Таким образом я говорю Друпалу, что если я располагаюсь на главной странице, шаблон для отображения нод находится не в файле node.tpl.php, а в файле node-front.tpl.php. Создаю в той же директории файл с таким именем - после чего проще всего скопировать туда весь код из файла node.tpl.php, и убрать всё, что мне не нужно. Например, я убираю с главной страницы всё, что относится к переменной $submitted (имя автора и время добавления статьи), переменную $links (ссылки типа "Все записи блога" и "Добавить комментарий"), переменную $terms (список терминов таксономии) и так далее. Но позвольте, время добавления статьи неплохо было бы и оставить, убрать лучше просто имя автора. Но переменная $submitted всё равно не нужна, решаю я. Для отображения даты и времени существует такая замечательная функция PHP, как date(). Например, прописать вот такую строчку перед переменной $content (переменная для отображения основного содержимого Вашей статьи):

<?php print date("d.m.Y - H:i", $node->created) ?>

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

Итак, это я сделал - теперь жму на каком-нибудь термине таксономии, которые отображаются у меня теперь только на странице самой ноды - и снова вылазит та же самая проблема. Идёт перечисление всех статей, относящихся к данному термину таксономии, и снова под каждым анонсом тот же самый кошмар - ссылка "Все записи блога", "Добавить комментарий" и так далее. Ну что ж, придётся теперь воспользоваться переменной $page. Её значени равно True(1) в том случае, если Друпал отображает какую-то ноду, но никак не список нод. Итак, прописываю в начале файла node.tpl.php ещё одну строчку:

<?php if (!$page): include "node-front2.tpl.php"; return; endif; ?>

Эта строчка говорит Друпалу о том, что если Друпал отображает список анонсов нод - файл шаблона для него - не node.tpl.php, а node-front2.tpl.php (на самом деле назвать можно как угодно). И снова я всё что, мне нужно прописываю в этом новом файле шаблона. Проблема решена!

С уважением, Ёж

Drupal-темизация: Прошлое

hawking_25.jpg

Вашему вниманию предлагается перевод обзорной статьи Джеффа Итона (Jeff Eaton) – «Друпал, дизайнеры и будущее». Что было в прошлом, что мы имеем на данный момент, и что имеет смысл ожидать нам всем в будущем. Но сначала, естественно, было прошлое, многие из читателей тоже могут вспомнить те времена, когда для сайтов вручную оптимизировались GIF-изображения и делалась табличная HTML-вёрстка. Лично я например тогда только поступил в радио-технический колледж, и вспоминаю книгу Игоря Мархвиды «HTML, CSS и JavaScript». Вот, пример такой работы, один из сайтов самого Джеффа – до сих пор рабочий сайт между прочим.

Перейду же теперь к Друпалу. Друпал сперва имел репутацию CMS, с которой дизайнеру было работать не так уж и легко, и долгое время это было действительно заслуженно. В первую очередь, подход Друпала к генерации HTML-страницы несколько отличается от подхода, который применяется в том же WordPress или Movable Type (ещё один очень распространённый движок для блоггинга). Прежде чем запрашивать у CMS необходимые части данных и работать с ними, тема Друпала предопределяет небольшие части текста (заголовок, имя автора и так далее) и, соответственно, только предопределив их, тема готова встроить всё это в сгенерированную HTML-вёрстку. Поэтому тут нужна некоторая перемена мышления – для дизайнера и верстальщика.

И в прошлом разработка темы на Друпале превращалась из обычной HTML вёрстки в работу, требовавшую нехилые навыки работы на PHP. В то время как большие части (например, разметка элементов страницы или индивидуальных частей контента) могли изменяться в template-файлах движка темы, то изменение темизации более мелких частей (например меню навигации или фрагменты информации о данной статье) требовали от Вас пробираться в глубины API Drupal-темизации и писать код. Те, кто помнят времена функции _phptemplate_variables(), знают, о чём я говорю. В итоге изменение разметки требовало написание сторонних модулей, которые копались в коде ядра, искали места, в которых генерируется соответствующий HTML-код, и переопределяли всё это своими собственными PHP-функциями. Это всё конечно прекрасно работало, но это было настоящим адом для людей, привыкших работать на чистой HTML и CSS вёрстке.

Оригинал тут.

Но в наше время всё конечно же совсем по другому. :) Продолжение следует…

Ёж

Drupal-темизация: Настоящее

drupal_logo_shirt-p235947756698576164q6vb_400.jpg

То, что есть на данный момент - это Друпал 6.x, и работа, проделанная для этой версии Друпала - это действительно серьёзный шаг на пути к удобству управлением Вашими темами.

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

example - это в данном случае название темы.

Файл example.info - это то место, в котором Вы определяете регионы для наших блоков. Регионы для блоков выделены красным на рисунке.
Там же в файле .info Вы определяете, что стили для нашей темы будут прописаны в файле style.css. После чего CSS будет запрашиваться именно из этого файла. Можно указать и какое нибудь другое имя, можно прописать несколько имён (возможно Вы видели - так делается в некоторых темах). В первую очередь это нужно для удобства самого разработчика - то есть Вы легко можете разграничить где будет прописан CSS для тех или иных элементов страницы, а не пихать это всё в один файл. И всё что нужно для этого - это просто прописать имена всех этих дополнительных .css файлов в файле .info.

Назначение файлов page.tpl.php, node.tpl.php и так далее - уже давно расписано до меня, тут содержатся шаблоны блоков, нод, общий шаблон страницы (page.tpl.php).

Также в папке с темой содержится файл logo.png - это картинка, которая используется как лого по умолчанию, скриншот темы и так далее (ну это уже лирика).

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

Так же легко можно создавать и подтему, на рисунке ниже:

В данном случае sub_example - это имя подтемы.

В файле sub_example.info - определяете тему родителя (define parent theme), определяете или переопределяете стили CSS родительской темы. Как видите - всё очень просто. В Друпале легко создавать чистые CSS темы, даже без необходимости изменять шаблоны - и это тоже безусловно большой плюс.

Ну и конечно файл template.php - в котором можно переопределить любую функцию темы, не относящуюся к стандартным типам (block, node, comment и т.п.).

Оригинал статьи теперь уже тут. Просто немного отошёл от первой статьи, решив более углубится в практическое, нежели в теоретическое описание.

С уважением, Ёж.

Drupal-темизация: Будущее?

306416820_0ef384e1bb_o.jpg

Друпал седьмой ветки пока ещё находится в разработке, но уже сейчас уделяется немало внимания улучшению работы с темами оформления. Некоторые предлагают использовать сеточную систему для быстрой вёрстки - например, систему подобную фреймворку 960 Grid System - вёрстка с использованием сетки шириной в 960 пикселей. Это может существенно ускорить разработку тем.

Но это всё только предположения. Как лучше всего бороздить просторы Большого Театра пока можно только предполагать. Конечно, когда выйдет седьмой Друпал, тогда всё и увидим. Пока лишь можно перечислить, что бы хотелось увидеть в Друпале 7. Что упростит разработку тем?

1. Включить в ядро файл layout.css который будет только лишь правильно позиционировать основные элементы страницы - content, header и sidebars. Переопределять данный файл можно было бы очень легко - просто добавлением CSS-файла с таким же именем в свою тему. Для вновь прибывших это также было бы полезно - быстрее бы разобрались как файлы шаблонов работают при минималистской вёрстке.

2. Обеспечить тему оформления в ядре, которая содержала бы только .info файл. Ну и, соответственно, тот самый файл layout.css, который размечает основные регионы. Такая тема могла бы служить хорошим примером того, на основе чего и строится любая друпаловская тема. И хорошим отправным пунктом для многих.

3. Обеспечить одну или несколько тем, включённых в ядро, для создания которых было использовано только CSS и несколько картинок, вставленных с помощью стандартной HTML-разметки. Ведь если на Друпале можно будет легко создать тему, построенную с помощью чистой CSS-вёрстки, то нужно сделать так, чтоб было ещё легче.

4. Создать наглядную тему, которая использует как стандартное переопределение с помощью шаблонов tpl.php, так и jQuery - для добавления разного интересного функционала. Например, прописать какой-либо регион - который будет сворачиваться и разворачиваться с помощью jQuery, сделать например, чтобы в какой-то теме комментарии автора статьи показывались по-другому и так далее. Это будет хорошей опорой для людей - и люди быстрее будут знакомится с самыми современными и передовыми технологиями.

5. Создать тему, с помощью которой можно легко добавлять один или несколько регионов, в которых бы отображались новости - подобно тому, как это стандартно реализовано в Joomla! и некоторых продвинутых WordPress темах.

6. Расширить Readme файлы, которые подробнее разъясняли бы, что и как делается в темах. (К сожалению - многие новички рунета никогда не бывают застуканы за занятием прочтения Readme-файлов, а жаль. На Западе несколько по другому - у них там для любого новичка Readme.txt - это как святая святых).

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

Оригинал статьи всё там же :).

Спасибо за внимание.

Полуночный Ёж.

Друпал - модуль User Points

fp_icon.png

  Здесь подробнее остановлюсь на модуле User Points, и на всех возможностях, которые предоставляет данный модуль. Сам по себе модуль User Points для шестёрки служит в первую очередь как API для других модулей, которые работают с поинтами.

 Основные моменты, которые позволяет реализовывать базовый модуль User Points - это зарабатывание пользователями юзерпоинтов за следующие действия пользователей на сайте:

 - публикация ноды (за публикацию нод разного типа можно присваивать разное количество юзерпоинтов);

 - публикация комментариев;

 - модерация комментариев и так далее...

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

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

 Но особый интерес конечно представляют интегрированные с User Points модули. Постараюсь ниже дать краткий обзор наиболее полезных и/или интересных из них.

 Ubercart Userpoints - этот модуль интегрирует модуль User Points с Уберкартом, и позволяет юзерпоинтами оплачивать покупки, делать скидки людям, имеющим определённое количество юзерпоинов, etc. Для шестого Друпала данный модуль правда пока находится в деве, он зависит от модуля Уберкарта Conditional Actions, а не от Rules (аналог Workflow-NG для пятёрки).

 Userpoints Node Action - модуль создаёт интерфейс для админов сайта, позволяющий применять юзерпоинты пользователями для оплаты некоторых действий с нодой, например публикация ноды, расположение ноды на главной странице, прикрепление ноды вверху списка (sticky). Этот модуль также прекрасно работает с модулем Override Node Options, в совокупности с которым можно расширять список подобных действий.

 Referral - позволяет работать с реферральными ссылками.

 Userpoints Store Credit - определяет новый метод оплаты товаров магазина на Уберкарте (store credit payment method), который позволяет платить за товары сайта не фактическими деньгами. Данный модуль для шестёрки пока также находится в деве.

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

 Спасибо за внимание.

Drupal 6.x. Создание модуля – файл .install

drupal_logo.png

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

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

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

В Друпале 6.x для создания таблиц и полей в БД применяется Schema API. Schema API позволяет модулям объявлять свои таблицы БД в структурированном массиве (подобно Form API) и обеспечивает функции API для создания, удаления и изменения таблиц, столбцов, строк, ключей и индексов БД.

Я хочу разобрать пример из документации по Schema API с сайта Drupal.org.

Например, как создаётся таблица БД для самой обычной ноды (модуль Node ядра Друпала, обязательный модуль, с помощью которого добавляются и загружаются ноды). Это отрывок из файла node.install, из функции node_schema().

<?php
$schema['node'] = array(
    'description' => t('The base table for nodes.'), 
    'fields' => array(    // Таблица содержит четыре поля (колонки) - <em>'nid', 'vid', 'type' и 'title'
      'nid' => array(  <strong>// Первое поле
       'description' => t('The primary identifier for a node.'), // Описание поля
       'type' => 'serial', // Тип первого поля - 'serial'
       'unsigned' => TRUE,
       'not null' => TRUE), // Конец первого поля</strong>
      'vid' => array(  // Второе поле
       'description' => t('The current {node_revisions}.vid version identifier.'),// Описание поля
       'type' => 'int', // Тип второго поля - 'int'
       'unsigned' => TRUE,
       'not null' => TRUE,
       'default' => 0), // Конец второго поля
      'type' => array(   // Третье поле
       'description' => t('The {node_type} of this node.'), // Описание поля
       'type' => 'varchar', // Тип третьего поля - 'varchar'
       'length' => 32,
       'not null' => TRUE,
       'default' => ''), // Конец третьего поля
      'title' => array(   // Четвёртое поле
        'description' => t('The title of this node, always treated a non-markup plain text.'), // Описание поля
        'type' => 'varchar', // Тип четвёртого поля - 'varchar'
        'length' => 255,
        'not null' => TRUE,
        'default' => ''), // Конец четвёртого поля
      ), // Конец перечисления полей
    'indexes' => array(  // Два индекса таблицы 'node_changed' и 'node_created'
      'node_changed'=> array('changed'), // Поле 'changed' - для изменённых нод
      'node_created'=> array('created'), // Поле 'created' - для созданных нод
      ),
    'unique keys'=> array( // Вторичный ключ таблицы
     'vid'=> array('vid') // Ключ 'vid' - поле 'vid'
      ),
    'primary key'=> array('nid'), // Первичный ключ таблицы - поле 'nid'
    );
?>

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

Продолжение в следующих постах. Оригинал статьи.

Спасибо за внимание.

Ёж

Drupal 6.x. Создание модуля – hook_schema

drupal_31.jpg

Итак, для того, чтобы через Schema API организовывались поля БД для создаваемых модулей, модуль должен иметь файл .install, в котором используется хук hook_schema() (в предыдущих версиях Друпала hook_schema() объявлялся в файле .schema, но в шестёрке это уже не используется). Приведём пример, файл mymodule.install для модуля mymodule:

<?php
function mymodule_schema() {
  $schema['mytable1'] = array(
     // Перечисление полей таблицы mytable1
  );
  $schema['mytable2'] = array(
    // Перечисление полей таблицы mytable2
  );
  return $schema;
}
function mymodule_install() {
  // Создание таблиц при инсталляции модуля
  drupal_install_schema('mymodule');
}
function mymodule_uninstall() {
  // Удаление таблиц
  drupal_uninstall_schema('mymodule');
}
?>

$schema['mytable1'] = array(
// Перечисление полей таблицы mytable1
); - в первой статье есть более подробный пример, как задаются поля и ключи в таблице - пример из первой статьи.

Для разработчиков модулей есть такой очень полезный модуль Schema Module. Несколько слов о том, зачем он нужен, впоследствии можно будет остановиться на этом модуле поподробнее:

• - Документация. Отображение в виде гиперссылок всей вложенной документации по Schema API, текст контексной помощи для каждой ссылки.
• - Модуль просматривает БД на сайте и может создавать структуры данных Schema API для всех таблиц в базе данных.
• - Сравнение. Модуль сравнивает структуру БД со структурой таблиц, которые создаются новыми модулями, сообщает обо всех отсутствующих или неправильно объявленных таблицах.

С уважением, Ёж

SQL и Views

logo.png

Один из самых используемых модулей Друпала Views стал таким популярным в первую очередь благодаря своей простоте. По сути дела те же самые SQL-запросы - но только Вам не нужно самим писать никакого кода. К тому же - построив страницу или блок с каким-либо view, Вы легко оперируете с данной страницей, как и с любой другой страницей Друпала. И ещё - модули сами сообщают обо всём Views, а Вам остаётся только выбрать нужные значения, и не нужно даже думать о том, как правильно передать ту или иную переменную.

Как например работает язык SQL? Он работает на запросах к БД. Так вот - тем кто привык и умеет писать простейшие (или даже и не простейшие, а пусть даже сложнейшие) запросы будет ещё легче задать параметры в настройках Views и получить тот же самый результат.

Возьмём к примеру простейший SQL-запрос:

SELECT title FROM node WHERE nid = 13

Всё понятно, не так ли? Выбираем поля (title) из таблицы (node), но только такие поля, для которых nid=13. Но и каждый Ваш view также строится на точно таких же SQL-запросах, только вы их задаёте в настройках создаваемого вида. Любой такой запрос можно разложить на базовые составляющие: утверждение select, условие where, условие order by. А теперь давайте ассоциируем это с тем, как такие условия задаются в вашем виде view:

SELECT [Поля]
FROM [view type and any relationships]
WHERE [Фильтры или arguments]
ORDER BY [sort criteria]

Как видите всё достаточно просто - я просто ассоциировал вкладки в настройках Вашего вида view (на картинке) с параметрами, которые передавались бы при построении аналогичного SQL-запроса.

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

Ёж.

Views - работа с аргументами

robot_rt_280x.png

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

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

Понятно, что такую листалку можно делать только через аргументы. Но моя задача усложнялась ещё и тем, что в фиксированном формате была только дата, а кроме даты там же администратор по ТЗ мог указывать и время - например 03-25-2009 12:23. И все эти записи нужно было отображать в моём виде. Только записи по конкретной дате.

Итак - добавляете в качестве аргумента то поле, в котором у Вас и содержится дата (например, у меня дата указывалась в заголовке комментария). Соответственно в аргументе и будет передаваться Ваша дата. Но как сделать, чтоб можно было включить туда все записи - не только те, которые имеют жёсткий фиксированный формат ММ-ДД-ГГГГ.

В итоге мне помог режим глоссария. Или же словарный режим - как кому больше нравится. Дело в том, что в настройках аргумента этот режим применяется для ограничения числа символов, используемых в аргументе. Причём - символами могут выступать как буквы, так и цифры. Таким образом в настройках аргумента я поставил птичку напротив надписи словарный режим - и поставил десятку - ведь дата в формате ММ-ДД-ГГГГ - это как раз десять символов. Ну и в базовых настройках я выбрал ПОКАЗАТЬ ВСЕ ЗНАЧЕНИЯ.

Всё - теперь в мой вид попадают и значения 03-25-2009 и 03-25-2009 12:23, и так далее. Точно так же можно показывать даты по месяцам - поставить 2 вместо десяти в поле ограничения символов, и тогда вид будет показан только по двум первым цифрам, то есть можно группировать записи по месяцам. И так далее - возможности на самом деле безграничны.

Ну, теперь осталось сделать саму листалку - для этого в основных настройках вида я использовал поле Подвал (Footer) и вводил туда свой код. Я использовал функцию для даты mktime(). Можно также использовать strtotime(). Или работать с преобразовыванием даты в формат JDC. Способов на самом деле масса - благо и функций для работы с датами в PHP немало:

<?php
$view = views_get_current_view(); // Получаем доступ к текущему виду

if(!count($view->args))
  return ''; // Если нету ни одного аргумента, ничего не выводим

$date1=explode("-",$view->args[0]); // Записываем дату из нашего аргумента в переменную $date1

$yesterday = mktime (0,0,0,$date1[0] ,$date1[1]-1,$date1[2]);// Вчера
$tomorrow = mktime (0,0,0,$date1[0],$date1[1]+1,$date1[2]);// Завтра

$before = l('Предыдущий день <<', 'all/'.date("m-d-Y",$yesterday));
$after = l('Следующий день >>', 'all/'.date("m-d-Y",$tomorrow));

// Формируем ссылки и выводим их оператором return

return "<p>$before</p><p>$after</p>";
?>

Всё. Сохраняем изменения - наша задача выполнена :)

Ёж

Друпал – Работа с БД

drupal_IG_big.png

Между Вашей БД (MySQL или PostgreSQL) и кодом PHP сайта в Друпале существует слой абстракции базы данных, благодаря которому можно использовать разные типы баз данных, используя один и тот же код. Это позволяет избежать многих ошибок, и к тому же не несёт никаких ограничений в использовании SQL. И очень удобно – например, Вам нужно сменить сервер баз данных с PostgreSQL на MySQL. Без абстракционного слоя Вам пришлось бы вручную изменять все SQL запросы, а так – ничего не нужно делать вообще. Слой абстракции сам будет по-другому обращаться к другому типу сервера.

Как Друпал определяет тип БД? Активация БД для последующих запросов осуществляется через функцию db_set_active. Сперва проверяется значение переменной $db_url в файле settings.php. Если переменная начинается с mysql, тогда Друпал использует оператор include() с файлом includes/database.mysql.inc; если же она начинается с pgsql – тогда с файлом includes/database.pgsql.inc.

Чаще всего запрос к активной БД осуществляется через функцию db_query. Рассмотрю простейшие запросы SELECT, INSERT, UPDATE и DELETE.

db_query('SELECT * FROM {joke} WHERE vid = %d', $node->vid);

Данный запрос возвращает все ряды из таблицы joke, у которых значение поля vid является целочисленным значением (integer – спецификатор %d), равным значению переменной $node->vid.

db_query("INSERT INTO {joke} (nid, vid, punchline) VALUES (%d, %d, '%s')", $node->nid, $node->vid, $node->punchline);

Данный запрос вставляет в таблицу joke ряд. Новый ряд включает в себя три значения. Два целочисленных (поля nid и vid – в них вставляются значения переменных $node->nid и $node->vid) и одно строковое, что мы и обозначили спецификатором %s – string (вставляется значение переменной $node->punchline).

db_query("UPDATE {joke} SET punchline = '%s' WHERE vid = %d", $node->punchline, $node->vid);

Данный запрос изменяет значение поля punchline для ряда, в котором значение поля vid равно значению переменной $node->vid. Вставляется новое значение, равное значению переменной $node->punchline.

db_query('DELETE FROM {joke} WHERE nid = %d', $node->nid);

Данный запрос удаляет из таблицы joke все ряды, для которых значение поля nid является равным значению переменной $node->nid.

Напоследок давайте рассмотрим пример файла .install, который осуществляет установку модуля – а для нода-модулей обычно необходимо создать таблицу. На этот раз пример для версии 5.x (из файла book.install):

<?php

/**
* Реализация функции hook_install().
*/
function book_install() {
switch ($GLOBALS['db_type']) {
case 'mysql': // Запрос идентичен запросу для mysqli.
case 'mysqli':
db_query
("CREATE TABLE {book}
(
vid int unsigned NOT NULL default '0',
nid int unsigned NOT NULL default '0',
PRIMARY KEY (vid),
KEY nid (nid),
) /*!40100 DEFAULT CHARACTER SET UTF8 */ ");
break;
case 'pgsql':
db_query
("CREATE TABLE {book}
(
vid int_unsigned NOT NULL default '0',
nid int_unsigned NOT NULL default '0',
PRIMARY KEY (vid)
)
");
db_query("CREATE INDEX {book}_nid_idx ON {book} (nid)");
break;
}
}
?>

Как мы видим – с помощью оператора switch корректируется запрос для разных серверов баз данных.

В статье я опирался на книгу Pro Drupal Development первого издания и на справочник API Друпала.

Ёж

FormAPI в Друпале 6

drupal_hosting.png

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

$form_state['values'] - как известно, все наши формы работают путём передачи POST-значений, поэтому передать их нужно правильно. Использование $form_state с данным ключом, это по сути дела замена переменной $form_values, которая была до этого. Как известно, $form_values раньше использовалась в функциях обработки и валидации формы для передачи значений.

Следующие три ключа используются для контроля рабочего процесса обработки формы. Функции валидации и функции-обработчики могут изменять значения переменной $form_state с данными тремя ключами для того, чтобы правильно организовать рабочий процесс, основываясь на значениях, вводимых пользователем в поля формы.

$form_state['redirect'] - здесь Вы управляете тем, что должно произойти после того, как работа с формой завершена. По умолчанию Вы просто возвращаетесь на страницу формы, и все поля в форме очищаются. Если же Вы присваиваете этой переменной значение какого-либо пути, например $form_state['redirect']='user/edit', то после завершения обработки формы Друпал перекинет Вас на эту страницу. Если же Вы установите значение данной переменной в FALSE, то пользователь никуда не будет перенаправлен, а значения, введённые в форму, так и останутся "висеть" в полях формы.

$form_state['rebuild'] - значение данной переменной отменяет значение переменной $form_state['redirect']; когда значение этой переменной установлено в TRUE - то форма перестраивается, позволяя разработчику добавлять дополнительные поля или изменять структуру формы, основываясь на действиях пользователя (например, перестраивание формы путём прибавления ей дополнительных полей в том случае, когда пользователь нажимает на кнопку "Прошу предоставить мне дополнительный выбор"). Если этот флаг будет выставлен в функции валидации, то функция обработчика формы будет пропущена. Если же этот флаг будет выставлен в функции-обработчике, то форма будет перестроена и выведена на экран после того, как все обработчики завершат свою работу с формой.

$form_state['storage'] - иногда приходится строить многошаговые формы, и в этих случаях важно сохранить данные, введёные в форму на каждом из шагов. Все данные, помещённые в переменную $form_state['storage'] автоматически попадают в кэш и перезагружаются для следующего шага обработки формы. Таким образом Вы можете накапливать данные на каждом шаге работы с формой, и обработать на финальном шаге те данные, которые Вы например ввели в самой первой форме.

Ну, и ещё.

$form_state['clicked_button'] - в данной переменной содержится полная копия элемента кнопки, которая была нажата для запуска функции обработчика формы. использование этого элемента более надёжно, чем работа через $form_values['op'], в этой переменной также помещается любая дополнительная информация, которая может быть в определении данного элемента типа 'submit'(кнопка).

Полный список изменений для FormAPI шестого Друпала Вы можете прочитать здесь.

Спасибо за внимание, Ёж

Модуль Page Title

icon_cms.jpg

Для работы этого модуля нужен Token.

Известно, что каждая единица контента сайта Друпала имеет свой заголовок (title). Естественно, то же самое относится и к страницам (page title). Заголовок страницы обычно помещается в теге title в хэдере Вашей HTML-страницы. Это весьма помогает улучшить SEO Вашего сайта.

Модуль page title позволяет добавлять теги