Drupal 8についてすべてのCTOが知っておくべき「24のこと」

この記事は「 24 things about Drupal 8 every CTO should know 」の翻訳です。

この記事の目次

Drupal 8への移行について

1.なぜDrupal 8にはそんなに時間がかかったのですか？

Drupalができてから15年、Drupal 8の開発には5年がかかっています。リリースまでに時間がかかっているように感じられます。内部ではDrupal 8にはDrupal 7から見てたくさんの大きな変化がありました。新しいプログラミングのコンセプトやパラダイムが適用され、Drupalはこれまでよりもさらに標準に準拠するようになりました。古く、Drupal特有の作法を排除し、標準的であると広く知られるテクノロジーを受け入れました。Drupal Communityの計画では、今後はDrupal 8のような、大きなメジャーリリースを待つのではなく、徐々に段階的なリリースを行うことでブランチを分けて開発や機能追加ができるようにしようとしています。

2.Drupal 8の構築を始めるとしたらいつですか？

すべてのプロジェクトにとって、Drupal 8を検討するなら今すぐです。ただし、いつDrupal 8に移行すべきかはリスクへの関心度、プロジェクトの機能や複雑さによります。Drupal8用にはまだ安定したリリースではありませんが、Contribute Moduleがたくさんあります。プロジェクトは最終的にはDrupal7で無料で使えたツールのDrupal8版を使って構築できるようになるでしょう。しかしながら、長い目で見たらDrupal 8を選択することはそんなことを圧倒するくらいに有利です。我々は、ここ半年後から一年の間にローンチを計画されているプロジェクトに関しては、Drupal 7より8を使用することをおすすめします。Drupal 8の多言語システムは、根本的なところでオーバーホールされました。すべての多言語サイトではDrupal 8を選ぶべきでしょう。近日中の、動かせないリリース日が決まっているプロジェクトでは、Drupal 8導入による予期せぬバグやリリース後の問題発生などのリスクがあるでしょう。これらの問題は新しいバージョンが発表されて広く使われるようになる前にはつきものと言えましょう。

3.一般的なContributed Moduleが使えるようになるまでにどれくらいかかりますか？

Deesonは、自分たちのプロジェクトで使用している52のモジュールについてメンテナンスを行っています。そのうち11のモジュールはDrupal 8のコアに含まれているため完全にサポートされており、9のモジュールがアルファ版、ベータ版としてコミュニティによりリリースされています。残り32のモジュールはテスト段階ですらありません。もっとも重要なコンテンツ管理ツールがコアプラットフォームに内蔵されているため、Drupal 8は機能を限定した単純なサイトであればすぐに使用することができます。しかしながら、PathautoやTokensのように、自動でメールのタグを生成したり、コンテンツのタイトルに自動でリンクを設定したりするような重要なモジュールが未対応だったりもします。経験上、Drupal 7ではリリースからContributed moduleが使用できるようになるまでに1年かかりました。今回は、Drupal 8のコアがそういったモジュールの多くを組み入れているためもっと早く使用できるようになり、重要なContributed moduleは2016年 6月には使用できるようになると見られます。

4.Drupal 7の開発者はどれくらい学習が必要でしょうか？

Drupal 8での大きな変化は、テーマレイヤーでのTwigテンプレートシステムの導入、コアへのSymfonyフレームワークコンポーネントの導入、プラグインシステムの導入、以前の手続き型プログラミングからオブジェクト志向のプログラミングスタイルに全般的に移行したことなどがあります。そのためDrupal 7開発者がDrupal 8で開発するにはかなりの学習が必要です。Drupal 8は来年にかけて更に注目をあつめるようになり、多くの開発者がDrupal 8で開発をするために必要なスキルについて学習を始めるとみられます。Drupal コミュニティはこの学習に必要な素材の提供についてとても良い活動をしており、Drupal.orgにてDrupalの以前のバージョンよりも優れたドキュメントを提供しています。開発チームは今後半年内に始まるプロジェクトをサポートするために開発者トレーニングを準備する必要があり、そうしなければリスクが残ることになるでしょう。

5.Drupal8を使うとDrupalの構築コストは減りますか？

