drupal 入門

Drupalについて

Drupalはコンテンツ管理システムのソフトウエアです。コンテンツ管理システム（略ＣＭＳ）とは、Ｗｅｂサイトのコンテンツ作成、維持、変更、管理を容易に行うことのできるシステムです。一般に、CMSは、バックエンドにリレーショナルデータベースシステムを配置し、ブラウザからコンテンツの入力、デザイン変更、ワークフローを実施できるようにしている。Ｗｅｂサーバ上で稼働し、コンテンツやサーバの管理コストを低減させることを可能にする。

Drupalは、Webサイトで広く活用されている言語であるＰＨＰをベースとして開発されていて、徹底したオブジェクト指向設計と、モジュールによる容易な活用が特徴である。また、後方互換性の維持にもしっかり取り組んでおり、スムーズにバージョンアップをしていくことができる。
PHP言語は、ほぼあらゆるＯＳをサポートしている。インタープリタ型であるので、アプリケーションのインストールも、決められた場所へ展開するだけと、活用の容易さも容易です。

稼働に必要な環境

オペレーティングシステム
Webサーバが稼働するＯＳ
- Linux
- FreeBSD
- Mac OS X
- Microsoft Windows Server
など、ほぼあらゆるオペレーティングシステムで稼働可能。
Webサーバソフトウエア
- 推奨： Apache http サーババージョン1.3 / 2.0 / 2.2
- 利用可能：IIS 5 / 6, thttpdなど
PHP実行環境
PHP 4.3.3 以上
データベースサーバ
- 推奨： MySQL 4.1以降 / 5.x
- その他： PostgreSQL 7.3 以上

これ以降の、初心者向けのインストール方法については、Drupal Japanのサイトのチュートリアルがわかりやすい。

本稿では、さらによりしっかり管理すること、モジュールを追加して使いこなすことを目標に解説する

Drupalによるサイトづくり

Drupalとは

Drupalとはコンテンツ管理システム(CMS)である。ブログシステムのリファレンスにもなっている。モジュールによるシステム構成がしっかりしており、コードも整理されている。したがって、コードの管理も容易と思われ、セキュリティ上も有利と思う。デフォルトで、３ペインや２ペインのスキンが数種類入っており、すぐに利用可能だ。またサードパーティのデザインもある。これらもdrupalと同じサイトからダウンロード可能だ。

Drupalの入手

Drupalは、Drupal.orgないしはDrupal.jpから入手できる。

サーバ環境の準備

DrupalはLAMPないしはLAPP環境で動作する。動作にはApache2, PHP4以上の他に、MySQLないしはPostgreSQLデータベースが必要だ。ただし、PostgreSQLサポートがちゃんとされているのはコアモジュールのみであり、サードパーティモジュールのなかにはPostgreSQLサポートが省略されているものがある。とはいえ、コアではデータベースの違いを吸収するようになっているので、そのようなモジュールであってもMySQLのデータベース定義を参考に、PostgreSQL用のデータベース定義を作成するだけで、利用可能である。 SQL文のわかる方は、ぜひPostgreSQLでの利用にチャレンジし、移植すると日本の多くのユーザに喜ばれるだろう。

インストールの前に

多くのサイトでは、すぐにパッケージを展開し、利用しているだろう。しかし、ここではコード管理システムによるコード管理を行いつつ、利用することにする。実は、このようなサーバパッケージは、セキュリティ対応のためバージョンアップに追随する必要がある。実際に動作しているサイトで、直接アップデートするのは、作業を失敗した場合にサイトの停止を招くし、作業中はアクセスを受けられないこともある。また、スキンやモジュールについて、独自の拡張やサードパーティのモジュールを導入した場合、それらをマージしつつ、利用したいだろう。設定についても、アップデートの際にパッケージを上書きして消してしまうこともある。(drupalでは、設定ファイルはsample用と実際のファイル名を違えているので、このような事故は無い) そこで、プログラム開発でつかうコード管理システムを活用して、このような課題を解決する。またバージョンアップや拡張を行う際には、テスト用のサイトを作成し、動作確認してから本番環境に摘要するといったことも容易にできるのだ。

subversionの準備

近代的なBSD/Linuxであれば、subversionはパッケージで導入できるだろう。

リポジトリの初期化


%svn init /path/to/repos

リポジトリの構造を作成する


%svn mkdir file:///path/to/repos/trunk

%svn mkdir file:///path/to/repos/branches

%svn mkdir file:///path/to/repos/tags

初期インポート

drupalのパッケージを一時的なディレクトリに展開する。


% tar zxf drupla-4.7.0.tar.gz

% cd drupal-4.7.0

subversionのリポジトリにdrupalのコードを導入する。


