Drupalの概要や基本機能について紹介します。と言っても、基本的には各Drupal解説サイトの説明を読めば十分だと思います。
以下は http://drupal.org/about の日本語訳です。
Drupalとは、個人もしくはユーザのコミュニティが、ウェブサイト上の多種多様なコンテンツを簡単に公開、管理、体系化することができるフリーなソフトウェアパッケージです。以下のように、何万もの人々や組織が、数々の多様なウェブサイトの構築にDrupalを使用しています。
Drupalは今すぐダウンロードすることができます。Drupalには使いやすいウェブ・インストーラも用意されています！組み込みの機能と、自由に利用可能なアドオンモジュールを組み合わせれば、以下のようなことが可能になります:
他多数。
DrupalはGPL("GNU General Public License")の下に配布されるオープンソースソフトウェアで、数千のユーザと開発者からなるコミュニティにより保守および開発されています。Drupalの方針に賛同される方は、プロジェクトに協力して、あなたのニーズを満たすために、Drupalを拡張そして洗練させてください。
以下は http://drupal.org/principles の日本語訳です。
以下は http://drupal.org/node/346217 の日本語訳です。
Drupalは事実上あらゆる種類のウェブサイトを構築するのに使われる非常に強力で柔軟なフレームワークを提供しますが、Drupalがあらゆる状況において必ずしも最適な解決策であるとは限りません。
以下のようなケースではDrupalが最適な選択ではないかもしれません:
とは言ったものの、以下のような多くの状況ではDrupalは優れた選択肢となります:
以下は http://drupal.org/node/65922 の日本語訳です。
Drupalを検討している人は、次のことを理解しておくべきです。Drupalの開発は常に最先端で行なわれており、各メジャーリリースでは抜本的な改良が行なわれることがあります。(Drupalのバージョン番号が意味するものの詳細については、 http://drupal.org/handbook/version-info (日本語訳) を参照してください。)アップグレードパスによりデータは確実に保護される予定ですが、以前のDrupalコードとの後方互換性はありません。
Drupalの創始者Dries Buytaertの説明によると:
私がDrupalを最初にリリースしたとき、私は主に技術的な正しさを求めることの方に興味があったので、後方互換性は保たないという選択をしました。後方互換性を保つことは、しばしば歴史的なお荷物をずるずると引きずる羽目になりますし、これはPHPのようなインタプリタ型言語では重大なパフォーマンスコストとなりえます。そのため、私たちはみんなのデータを壊さない代わりに、コードはどんどん変えていこうと決めたのです。私たちのミッションは、Drupalを速く、小さく、クリーンに、そしてとにかく技術の最先端にすることになりました。始めのうちは、私は完全に、そして徹底的にDrupalのコードの美学にこだわっていました。私と、多くの仲間たちで、他のものよりもコードをより少なくし、より洗練させて、何らかの形でよりよくしようとすることに時間を費やしました。
これは正しい選択でした。年月を重ねるにつれ、我々は後方互換性を保ったままではおそらく起こらなかったであろうたくさんのイノベーションが起こるのを見てきました(ノードシステムは最も顕著な例のひとつです)。開発者たちは、常に可能なかぎり最善の方法で自分たちのアイディアを実装する裁量の自由を持っていました。これは他の多くのコンテンツ管理システムと比較して、Drupalが持つ有利な点です。Drupalがどのように広まったのか、そしてどのようによりフレキシブルで他システムよりもニッチな用途をカバーできるように成長したのかを見てみると興味深いものです。何かあるとすれば、それは我々が後方互換性にあまり関心を持たなかったという事実、そして技術的な正しさにこだわる我々のひたむきさに起因していると言えるでしょう....
....Drupalの主な強みが絶え間なく変わるWeb開発の状況に対応できる機敏さと、ほとんど無限量の柔軟性および拡張性を開発者に与えることだという事実を踏まえると、私は少なくとも現在のところ、後方互換性を維持することよりも絶えず革新する力を維持することの方がより重要だと感じます。このことに本質的な価値がないならば、我々はいま誰もDrupalを使っていないでしょうし、私はこれが我々の将来性の基礎となるだろうと強く信じています。これまでは常にそうでした。
以下は http://drupal.org/node/278173 の日本語訳です。
特にDrupalコミュニティへ新たにやってきた人たちがよくする質問は「なぜ○○の機能はコアに入ってないの？」というものです。この○○というのは大抵、ほぼすべてのDrupalウェブサイトで使われているCCKやViewsのような"ユーティリティ"モジュールだったり、ある種のウェブサイトで必要となるFivestarやLoginTobogganのようなモジュールだったりします。
コアに含まれていないものに対する最も大きな議論のひとつは、それがひとたびコアに入ると、"ロックダウンされる"傾向があるということです。たとえば、taxonomyシステムは、それが導入された2002年のDrupal 4.0から、ほとんど何も変えることができませんでした。Drupal 4.7ではフリータギングが追加され、Drupal 6ではフォームのクリーンアップが完了しましたが、そのほかの点では基礎となる構造は6年ものあいだ変わらぬままでした。
対照的な例として、ViewsモジュールはDrupal 5からDrupal 6の間に完全に書き直され、数えきれない方法で大幅に改善されました。元々のViewsはノードのリスト作成を扱えるだけの代物でしたが、書き直されたバージョンではあらゆるもののリスト(ノード、taxonomy、ユーザ、その他なんでも)が扱えるようになりました。これは拡張モジュールが、Drupalコアに比べてその場その場で色々なことを変更する柔軟性を持っているからこそ実現できたことです(それがきわめて重要な拡張モジュールであったとしても)。
したがって、コアが最適化されてない状態の機能で何年間も困ることがないように、拡張モジュールがコアに移される前にはcontribの中で適切に審査されることが非常に重要となります。Drupalコアに追加する機能はどんなものでも、比較的変更なしの状態で少なくとも3年維持できるくらい良いものである必要があります。
人々はしばしば、Joomla!のようなパッケージをダウンロードしたとき、それにはより多くの機能が内蔵されているという事実を嘆きます。Drupalのコアは比較的シンプルです。Drupalコアのツールで小さなコミュニティサイトを構築することはできますが、もっとシリアスな種類のサイトを構築する際にはDrupal contribへ踏み出す必要があります。
しかしながら、Drupalコアがコードを持てば持つほど、開発チームがそれを適切にテストし、リリースを済ませるまでに、より長い時間がかかるということを思い出してください。また、そのコードの一部から持ち込まれる細かいバグが、他の多くに影響を与える可能性もそれだけ増えていくことになります。コアは小さく保っておき、"hook"により拡張モジュールがコアを拡張できる機会をたくさん用意しておくのがDrupal流のやり方です。
一部の人たちは、自分たちのウェブサイトを18-24ヶ月ごとにアップデートするのは嫌だということで、リリースサイクルは長い方がよいのだと主張するかもしれません。しかし、人々がDrupalを使う理由の重要な一部は、その絶え間ない改善であり、以前よりも新たな可能性を提供する各リリースであることを思い出してください。我々は各リリースで、努力の結果がDrupalのウェブサイト構築を次のレベルへ向かうために使われるのに十分であることを保証する必要があります。
あるものをコアに入れるには長い時間がかかります。contribと違い(contribは基本的に各モジュールのメンテナが自分の領域でそれなりに自由に遊べる"ワイルド・ウェスト"です)、コアに入れられるコードはその一行一行を細かいところまで注意深く調べられます。これはDrupalコアが文字通り何百万ものウェブサイトで使われているからこそ必要となるものであり、コミュニティ側のこの詳細な注意深さは、Drupalの重要な強みのひとつとなっています。コアに対する変更の多くは、巨大なコミュニティによって価値があるものと考えられるまでに何百回もの改訂をごまんと経験しています。
ほとんどすべてのDrupalサイトが使用するCCKやViewsのようなユビキタスなモジュールでさえ、あらゆる種類の主要な開発作業を行なっているのは、ほんの一握りの人たち(多くの場合は一人)だけです。これらのモジュールのメンテナたちは、しばしば単にDrupalの現行バージョン用のモジュールに対するバグレポートや機能リクエストを受け付ける以上の手間ひまをかけており、多くの場合それは無償の時間を使って行なわれています。何かをコアに入れようとして時間を費やすことは、たった今それを使っている何十万もの人たち全員のためにモジュールのサポートを提供することにはなりません。多くの場合、これらのモジュール(またはそれらのモジュールの重要な一部)をコアに持っていく試みには、作業のためのさらなる開発者か、モジュールメンテナへの資金提供が必要になります。