以前のバージョンと同じように、Drupal 8はライセンス料無しで使用できます。それとは異なり、プロジェクト構築の費用は以前のバージョンのDrupal使用時と比較してまったく違ったものになるでしょう。しかし、Drupal 8の内部の改善により、サイトを管理・保守する長期間のトータルコストを削減できると我々は信じています。新しいプラグインシステムを含む開発の効率のよい手法が導入されたことで、Drupal 8の拡張を以前のバージョンよりも容易にしています。

6.Drupal 8ではサイト構築が早くなりますか？

DX（Developer Experience)として知られる開発者向けの環境において大きな進歩がありました。そのことにより、開発チームの問題解決能力にも進化があるでしょう。コーディングの原則がオブジェクト指向へ変わったことにより、より論理的で開発者寄りの構成になりました。IDEのようなコード編集ツールによって自動でコード生成されることもあります。他にも、TwigテンプレートレイヤーがDrupalのテーマシステムをより良く構成しているため、乱雑なコードは書かれにくくなっています。

Drupal 7との関連

7.Drupal 7からのアップグレード方法はありますか？

Drupal 8にはMigrateモジュールがあります。MigrateはDrupal6や7で作成されたwebサイトのコンテンツをDrupal 8向けにマッピングできる一連のツールを提供します。シンプルなプロセスではありませんが、以前のバージョンからの移行は可能だと言えましょう。

8.Drupal 8リリース後のDrupal 7へのサポートはいつまで続きますか？

Drupal コミュニティはDrupalのひとつ前のバージョンをサポートしています。ですのでDrupal 7はDrupal 9のリリースまではサポート対象です。いまのところDrupal 9の公式リリース日は決定していないので、Drupal 7のサポート終了期限も決まっていません。

Drupal 8の新機能

9.Drupal 8 にはDrupal Commerceがフィーチャーされていますか？

Drupal CommerceはDrupalコアチームではなく、企業― Commerce Guysによりメンテナンスされています。彼らにより、DrupalCommerceはDrupal 8向けのバージョンが活発に開発されています。新しいDrupal 8バージョンでは以前のバージョンのDrupal Commerceに比べ重大な変化があると説明されています。カートへの追加機能の改良や、素早い在庫作成、より直感的な在庫管理などです。

10.Drupal 8 では多言語サイトの作成方法が違うのですか？

以前のバージョンのDrupalでは、部分的にしか多言語をサポートしていませんでした。多言語プロジェクトは通常Drupalの多様な要素を、全く違った手法で翻訳機能を提供している多数のモジュールを縫い合わせるようにして作られます。この一貫性の無さがプロジェクトの予算がかかり、締め切りにプレッシャーを与えます。Drupal 8の多言語サイト構築能力は非常に大きく改良されました。すべてのコア要素の翻訳が同一の、一貫した方法で翻訳されています。Drupalのインストーラーは94の言語をサポートしています。新しい言語のインストールやアップデートを行うための簡単なプロセスもあります。管理画面インターフェイスについては完全に翻訳可能です。画像やファイルのようなAssetについては特定言語に割当てられるか、言語間で共有することができます。

11.コンテンツ編集者にとってのDrupal 8での違いはなんですか？

Drupal 8にはポピュラーなCKEditor WYSIWYG web エディタが搭載されています。標準的にサポートされるツールとなるため、Drupalとの統合もメンテナンスし続けられるでしょう。Drupal 8コアの新しいNevBar モジュールは、すべての管理画面セクションへアクセスできるクリーンな管理ツールです。Drupal 8のquick edit機能はコンテンツ編集者が編集を行う際、フォームをロードする代わりにシンプルな編集と更新を可能にしました。Drupal 8ではメディアの操作でも進化をしました。これまでコアには組み込まれていなかった、ファイルや画像などのアセット管理について優れたインターフェースが提供されます。

12.Drupal 8では複雑なユーザーとコンテンツの権限の操作に変化がありますか？

見えないところではコンテンツのアクセスパーミッションシステムがDrupal 8では書き換えられましたが、動作は変わりません。Contributed Moduleではとてもきめ細かい追加パーミッションコントロールの提供が予想されます。Drupalの以前のバージョンではOrganic Groupがよく選ばれていましたが最近のコアバージョンではリファクタリングされてきませんでした。私たちはDrupal 7の安定した機能を提供するため、Organic Groupの代わりにGroupモジュールを使っていますが、Drupal 8バージョンの開発も計画しています。