%svn import file:///path/to/repos/trunk

続いて、リポジトリにあるパッケージを作業ディレクトリにチェックアウトする。


%cd ~/work

%svn co file://path/to/repos/trunk drupal

つぎに、branchをつくって、maillineブランチとtrunkにわける。


%svn cp file:///path/to/repos/trunk file:///path/to/repos/branches/mainline

今後、パッケージのアップデートがあった場合は、すべてこのmainlineブランチにいれていく。 trunkは、実際に本番環境で使う環境である。

モジュールの導入

そこでtrunkには、追加モジュールなどをいれてコミットする。追加モジュールはダウンロードして ~/srcディレクトリにあるとすると、


% cd ~/work/drupal/modules

% tar zxf ~/src/some_module-4.7.x-.tar.gz

% cd ../

% svn add some_module

% svn ci -m 'add some module'

というようになる。複数ある場合は上記を繰り返す。

バージョンアップの対応方法

もし、バージョンアップがあったら、

maillineブランチにバージョンアップをコミットする。タグも打っておく %cd work/drupal; % svn switch file:///path/to/repos/branches/mainline % cp -pr somewhere/drupal ./ % svn ci -m 'mainline version up' % svn cp file:///hogefuga/branches/mainline file://hogefuga/tags/ML-4.7.5
trunkの作業コピーにマージする。 % svn switch file://hogefuga/trunk % svn merge -r 1:HEAD file:///path/to/repos/branches/mainline
実験用ディレクトリにいれて、動作を確認する % cp -pr * ~/test_html
OKだったらそれで運用し、コード管理でコミットする % svn ci -m 'upgrade'

インストール

コード管理システムで管理されているので、ファイルのインストールは、コード管理システムからチェックアウトすることに相当する。


% cd ~/

% svn co file:///path/to/repos/trunk public_html

さて、drupalの基本設定については、パッケージ管理システムの作業ディレクトリで実施する。


% cd ~/work/drupal

% cd sites/default/

% vi settings.php

ひとつのパッケージで複数サイトを運用する

drupalはひとつのパッケージで複数サイトを運用するための仕組みを備えている。たとえばxoopsではサイトごとにパッケージを展開、管理する必要があるが、セキュリティバージョンアップの際には、すべてのコードを更新しなければならなくなり、ミスをよぶ原因ともなる。 drupalでは、設定ファイルに工夫がある。設定ファイルがsitesというディレクトリにあるのには理由があるのだ。もし、利用したいサーバ名 path名がhttp://www.drupal.org/misite/test/ だった場合、

sites/www.drupal.org.mysite.test
sites/drupal.org.mysite.test
sites/org.mysite.test
sites/www.drupal.org.mysite
sites/drupal.org.mysite
sites/org.mysite
sites/www.drupal.org
sites/drupal.org
sites/org
sites/default

の順番で設定ファイルのサーチが行われる。たとえば、

http://www.example.com/userA/
http://www.example.com/userB/
http://www.example.com/

という3つのページを作る場合は

sites/www.example.com.userA/settings.php
sites/www.example.com.userB/settings.php
sites/default/settings.php

という設定ファイルを準備し、それぞれにデータベース設定とアップロードするファイルの場所を違えておけば、独立して運用してもらえる。

Drupalの便利なモジュール

モジュールとは

Drupalはモジュールによる拡張ができるようになっている。モジュールは、Drupal.orgのModulesページから取得できる。モジュールは、ほとんどはdrupal/modules/にて展開するだけで利用可能になる。一部、他の製品と統合する機能を提供するモジュールの場合は、パッケージに他の製品のファイルへのパッチや置き換えファイルがはいっているため、パッケージのドキュメントを参照して作業が必要。展開したら、「サイト管理」ー「モジュール」にでてくるので、チェックして保存すると、DBMSのテーブルは自動的に作成される。

便利なモジュール

abc順で便利なモジュールを紹介する。

adsense

Google Adsenseの広告を表示するモジュール。本サイトでは、左側のメニューペーンにある広告の表示に使っている。

adsense_Injector

Google Adsenseの広告を記事中に挿入するモジュール。記事の左上に記事を入れてくれる。本サイトでは、右上になるように、設定を変更している。

affiliate

amazon等のアフィリエイトをサポートする。

aggregator

RSSフィードを取得し表示する。

atom

ATOMによるRSSフィードを提供する。

attatchment

記事にたいする添付ファイルをサポートする。

blog

登録ユーザによるブログをサポートする。

blogapi

RPC-XMLによるブログ投稿を支援する。

contact

メールアドレスを公表することなくメッセージの受け取りを許す。

export opml

