いよいよ、Drupal 7 が正式にリリースされました。
　2010年の年初に最初のアルファ版がリリースされてから、おおよそ１年をかけての正式版のリリースということになります。
　昨日（1月5日）、drupal.org の Twitter アカウント からリリースを宣言する ツイート が行われて、私も RT しましたが、
　日本ではともかく、世界的にはかなりの速度で多くの方々が関連ツイートされていたようで、そこからも期待の大きさが窺われます。
　今回のリリースのために尽力された方々に対して、改めて感謝したいと思います。

　さて、リリースページによると、Drupal 7 の（おそらく Drupal 6 と比較した場合の）メリットとしては、
　（1）より簡単に
　（2）よりフレキシブルに
　（3）よりスケーラブルに
　という３点が挙げられています。
　他にもいくつか特徴が挙げられていますが、これらは Drupal 7 の大きな開発方針と捉えることができると思いますので、
　「これらが具体的にどういう改善に基づいているのか」「その結果、実際にどのような効果が得られるのか」について、
　Drupal 上で開発している者の一人として、また、Drupal サイトを管理している者の一人として、
　今後、よく検討してみたいと思います。
　以下は、Drupal 7 をローカル環境にインストールして動かしてみた段階、および、非常に荒い情報収集を通じての、
　現時点においての簡単なレポート（レビュー）になります。
　これは、Drupal 7 をインストールした直後の、コンテンツが何もない状態での最初期の画面のキャプチャーです。　レイアウトデザインは、デフォルトのテーマである「Bartik 7.0」によるもので、
　Drupal 6 時代のデフォルトテーマである「Garland」と比べると洗練された印象です。
　一般ユーザーに対して表示される通常の画面ですが、
　管理者としてアクセスしているために、ページ上部に管理者用のメニューバー（黒色の背景部分＆灰色の背景部分）が表示され、
　そこから各管理項目にアクセスできるようになっています。
　この状態から、ある管理項目画面への最初のアクセスは Ajax 対応しているため、ページ遷移を伴うことなく、
　迅速に管理画面を呼び出すことができるようになっています。
　ただし、現状では、ある管理項目から次の管理項目へは、何故か、通常のページ遷移を伴う移動になっていました。
　それでも、通常画面の上にオーバーレイとして管理画面が表示されており、
　オーバーレイ画面を消去することで通常画面に迅速に復帰できるため、管理作業を終えた後のページ遷移が不要になっています。
　次は、モジュール管理画面のキャプチャーです。　この部分は、管理用テーマの「seven」による描画になっています。
　右端に、Drupal 6 にはなかった「OPERATIONS」というカラムが設けられ、
　そこに、モジュールによっては、「Help」「Permissions」「Configure」へのリンクが設定されています。
　「Configure」リンクからは、各モジュールの設定画面を呼び出すことができるようになっています。
　これらの新しいユーザーインターフェースからは、サイト管理者のワークフローを踏まえて、
　「極力余計なページ遷移を不要にする（＝ページ遷移中の手待ち時間を最小化する）」
　「目的とする管理項目ページに迅速にアクセスできるようにする」
　などにより、「サイト管理のために要する手間・時間を最小化する」という開発姿勢を感じ取ることができます。
　つまり、このあたりの変更点は、「（1）より簡単に」という開発方針の具体化の一つということになるでしょう。
　次に、Drupal における開発の一面を担うモジュール開発が、Drupal 7 においてどのようになるのかを概観してみたところ、
　大きな変更点としては、次の２点を認識することができました（ただし、この点については、まだ他にもあるものと思われます）。
　（1）よりオブジェクト指向と言われるプログラミング手法に対応した
　（2）データベースへのアクセス方法を、より抽象化した方法に変更した
　このような対応をすることで、一般的には、
　（A）個々のプログラマーにおいては、Drupal 7 が、開発用のフレームワークとしてより充実化・高機能化する（*1）
　（B）アウトプットにおいては、Drupal 7 上で、より大規模なシステム、アプリケーション、サイト開発が行いやすくなる
　という利点が考えられます。