フロントエンドとDrupal 8

13. Drupal8のテーマ開発やフロントエンドの標準は変わりましたか？

Drupal7ではPHPベースのテンプレートが容易に書けてしまったことから、本来モジュールに書かれるべきロジックが、テンプレート内に書かれることがありました。しっかりと管理されていないテンプレート内コードは、壊れやすく、バグを見つけにくくなり、新機能を付け加えることが難しくなります。D8でのテーマ開発はTwig の導入により、とても大きく変わりました。開発者はほぼすべての機能的なマークアップをTwigテンプレートで書くことが出来るようになります。開発チームにとって最初の学習コストはかかりますが、長い目で見てよりクリーンでメンテナンスのし易いテンプレートになるでしょう。

14. Drupal8のアクセシビリティはどのように扱われていますか？

WAI-ARIAのランドマーク、ライブリージョン、ロールとプロパティなどがページの動的なエリアのアクセシビリティを改善するために取り入れられました。DrupalのForm APIは別のリージョンでではなく、エラーが起こった場所にインラインで表示されます。音声読み上げ機能を使うユーザーにはJavascriptのアラートも音声でタイムリーに提供できます。新しいタブマネージャーはマウスを使わないユーザーにもロジカルな順番でページ要素にアクセスできるようにします。Drupal8はスクラッチで開発された馴染みのある方法ではなく、標準的なライブラリーを使って機能を構築します。ライブラリ開発者をまきこみ、外部の大きなコミュニティとのパートナーシップから最高品質のテクノロジーが開発できるようになります。これらの効果の一つは、特定機能のアクセシビリティがその分野を良く理解しているチームから提供されるようになることです。よいサンプルとしてjQuery UIライブラリーが提供するオートコンプリート機能が挙げられます。DrupalコミュニティはjQuery UIコミュニティに対してアクセシビリティを向上させる手助けができるようになったのです。

エンタープライズ領域でのDrupal8

15.Drupal8は自動テストのようなエンタープライズ向けの開発手法がとれるようになりましたか？

いくつかの改良によって、Drupal8はより効果的な継続的開発（CI)のプラットフォームなりました。コンフィグレーション・マネージメント・システムで設定はコードに書き出され、安全にサイト環境を移行し、挙動も予測できるようになりました。Drupal8のコードはよりオブジェクト指向的になったことで、コアのコードからテスト環境としてPHPUnitがサポートされました。コアのコードもすべてUnitテストが書かれています。DrupalのコマンドラインツールDrushもすでにDrupal8用にアップデートされ、カスタムコードの品質をテストするCoderモジュールから、機能をテストするPHPUnitまでほとんどの開発を自動化するために使われています。　自動テストもDrupal8で改良されました。コアはUnitテストと機能テストを実行するPHPUnitを取り入れています。これらを使うと前バージョンより素早いテストを行えます。PHPUnitはPHP開発者に広く使われているツールですので、テストを書いたり開発者を支援するツールを見つけたりしやすくなると期待されています。Drupal8ではSymfonyで人気のあるBehat テストフレームワークを利用して、ビヘイビア駆動開発（BDD)を行えます。

16.Drupal8は大きなサイト開発がやりやすくなりましたか？

Drupal8は大きなサイトを管理している組織にぴったりな選択肢となります。Drupalは最も自由度と拡張性が高いCMSです。そのため小さくシンプルなサイトだけでなく、大きくより複雑なサイトまでカバーできます。Drupal を採用することで、大きなサイトの開発コストやメンテナンスコストを軽減することができます。

17.Drupal8の設定管理は改善されましたか？