OPML (Outline Processior Markup Language)でコンテンツのexportをサポートする。OPMLとは、RSSの一種ともいえ、元々は文書のアウトライン構造の情報を異なるOSや、異なる環境で交換できることを可能とするための規格である。サイト間連携で使うほか、RSSリーダーにも、RSS を提供するサイトの一覧を記述している OPML を取り込むことができるものがある。

filemanager

ファイルのアップロードやアップロードしたファイルの管理を行う。これに対応した他のモジュールから使われる。

flexinode

サイト独自のコンテントタイプを作成可能にする。たとえば、イベントのコンテンツタイプに、定型的なラジオボタンでその種類を示すとか、会場がいくつか固定であるときにプロダウンメニューを定義するとか。

googlesearch

Googleによるサイトサーチが簡単にできるようにするモジュール。デフォルトで含まれるsearchモジュールではサーバのDBに検索が走るが、公開されているサーバならば、Google Searchを使った方がサーバ負荷は下がるだろう（その代わり、Googleへ検索キーワード情報が行ってしまう） Google site managerなど、検索エンジン側の情報取得サービスを併用出来る場合に有効である。非公開サーバの場合は、デフォルトのsearchを使うべし

gsitemap

Google site Managerでは、sitemap情報を、googleの定義するsitemap　XMLで読み取りできるようにすることで、効率的にクロールしてもらうことができる。サーチエンジンマネジメント的に有効。上記、google searchとの組み合わせがおすすめ。

leech

RSS　Aggregationを行う。デフォルトのAggregatorと違うのは、RSSフィードからノードを作成できること。デフォルトのAggregatorは、配信元別とカテゴリ別にノードになるが、Leechであれば、コンテンツ毎にノードになる。この結果、RSSによる記事作成、連携にも利用可能である。

node privacy byrole

