Drupalでの開発時に避けるべき5つの間違い：アーキテクチャー編

Drupalは、最も柔軟なCMSの1つです。この記事では、DrupalでWebサイトを開発、運用するにあたり避けるべき5つの間違いを、アーキテクチャ、セキュリティ、パフォーマンス、インフラストラクチャ、およびWebサイトのライフサイクル管理の観点から取り上げます。 アーキテクチャーの観点から言えば、Drupalによる成功とパフォーマンスを保証するためには以下の事柄をしっかりと検討する事が大切です。

• どのように、コンテンツを構造化するか
• どのように、コンテンツの表示を設定するか
• どのように、機能を整理するか

コンテンツのアーキテクチャー

コンテンツはウェブサイトの本質です。サイトの存在理由そのものです。コンテンツの構造を決定することはウェブサイトアーキテクチャを作成する最初のステップです。

ベストプラクティス

フィールドとコンテンツタイプを含むコンテンツの構造を設計します。コンテンツのアーキテクチャを明確化することは、優れたパフォーマンス、より良いユーザーエクスペリエンスやメンテナンス性の向上につながります。

Viewsに関しては、特定のコンテンツタイプで使用可能なフィールドに依存することが多いため、ここでは「ディスプレーアーキテクチャー」の内容と重複しているものもあります。

間違い：

コンテンツタイプをたくさん作成する。

結果：

これはコンテンツ制作者を混乱させます。

具体例：

コンテンツタイプ「ニュース」と「記事」はほぼ同じです。

解決策：

コンテンツタイプを再利用し、標準化しましょう。

間違い：

すべてのコンテンツタイプに対して新しいフィールドを作成する。

結果：

これはリソースの無駄であり、パフォーマンスの低下につながります。

具体例：

学校のサイトにおいて、「学校の所在都市」の都市名と、「教師の所在都市」の2つの異なるフィールド都市名としてを利用した。

解決策：

「都市名」というフィールドを作成し、それを再利用しましょう。フィールドに関するレポートはexample.com/admin/reports/fieldsで確認する事ができます。

間違い：

ノードのないコンテンツタイプを残しておく

結果：

不必要なコンテンツタイプは、複雑さの原因となります。

解決策：

「サイトを構築するときに、そのコンテンツタイプが本当に必要かどうか再評価しましょう。コンテンツリストをフィルタリングして、未使用のコンテンツタイプを特定し削除しましょう。

ディスプレイアーキテクチャー

Drupalはコンテンツを様々なリージョンに、様々な形式で表示させることができます。

ディスプレイアーキテクチャには、Views、Panels、およびContextモジュールが含まれます。

ベストプラクティス

必要なときにのみコンテンツがレンダリングされるように、ディスプレイアーキテクチャを設計します。
できるだけ最適化や再利用してください。また、常にロジックとディスプレイを分離するようにしてください。
テンプレートに関しては基本的なベーステーマから始め、そこから良く学んでください。
サイトの外観を簡単に変更できるかどうかは、ディスプレイアーキテクチャーの次第です。

間違い：

Viewsでリストを作成する際に、その都度、Viewを作成する。

具体例：

ロンドン、パリ、リスボンの求人情報のリストを表示するために、個別に3つのViewを作成する。

解決策：

作成しようとしているViewを良く分析して、既存のViewの再利用で対処する事ができないか良く考えてみましょう。特定のパラメータに応じたリストを表示する場合にはContextual Filtersがを利用しましょう。

間違い：

データベースやテンプレート（.tpl .php）ファイル内にPHPコードやその他のロジックを記述する。

具体例：

ブロックの表示条件を決定するPHPコードをテンプレート内やデータベース内に記述する。

解決策：

PHP、Webサービスの呼び出し、SQLクエリ、などあらゆるロジックは、モジュール内または、必要に応じてtheme preprocess functionsに記述する。

推奨ツール：テーマ開発モジュールhttp://drupal.org/project/devel_themer

このモジュールを有効にすると、Webページのさまざまな領域にマウスを置く事で、そのセクションをレンダリングするテンプレートを表示させることができます。

サイトまたは機能のアーキテクチャ

サイトのアーキテクチャには、サイトの挙動や、モジュールの数や、それらがどのように相互的に作動するのかが含まれます。

ベストプラクティス

コードと使用するモジュールの数を最小限に抑えて、サイトから無駄をそぎ落としてください。
カスタムコードを書くのではなく、できる限りモジュールを使用してください。

また、ViewsやPanelsなどの鍵となる主要モジュールの使い方を熟知しましょう。 カスタムコードを記述する際にはDrupalのコーディングスタンダードに従ってください。 定期的にアーキテクチャを再検討する事も重要です。

間違い：

沢山のモジュールを使用した。もし、200以上のモジュールを有効化しているようであれば、本当に全てのモジュールが必要かどうかを検討する必要があります。

具体例：

元々は多言語サイトを作成しようと計画していたが、単一言語のみでの運用となった。しかし、多言語に関する全てのモジュールや、それに関わる寄与モジュールがインストールされ有効化されている状態。

解決策：

サイトを定期的に再評価し、未使用のモジュールをら無効化、アンインストールし、コードベースで削除しましょう。

間違い：

ロールが多すぎて、メンテナンスやセキュリティチェックをするのが困難

具体例：

当初の計画では多数のロールが必要とされていたが、実際にはほとんどのロールが使用されなかった。これはロールを現実世界の役職と一致させようとした場合に起きる事が多い問題です。

解決策：

サイト内のロールとパーミッションを再検討しましょう。また、ロールを機能毎にグループ化して、権限の継承やカスケードを利用してシンプルにできないかを検討しましょう。

間違い：

ある機能を実現するための、寄与モジュールがあるのにカスタムコードで対処しようとする。

具体例：

問い合わせフォームからの送信内容を、サイト管理者にEmailで送信する機能を実装するのにカスタムモジュールを作成した。

解決策：

この機能を実装するモジュールとして、十分にテストされているWebformモジュールがすでに存在します。あなたが求める機能を実現するモジュールが存在しないかをまずは調べてみましょう。

間違い：

コアモジュールや寄与モジュールをハックしたため、思わぬ挙動を引き起こしたり、アップデートが困難になってしまった。

解決策：

もし、コアや寄与モジュールがの挙動をカスタマイズする場合には、hookを使用してカスタムモジュールをビルドして挙動を変更します。もしあなたがサイトを他者から引き継ぐ際には、コアやモジュールに変更が加えられていないかを確認するために、Acquia InsightまたはHacked！モジュールを使用してください。モジュール（推奨ツールを参照）。

間違い：

間違ったhookやDrupal APIを利用したカスタムコード。

具体例1：

トップページでのみ使用されるものについて、すべてのページにロードするhook_initを使用する。

具体例2：

nids、tidsやvids等のハードコーディングされた文字列を含むカスタムモジュール。もしこれらの文字列に変更が生じた場合に、問題の原因を究明することは非常に困難です。

解決策：

カスタムコードは慎重に使用してください。 drupal .orgのAPIを使用して適切なhookとシンタックスを利用してください。APIに関するドキュメント:http://api.drupal.org/api/drupal

終わりに

間違いのほとんどは、Drupalに対する十分な理解がないままシステムを構築したために発生します。Drupalは非常に柔軟にカスタマイズできますが、安易なカスタマイズは単にシステムの維持を難しくするだけではなく、セキュリティやパフォーマンスに影響を及ぼす可能性もあります。Drupalの設計思想を理解し、コアや寄与モジュールでできることとできないことをしっかりと把握することが重要です。