2010年4月2日に、事務所移転しました。新しい事務所の住所は下記の通りです。

〒107-0052
東京都港区赤坂4-1-1 SHIMA赤坂ビル

今後とも、よろしくお願い申し上げます。

本当は、tipsの続きでサブテーマについて実験してみようと思っていたのですが、さる2010年3月4日（日本時間）に6.16がリリースされたのでそちらのアップデートの確認作業に時間がとられてしまったので、Fusionを遊んでみるのは少し延期になりました。

さて、この6.16は重大なセキュリティフィックスがあるとのことで、早めに対応した方が良いでしょう。

セキュリティフィックス

一つはインストール時にクロスサイト・スクリプティングの危険があります。これはインストールされていないサイトでのみ影響がある問題です。次にdrupal_goto()のフィッシング・アタックに使わえる可能性があるというもので、これはサイト運営者にとってはかなり頭の痛い問題です。次にLocaleモジュールのクロスサイト・スクリプティングの問題です。大抵の日本のサイトは使っていると思いますので、影響必至です。最後にブロックされた状態のユーザのセッションを復活できるという問題です。セッションを閉じた状態でユーザをブロックした場合に発生するそうです。

いくつかのDrupalサイトを運用してみるとわかるのですが、「コンテンツ毎にちょっと違うレイアウト」を試したいという要望が結構あります。でも、テーマの骨格となるブロック設計というのはテーマをインストールした時に決まってしまいます。UIだけでは、このブロックを変更できません。

今日は、これを解決する方法をいくつかご紹介します。

Panelsモジュール

Drupal のブロックレイアウトをCSSやテーマファイルを変更せずに、レイアウトを自由に作り替えられる優れたモジュールです。非常に強力です。

Skinrモジュール

リンクカラーやちょっとしたレイアウト修正を行うのにわざわざテーマのCSSを修正したりするの面倒ですよね。このモジュールをそれをUIから定義できるようになります。先のPanelsモジュールやViewsにも使えるので、これ便利かも！って感じです。

Fusion

これまだ発展途上なんですけど、Drupal UIからレイアウトを調整できるようなベース・テーマを開発するっていうプロジェクトなんです。私もこれに参加してみましたので、また進捗あったらブログに書きますね。

Amazon S3について少し研究したいと思います。昨年からAmazonのウェブサービスについて、EC2やRDSといった機能については、ちょくちょく調べているのですが、今回はAmazon S3です。じゃ、S3とは何かというと、Amazon Web Services LLC(以下、AWS)が提供しているインターネット上で使えるストレージ・ウェブサービスの事です。と書くと、既にApple社のmobileMeのiDiskと比較してしまうと思います。iDiskとの違いは、iDiskはWebDAVという共通技術を元に作られているいわば「ファイル共有サービス」です。S3はITサービス開発者の視点からみると、もうちょっと面白くて、「ファイル共有を実現するための機能サービス」といったところでしょうか？

なので、AWSそのものが、iDiskのような洗練したインタフェイスを提供していません（コマンドラインはあります）。ではどういった機能が提供されているのでしょうか？

AWSのMySQLベースのリレーショナル・データベースを使ってDrupalをインストールしてみました。

AWS RDSのサービス申込をしてから、Javaベースのコマンドを用意します。こちらからダウンロードできます。これを端末にインストールします。インストールはここにある通りやれば簡単に動作させることができます。このコマンドはEC2のコマンドツール同様にEC2のインスタンスマシンにインストールする必要はありません。手元のWinやMacOSでもまったく構いません。コマンド・ツールのインストールと設定についてはここに詳しいので、ここではデータベースの作成方法とアクセスするまでについてメモしておきます。

今年は少しずつブログを書いていくつもりでしたが、やはり2週間以上間が空いてしまいました。弊社が管理運営をお手伝いしているウォルナッツさんのブログはほぼ週に5本以上のブログを書いています。これって本当に凄いことなんですね。

さて、今年の初めに「Drupalってここが嫌」は書いたのですが、あんまりDrupalの利点を書いていなかったと思いますので、今日は少しDrupalの利点について書いてみたいと思います。

検討の結果、携帯電話端末のセッション管理をセッションIDをURLに埋め込むという方向で行こうと決定しました。ただ、デフォルトでの設定で動作しているDrupalのURLを見ると、PHPSESSION等というものが見あたらないと思います。Cookieでセッション管理を行うのがデフォルトだからです。まずは、セッションIDをURLに入れるところから始めましょう。

Drupal のテーマを作ったことあるなら、すぐにリンクタグ（<a>）を作る場合、主に使う関数 l() を修正する必要があると考えると思います。しかし、前回のブログでも見たとおり、セッション・ハンドラーは独自に作り直していますが、セッション管理機構はPHPのものを使っていますので、これにそった形で修正を進めるのが良いと思います。

先日は、Drupalのセッション管理がどのタイミングで行われ、置き換えられそうだというところまでわかりました。今回は、携帯向けセッション管理を行うためにまず携帯のセッションってどうしているんだろうという事を知る必要があります。

昔、少し調べた（Webアプリじゃなくて、ロードバランサー側の設計を担当しているときなんですが）時に「こんなんでセッション管理って言えるの？」って感じの仕様だったことを思い出して、色々とウェブサイトを漁ってみました。ここのドキュメントが詳しく解説していましたので、少しこの辺りの話は省きます。

個体識別番号とかを使うと、キャリア毎にも若干違ったり、やはりPCサイトとの互換性やiPhone等のスマートフォンの台頭を考慮するとこの手法を使って一生懸命実装するのも、ばからしいと思うわけです。

やはり、ここはURLにセッションを埋め込む方法を使いましょう。ということで、今日までに簡単に方針を決めて、明日から実際にコーディングに入っていきたいと思います。

先日のブログでも少し書いたけど、日本の携帯電話でDrupalは本当に使いにくい。閲覧だけなら、何とかなるのですが、やっぱり編集もしたいという要望も実際にあります。電子メールを使ったブログ投稿ならすぐにできそうですが、将来的にeコマースなどを実現しようと思うと、セッション管理周りはできるように拡張した方がやりやすい。そこでまずDrupalのセッションの管理方法についてコードハックしていきたいと思います。

まず、Drupalのページがどうやって作られるか調べておく必要がありますね。bootstrap.inc を見ればわかるんだけど、

Drupal をまるまる1年じっくり使いサービスを提供してみると、色々と弱点も見えてきます。ここのブログでは、弊社でサービスを提供しているのだから強みを中心に説明していくところなんでしょうが、やっぱりあまり過大評価しすぎるのもどうかと思うので客観的に評価してみることにしました。