設定管理（コンフィグレーション・マネージメント）はDrupaのようなソフトウェア・アプリケーションをテストし、バージョン管理することを可能にします。Drupal7においては、コードで動作を定義するのではなく、実際の環境でもう一度手動で設定し直さなければならないことがありました。Drupal7でこれを実現するためにFeaturesモジュールのような拡張がありましたが、全体を統合する方法はなく、個々のモジュール毎にFeaturesからエクスポートしなければなりませんでした。加えて、Drupal7のVariableテーブルは設定と環境ごとのステータスが混ざり合っていたため、開発には時間がかかり、エラー発生にも繋がっていました。Drupal8のコンフィグレーション・マネージメントイニシアティブはモジュールの設定項目を定義する標準的な方法を開発しました。サイトビルダーはコンフィグレーションをファイルとしてエクスポートすることで、Webサイト全体をバージョン管理し、環境単位で変化させることが可能になります。これによってコンフィグレーションを監査、ロールバック、テストする対象にすることができます。

アーキテクチャ−の変化

18.Drupal 8での”headless Drupal”とは何ですか？

ヘッドレス(顔のない）・Drupal”または”デカップルド（分離された）・Drupal”という言葉はDrupalのバックエンドとテーマ部分を分離するシステム・アーキテクチャの試みを指して使われます。このようなアーキテクチャではDrupalはデータの入力と取得のためのコンテンツ管理システムとして使われ、エンドユーザーに表示されるページをレンダリングする機能は他のツールへ任されます。開発チームはリッチなインターネットアプリケーションやモバイルアプリ、スマートTVのようなデバイス向けのアプリ、時計、次のGoogle Glassなどを開発することができるようになります。これらのデバイスはそれぞれ特有の画面表示メカニズムを持っていますので、CMSから取得する純粋なデータだけを必要としています。Drupal8はHTMLだけでなく、その他の様々な形式、JSON、XMLなどを出力することができます。データを要求してくるデバイスやアプリによってデータ形式を変えて提供します。Drupal8をコンテンツ・マネジメント・システムとして採用することは未来へのよりよい投資と言えます。まず第一に、伝統的なブラウザーに向けてWebサイトを送信できますし、アプリや動的なインターネットアプリが同じDrupalバックエンドを使って構築できます。

19.Drupal8で他のシステムとの連携方法は変わりましたか？

Drupal8がPHPの標準的なライブラリーと親和性が高まるということは、特定用途に開発された外部の良いライブラリーを使いやすくなるということです。Drupalのエコシステム内で活動する開発者も連携の開発が容易になります。Druapl8はデータをRESTful API でエクスポートする機能を持っていますので、他のシステムとの連携が非常に簡単になります。加えて、Drupalに導入された新しいプラグインシステムはDrupalのエクステンション開発を容易にします（従来のモジュールとは別の仕組み）。このテクノロジーはDrupalのポジションを現存する最も拡張性と自由度の高いCMSフレームワークの地位に保ってくれるでしょう。

20. データベース・抽象化レイヤーに変化はありましたか？

Drupa7から引き続き、Drupalのエンティティモデルの標準化は進んでいます。Drupal8での開発は、データベースレベルではなく、エンティティレベルになります。これによってDrupal8はMySQLのような一般的なリレーショナル・データベース以外のさまざまなデータベーステクノロジーを利用することができます。例えば、MongoDBのようなNoSQLソリューションをDrupal8サイトのデータベースストレージとして使うことができます。Drupal8のデータベースAPIはほとんどDrupal7と同じですが、開発者はコアAPIの開発でない限り直接データベースコールをすべきではありません。

21.Drupal8ではSymfonyが重要な使われ方をしていると聞きましたが、どのような実装になっていますか？

前のバージョンまではDrupalはすべてのコードがコミュニティのメンバーによって開発されていました。Drupal8ではSymfonyのような外部プロジェクトを受け入れ、また他のプロジェクトで使ってもらえるようなライブラリーを作ろうとしています。「車輪の再開発」をせずDrupal8は問題解決のために大きなコミュニティで開発されたコンポーネントを利用します。これはDrupalがさまざまなプロジェクトで使われているより安定したコードベースを利用できるメリットがあります。その逆にSymfonyのようなプロジェクトはより多くのユーザーがコードを使うことでその過程でさらに強靭なものになるメリットを享受できます。Symfonyに慣れていてDrupalには不慣れな開発者もDrupal開発をすることができるようになります。開発チームが才能ある開発者の集団に開かれることを意味します。SymfonyはPSR-4(名前空間クラス)のような業界標準やベストプラクティスを使って書かれてあり、それらはDrupal8にも引き継がれています。

パフォーマンス・セキュリティ

22.Drupal 8ではパフォーマンスが向上しましたか？

Drupal8のキャッシュシステムは全面的に書き換えられました。Drupal7では少しの変更のために全体のキャッシュを再構築する必要がありました。通常のキャッシュはDrupal7と同じようにページ単位で行われます。ページの全体がキャッシュされ、再生成されます。ログインユーザーには基本的にはキャッシュは適用されずページ全体がリクエストの都度生成されます。Drupal8ではキャッシュはさらに複雑になり、細かく制御されるようになります。例えば、新しいキャッシュタグシステムはページの部分単位をキャッシュすることでログインユーザーはページの大部分をキャッシュから受け取り、ユーザー特有の情報を別に受け取ることが可能になります。またキャッシュタグを使うことにより、開発者は特定のキャッシュクリアシナリオを定義することができます。例えば、「User 300のアカウントデータキャッシュをクリアし、その他のユーザーはそのままにする」などが出来るようになります。加えて、ほとんどのDrupal8キャッシュシステムは拡張性があり、どのレベルからでも外部のキャッシュツールを使うことができます。大規模で複雑なサイトには、より適正なツール群をパフォーマンス改善に使うことができます。Drupal8ではページ生成の一連の動作の再検討がなされましたので、ページ生成はより効率的になっています。「速い設定がデフォルト」の原則がDrupal8では採用されて、開発者は何も考えずにパフォーマンスの向上を享受できます。

23. Drupal8での高可用性（High Availability)は改善されましたか？