　特に（2）による、　という点は、Drupal サイトの所有者・管理者・開発者にとって、非常に大きなメリット（＝アップグレイド要因）であると言えます。
　開発者（プログラマー）は、Drupal 6 においては、ある基本的なコーディング・ルールに従うことでこの攻撃に対処してきましたが、
　Drupal 7 においては、もはやそのようなコーディング・ルールを意識する必要はなく、
　Drupal 7 のデータベース・アクセス用の API を利用するだけで、この攻撃に対処できることになります。
　つまり、開発者にとっては、Drupal 7 の API を利用することそのものが SQL インジェクション対策となるわけです。
　そして、これは、Drupal 7 のコアだけでなく、Drupal 7 上の全てのモジュールについても同様であるため、
　サイトの所有者・管理者にとっては、
　システムとして Drupal 7 を選択するということが、即ち、SQL インジェクション対策となるということを意味しています。
　Drupal 7 を利用することにより、開発者に依存していた、つまり、属人的に行われていた SQL インジェクション対策を、
　システムとして担保できるわけです。（*9：Drupal 7.32 で関連する脆弱性が発見・修正されました）
　このように、SQL インジェクションという、甚大な被害をもたらす恐れのある大きなリスクを回避できるという点、
　すなわち、セキュリティ面における堅牢性の大幅な向上は、Drupal 7 の非常に大きな進化であり長所であると言えます。
　そしてこの点は、上記（A）（B）をより促進するものと考えられます。（*8）

　また、利点（A）により、今後一層モジュール開発が促進されることが期待できるため、
　（C）一般ユーザーにおいても、Drupal 7 を、より機能的に充実した CMS として用いることができる（*2）
　という効果が生まれるでしょう。
　このあたりの変更点は、「（3）よりスケーラブルに」という開発方針の具体化の一つと言えそうです。
　この日記の昨年12月19日のエントリー「Drupalの２つの側面」でも言及したように、
　Drupal には、「ノン・プログラマーのための CMS」としての側面と「プログラマーのための CMS」という側面があるわけですが、
　上記のような対応から、Drupal 7 においては、「プログラマーのための CMS」という側面をより強化することにより、
　それが結果的に「ノン・プログラマーのための CMS」としての Drupal の魅力を高めていくという、
　Drupal のこれまでの既定路線をより強化していると見ることができるでしょう。
　ただ、（B）のような利点が生まれることから、
　今後は、より「システム構築のためのフレームワーク」的な性格も強まっていくように思われます。
　次に、Drupal における開発のもう一面を担うテーマ開発が、Drupal 7 においてどのようになるのかを概観してみたところ、
　大きな変更点としては、次の４点を挙げておきたいと思います。
　（1）デフォルトのテーマエンジンが「PHPTemplate」に設定された
　（2）テンプレートファイル関連の一部変更：一部テンプレートファイルの改廃や命名規約の一部変更が行われている
　（3）Drupal 変数関連の一部変更：変数名の一部見直し等が行われている
　（4）class 名・id 名の一部変更：より意味のある命名とする方針で一部変更がなされている
　他にも、細かい点で非常に多くの変更点を確認することができました。
　これらについては実際に使ってみないと何とも言えませんが、情報レベルでは、より合理的な変更のように感じました。
　このあたりの変更点は、「（2）よりフレキシブルに」という開発方針に基づくものかもしれません。（*3）
　現状で Drupal 5.x を利用されている方は、Drupal 5.x のサポートは終了してしまうため、
　公開サイトであればセキュリティ面での理由から、Drupal 6（最新版） ないし Drupal 7 への移行が必要となるでしょう。
　現状で Drupal 6.x を利用されている方は、情報収集等を通じて、
　アップグレードに伴うデメリットや、Drupal 7 自体のメリット・デメリットを検討すると共に、
　それを機会に、今のサイトやシステムの問題点や今後の方針等を再検討してみるといいかもしれません。
　現時点では Drupal 7 対応モジュールが全モジュールの約１割強という状況ですし、
　Drupal 6 に特に問題があるわけでもないため、特に急ぐ必要はないとは思われます。
　Drupal 7 のもう一段のブラッシュアップを待つという選択肢もあります。
　その上で（Drupal 6 のサポートは継続されるわけですから）、アップグレードしないという選択肢もあり得ます。
　もちろん、必要とするモジュールが Drupal 7 に対応済みであり、メリットの方が大きいと判断すれば、
　即座にアップグレードしてもよいでしょう。
　また、現状で Drupal を利用されていないという方は、これを機会に Drupal という CMS・フレームワークについて、
　既存のものと比較検討してみると良いかもしれません。
　サイトやシステムに高い機能を求める場合や複雑な処理が必要となる場合には、Drupal は良い選択肢になると思います。（*4）
　以上、Drupal 7 の管理面・開発面（モジュール開発・テーマ開発）について、非常に大ざっぱに見てきましたが、
　私的には、非常に良い方向で変更が行われているような印象を受けました。
　TransNetCreation としては、自ら開発したモジュールについて、コード内容や機能を再検討しつつ、
　Drupal 7 への対応を進めていきたいと思います。
　そして、その後ということになりますが、当サイトとしても、
　特に速度面でのメリット「（3）よりスケーラブルに」に期待しつつ、Drupal 7 へアップグレードしたいと考えています。（*6）