role(役割）ベースでコンテンツのアクセス権限（読み取り、編集）を制御できるためのモジュール。ユーザにroleを割り振る。roleごとに権限を設定する。直接ユーザを設定しなくても、roleが間にはいることで柔軟にアクセス権限を設定できる。(4.7.xまで）２００７年２月現在、開発者を探している。

nodeaccess

node privacy by roleと同様の機能を実現する。roleだけでなく、ユーザ単位でも制御可能。開発版ながら5.xにも対応している。

node_template

ノードのテンプレートを提供するモジュール。leechに必要。

rcmail

RoundCubeMailというOSSのWebMailと連携可能にするモジュールおよびハック。導入には、DBMSの知識やパッチを当てるための知識が必要である。モジュール単体にはほとんど機能はなく、機能は別のソフトウエアが持つ。

service_links

コンテンツに、DiggやDel.icio.usへの登録ボタンを追加する。

site_map

人間が見やすい形でsitemap を表示する。

spam

コメントスパムやトラックバックスパムを、キーワードマッチで検出し、まとめて削除可能にする。

trackback

トラックバックを送信したり、受信したり出来るようにする。すごい数のトラックバックスパムを受けるので、spam moduleは必須。

webcal

WebCalendarというLAMP対応のＯＳＳライセンスのＷｅｂカレンダーソフトウエアと連携する。ユーザ管理をDrupal側で行って、ユーザ毎のカレンダーを作成したりできる。デフォルトのeventモジュールでは、イベントを作成し、ユーザが登録する程度しかできないが、こちらは個人毎のスケジュール管理まできる高機能なものだ。機能は、WebCalendarプロジェクトからダウンロードできる別ソフトウエアが提供する。

モジュールのインストール

Drupalのモジュールインストール

Drupalのモジュールは、バージョンによりインストール方法が異なるが、次のようにして導入する。 Drupal 5.0より前のバージョンの場合 モジュールをダウンロードして、展開する。2つのパターンがあり、

wwwhome/modules/の配下にtarコマンドないしは、zipコマンドで直接展開する。
展開した中に、パッケージ名のディレクトリがあり、そのディレクトリをdrupal_home/modules/配下に展開する。

である。

多くの標準的なパッケージは、1つめの方法でOKである。複数のソフトウエアをDrupalに統合するパッケージの場合、パッケージ内部にDrupal用のファイルと統合相手のコードを変更するファイルが入っているため、2つめの方法になることが多い。ドキュメントにその旨かいてあるが、簡単に判別する方法は、 module_name.module, module_name.install, module_name.mysqlといったファイルがDrupaloのモジュール本体であるため、これらのファイルが入っているディレクトリをコピーする、と覚えるといいだろう。

Drupal 5.0, 5.1以降の場合

drupal_home/sites/all/modules/ に展開する。展開方法は、上記と同じ。サイト別に特別なモジュールを限定して入れたい場合は、drupal_home/sites/some_site/modules/に展開する。some_siteのところは、各位の設定にあわあせる。

ちなみに、DrupalはPostgreSQLに対応しているが、サードバーティモジュールの場合、対応していないことがおおい。対応していないといっても、Drupalのコア機能では抽象化されているので、単にPostgreSQL用のスキーマが提供されていないだけに過ぎない。

PostgreSQLで運用している場合は、module_name.mysqlのMySQL用スキーマを参考にPostgreSQL用のスキーマ、module_name.pgsqlを作成するといいだろう。

展開したあとの設定

展開したあとは、DrupalのWeb画面にいき、administrator-modulesにいって、そのモジュールのチェックボックスにチェックをいれて、送信することで自動的に必要なDBや設定が作られる。モジュールの設定は、administrator-config- module_name に進んで、設定する。

Ｄｒｕｐａｌのデザイン

Drupalのデザインは、これもパッケージの形で多数提供されている。インストールも簡単で、ダウンロードして、サーバの決まったディレクトリで展開するだけである。

Drupalのバージョンによってサードパーティモジュールの展開方法が変わったので注意されたい。

Drupal 4.6, 4.7の場合

drupal_home/themes/の下にディレクトリごと展開する。

Drupal 5.0, 5.1以降の場合

drupal_home/sites/all/themes/の下に展開する。なお、sitesの配下には、各バーチャルホストやパスの設定ごとにディレクトリを作成できるが、そのディレクトリたとえばdrupal_home/sites/www.da-cha.jp/themes/を作成して展開した場合、そのサイト専用のテーマとなる。

この機能は、たとえばサイト専用のデザイン（背景に特別なデザインがあるなど）の場合に、有用である。

単一サイトの運用の場合は、デフォルトの場所で問題ない。ユーザが登録させるようにすると、ユーザごとに好きなデザインを選ぶこともできる。ゲストに選ばせることもできるが、それはアクセスコントロールによって設定可能だ。

テーマを展開したあとは、configure-themeと選ぶことでサイトのデフォルトテーマを設定可能だ。また、デフォルトのテーマでは、ロゴマークがDrupalの悪そうな顔のデザインだが、設定ページでロゴのアップロードが可能だ。

デザインを複数有効にすることもできる。その場合は、ユーザが選択できるようにしたり、季節ごとに表示するデザインを切り替えることができる。複数のデザインを利用する場合には、ブロック構成がデザインごとに設定必要でることに注意が必要だ。

ブロック構成とは、コンテンツの表示エリア、メニューの表示エリア、タイトルの表示エリアなど、基本となるボックス（ブロック）を左側、中央、右側、中央下、中央上、中央右等々のあらかじめ指定された領域に配置することをいう。この領域の配置と色がテーマであり、配置によってデザインが決定される仕組みだ。

サイトの管理方針

サイトの管理にあたっては、次のような事項について、あらかじめ考えておくことが望ましい。

コメントやトラックバックをゆるすかどうか。それによって、スパムコメントに対する対策について考える必要がでるし、必要なモジュールもある。
サイトを訪問した人にユーザログインを許すのかどうか。たとえば、会員への情報提供や掲示板を運営したい場合は、ユーザログインを許し、ゲストとのサービスに差をつけたり、不正な利用を予防する必要がでてくる。また、グループで運営するサイトや、Wikiのようにボランティアでコンテンツを作成するサイトの場合にも同様である。この場合、グループの管理やアクセスコントロールについて、考える必要が出てくる。
一人で管理するのか、複数人で管理するのか。一人の場合は、ユーザ登録は管理者だけができるとして、自分を管理者として何でもできるユーザにしておけばいい。複数人の場合はモジュール管理できる「サーバ管理者」と、コンテンツを作成する「コンテンツ管理者」にわけるのがいいだろう。商業利用の場合には、管理職による承認が必要なこともある。そのような場合は、Drupalにはワークフローの機能があるので、「コンテンツ管理者」がコンテンツを作成すると、「管理職グループ」に属するユーザが承認すると公開される、といったこともできる
ブログをおくのかどうか。これはブログモジュールを追加するかどうか、ということになる。

これ以外にも状況によって多数の考慮点があるだろう。ここでは、個人サイト（すべてのコンテンツ作成者＝サーバ管理者）という前提でお話をすすめる。

コンテンツの作成

コンテンツの作成は、メニューの「コンテンツの作成」から始める。これを開くと、コンテンツの種類を選ばせる画面がでる。

代表的なコンテンツの種類は以下の通りである。

ページ: ふつうの静的なページ。タイトルやサイトの説明、問い合わせ先の表示、などに利用できる。
ストーリー: 記事を書くときに一番使う。
Book: 複数メンバーで長編の記事を書いたり、この文書のような解説書を作成したりするのに向く。構造化された文書作成ができる。