Drupal サイト開発時のワーストケース

こんにちは。自社サイトのリニューアルを Drupal 8 で行っていて、今までのようにはいかずに四苦八苦して泣きそうな大野です。

今回は他社で制作されたサイトを弊社で改修する案件をいただいた際に、 Drupal をあまりよく知らない方が陥るワーストケースを紹介します。

Drupal は自由度が高い反面、好き勝手に実装できてしまうことが多く中身がカオスになりがちです。今回紹介している方法が絶対に正解と言うことではありませんので、こうした方がよりクリーンに作れるよと言う観点でご覧いただければと思います。

Drupal サイト構築全般

コーディングスタンダードを無視

独自のスタンダードを適用しているケースがあります。郷に入っては郷に従いましょう。Drupal には良く整備されたコーディングスタンダードとドキュメントが用意されています。

Drupal コーディングスタンダード 日本語訳

モジュールの Zip ファイルなどの不要なファイルをアップロード

モジュールなどをダウンロードした際の圧縮ファイルがサイト内に残っていることがあります。容量の無駄ですので、極力意味のないファイルをサイト上にアップロードするのはやめましょう。

開発版のモジュールを使用

開発版とされているモジュールを利用しているサイトがあります。開発版のものはアップデートをサポートしていないことが多く、運用後のアップデートが困難になる可能性があります。

また、開発版にしか無いような修正があるモジュールはあまりメンテナンスされていないものが多く、脆弱性が見つかっても放置されるケースが高い傾向にあるので運用時のリスクが高いサイトになってしまいますので、利用は避けたほうが無難です。

カスタムモジュールやカスタムテーマを指定のディレクトリ以外に入れる

Drupal ディレクトリ直下の modules や themes ディレクトリにカスタムファイルをインストールしているサイトを見かけます。Drupal はそれらのディレクトリにカスタムファイルがあっても認識しますが、カスタムモジュールやテーマなのか判断しづらくなりますので、予め用意されている sites/all/modules などの専用ディレクトリにインストールするようにしましょう。

参考: Drupal 7 のディレクトリ構造とその役割

フロントエンド

ベーステーマとして配布されているテーマをそのまま改造して使う

Zen や Omega テーマなどをそのまま直で編集して使われているケースがあります。

これらのテーマはベーステーマと呼ばれるもので、直接編集することは想定されていません。本来はそれらのテーマをベーステーマとしてサブテーマを作り、オーバーライドすることが正しい使い方です。

テーマという性質上あまり無いとは思いますが、ベーステーマはすぐにアップデートできる状態にしておかなければ脆弱性が発見された時の対処が困難になってしまいます。

Zen などの高機能なテーマは学習すると非常に早く開発ができる一方で、開発に関する多くのルールがあります。テーマ開発の初心者であれば、まずはテーマを一から開発できるようになってからこのようなテーマを活用すると、より良いテーマを作成することができます。

Java Script のライブラリや CSS を直接 html.tpl.php に書き込む

html.tpl.php の head タグ内に直接 JavaScript のライブラリを読み込むテーマがあります。

一見問題ないように見えますが、この方法ですと Drupal のコントロール下から離れてしまいますので、読み込みの順序の制御できないなどの不具合が発生します。

CSS や JavaScript を追加する方法は色々とありますが、テーマに付随する JavaScript や CSS であればテーマの .info ファイルに記述するようにしましょう。

参考: Writing theme .info files

バックエンド

PHP Filter モジュールを使ってノードに PHP のコードを書き込む

ノードの Body フィールドに PHP Filter を使ってデータベースを直接読み書きするようなサイトがありました。コードをデータベースに格納してしまうとデバッグするだけでも大変な思いをしますので、特別な理由なく PHP Filter を利用する事は避けた方が無難です。

Views オブジェクトを PHP Filter で処理する

Views に PHP Filter を使って View のオブジェクトを書き換える実装のサイトがありました。データベース上にPHPのコードが含まれている問題箇所の特定が非常に困難になり、メンテナンス性が著しく低下します。

Views のデータを加工したい場合はカスタムモジュールを作って対応すべきでしょう。大体の要件は hook_views_data_alter などの Views API で解決することができます。

何度も言いますが、 PHP Filter が利用されているサイトはカオスな設計になりがちです。

Drupal コアのファイルやコントリビュートモジュールを直接編集して放置

Drupal のコアではめったにありませんが、コントリビュートモジュールなどでは希望する hook が無くてどうしても直接コードを改編するしかない事があるのですが、編集した後にそのまま改変した内容を放置しているサイトをよく見かけます。その後、次のバーションがリリースされた際にアップデートを行うと、改変されたコードまで上書きしてしまうことになってしまいます。

最低限その更新を行ったデベロッパー以外でも分かるように配慮しておいた方が良いでしょう。一般的には Drupal のルートディレクトリ直下に Git のパッチを置くことが多いようです。

独自の PHP ファイルを置いて、そこから Drupal API を使う

独自の PHP ファイルが設置し、 Drupal の bootstrap.inc をインクルードして API を使うサイトがありました。実行スピード向上のメリットは多少有るかもしれませんが、他の開発者にとってはバックドアの様なものです。 Drupal の API を利用する場合は Drupal のモジュールとして実装すべきです。

サニタイズをしないでクエリーを生成

Drupal サイト以前の問題かもしれませんが、SQL のクエリーを URL パラメータから直接生成している実装がありました。例えば以下の様な感じです。

db_query('UPDATE node SET title = "' . $_GET['title'] . '" WHERE nid = xxx');

SQLインジェクションし放題です。本来は db_update() を使うのが適切ですが db_query() を使う場合でも引数として値を渡しましょう。

db_query('UPDATE node SET title = :title WHERE nid = xxx', array(':title' => $_GET['title']));

こんな記事を書いている私ですが、初心者の頃は同じようなことをやってしまった覚えがあります。面倒でも決められたルールを守ることで最終的には時間の節約になりますので、コードを書く上ではその場限りのものにならないよう気をつけていきたいものです。

突っ込みどころがありましたらコメント欄からこっそり教えてください。