　TransNetCreation としては、自らの対応や情報収集等を通じて得た知見に基づいて、
　有益な情報につきましては、今後も、この日記やコラム Power of Drupal などでレポートしていきたいと思います。（*5）（*7）

　*1：フレームワークとしての Drupal の特徴については、
　 　　コラム「Drupal はウェブ・アプリケーションの夢を見るか 」でも説明を試みています。
　*2：CMS としての Drupal の特徴については、
　 　　コラム「Drupal、６つの自由自在をもたらすCMS 」でも説明を試みています。
　*3：「（2）よりフレキシブルに」という開発方針については、
　 　　CCK モジュールをコアに取り込んだということが最も大きな変更点のように思われます。
　*4：Drupal を採用する意義については、Drupal & TransNetCreation でも簡単な説明を行っています。
　*5：2011年02月19日、当日記のエントリー「Entity化するDrupal」において、
　 　　Drupal 7 において導入された概念・実装である「Entity」について解説しました。
　 　　（※2011年02月19日追記）
　*6：2011年03月08日、当サイトを Drupal 7 にアップグレードしました。
　 　　（※2011年03月08日追記）
　*7：2011年03月24日、コラム Power of Drupal vol.3 のエントリー
　 　　「Drupal 7 における、オリジナル「Entity」導入のメリット・デメリット」を公開しました。
　 　　（※2011年03月24日追記）
　*8：Drupal 7 がその API 自体に SQL インジェクション対策を組み込んでいるという点は、
　　　非常に大きなメリットであるために（かつ、日本においては、その点があまり指摘されていないようですので）、
　　　その点について、1つの段落を設けて、本文中に追記しました。
　 　　（※2011年08月18日追記）
　*9：2014年10月15日、Drupal 7 シリーズに対して security update が行われ、Drupal 7.32 がリリースされました。
　　　これは、追記 *8 で言及した、
　　　Drupal Core に組み込まれたデータベース・アクセス用の API の中で発見された脆弱性を修正するものです。
　　　詳細は明らかではありませんが、上記 security update によると、
　　　「特別に組み立てられたリクエストによって arbitrary SQL execution をもたらすことを可能にさせる」ということで、
　　　かなり SQL インジェクションに近い脆弱性であるようです（こちらの 英文記事 ではやや詳しくレポートされています）。
　　　そのため、Security risk が「Highly Critical」とされており、Drupal 7 を用いたサイトでは早急なアップデートが望まれます。
　　　追記 *8 では、「Drupal 7 では SQL インジェクション対策がなされている」旨、書きましたが、
　　　当然、セキュリティにおいては「完全」という概念は無く、
　　　大手プロプライエタリのソフトウエアがそうであるように、Drupal と言えどもその例外とは言えません。
　　　しかし、Drupal には、素晴らしい Security Team が存在し、迅速に対策を講じてくれています。
　　　脆弱性が存在したこと自体は残念ですが、それはソフトウエアの宿命とも言え、発見と対策が迅速かつ継続的に行われることが重要です。
　　　今回も迅速に対策が講じられたことに、Security Team の方々・関係者の方々に感謝致します。
　　　なお、上記でリンクした 英文記事 によると、今回の攻撃手法は匿名ユーザーによって公開され、
　　　それを、匿名クライアントから依頼を受けて Drupal のシステム監査を行っているドイツの PHP セキュリティ企業が発見した
　　　ということのようです。
　　　ここで匿名クライアントとは、おそらくは、Drupal の開発・管理主体そのものもしくはそれに近しい主体であるか、または、
　　　高レベルで Drupal を利用している組織・団体もしくは企業であると推察されますが、その点からも Drupal の信頼性が伺えます。
　 　　（※2014年10月16日追記）　

　TAG 1 :: DIARY :: AROUND THE CORNER :: Drupal
　TAG 2 :: DIARY :: AROUND THE CORNER :: TransNetCreation