Drupalは長い間、高可用性環境で使われてきており問題点も共有されています。Drupal8はこの点はDrupal7と同じです。Drupal8でキャッシュレイヤーが改善されたことでより複雑な構成が可能になります。

24.Drupal8のセキュリティに対する考え方に変化はありますか？

Twigテンプレートシステムを使うことはPHPコードをテンプレートに書かなくなったという点で大きな変化になります。テーマレイヤーはこれまで脆弱性の原因となることがよくありましたが、Twigはセキュアな画面表示レイヤーを実現するためのフル機能を持っています。サイトビルダーがWYSIWYGエディターを利用するために設定するテキストフィルターもまた脆弱性を多く生み出してきました。WYSIWYGエディターはコンテンツマネージメントシステムには必須の機能ですが、これまでDrupalコアではサポートしていませんでした。このインストールと設定は複雑でサイトビルダーに大きな負担となっていました。Drupal8ではCKEditorが標準でインストールされ殆どのケースでセキュアに使えるように注意深く予め設定されています。これまではPHPモジュールを使ってサイトビルダーがPHPコードをブラウザから書き込むことができましたが、コアから削除されました。PHPをブラウザから書くことは推奨されない作法でしたし、設定がしっかりなされていないサイトに悪意あるユーザーが高い権限を持った場合PHPコードをサーバーで実行できる問題がありました。URLから送られるすべての変数は新しいルーティングシステムで適切に扱われます。おかしなデータ、意図しないデータは標準でフィルターされます。Drupal7のコアAPIで提供されていたCSRF(クロス・サイト・リクエスト・フォージェリ)対策も引き続き有効です。Drupalセキュリティチームと呼ばれるボランティアで組織されたチームがDrupalコアのセキュリティ問題やセキュリティ勧告を管理しています。Drupal8では多くの外部コードを利用しますので、外部ライブラリに対するセキュリティ勧告は非常に重要になります。外部ライブラリを使うモジュールは依存性があるライブラリのセキュリティに問題が会った時にhook_requirementsイベントを使ってアラートを出すことができます。外部で書かれたコードもDruapl8のコードベースの一部になっています。それらの外部コードでセキュリティ問題が発覚した場合、セキュリティチームは外部の開発者と一緒に問題を解決しセキュリティ勧告を双方のコードベースでリリースします。Drupal8は自動アップデート機能をすぐに使えるような形では提供しません。しかし、Drushコマンドやバージョン管理システム、自動テストツールなどのCIプロセス（継続的開発）を利用することで自動アップデートが可能になります。