5.7以前からの開発者のためのガイド

concrete5のバージョン7では、たくさんの変更があります。このページは、以前のconcrete5の経験のある開発者に向けて書かれています。CMSにおけるインタラクションのひとつひとつが、モダンPHPで採用された原則とベストプラクティスにしたがって改善され、書き直されています。このテクニカル面での刷新は、将来におけるconcrete5の改善と成長をもたらしてくれるでしょう。しかし、以前の古い方法とは大きな変更があるのも事実です。このページでは、concrete5のバージョン7がバージョン6と大きく異なる点について解説していきます。

アプリケーションディレクトリ

バージョン6以前では、concrete5のオーバーライドディレクトリは、ウェブのルートディレクトリで、コアディレクトリは concrete/ でした。バージョン7では、concrete/ ディレクトリはコアソースを格納するディレクトリのままですが、ルートディレクトリの内容はぐっと少なくなりました。オーバーライドディレクトリはどこへ行ったのでしょうか？

それは、application/ ディレクトリに移動しました。このディレクトリを開いてみると、コアのアイテムをオーバーライドするための空のディレクトリ群を確認することができるでしょう。

コアディレクトリの再編成

ぱっと見では5.7の concrete/ ディレクトリは以前と同じように見えるかもしれませんが、詳しく見るといくつかの変更点があります。

新しいトップレベルディレクトリ

5.7ではいくつかのトップレベルディレクトリが追加されました。例えば、属性タイプ（以前は concrete/models/attribute/types にありました）や、認証タイプなどです。これらのディレクトリのすべてのリストは、ディレクトリ構造のドキュメントを参照してください。

models/ helpers/ libraries/ ディレクトリは無くなりました

ブロックタイプや属性タイプ、認証タイプ、メニューアイテム、コントローラー以外のconcrete5のクラスは、concrete/src/ ディレクトリにまとめられました。このディレクトリ内はPSR-4の命名規則に従います。これらのコードはすべて名前空間に対応しています。これは5.7で新しくなった点のひとつです。

多くの既存のAPIメソッドはそのまま動きます。Loaderのようなレガシークラスも動作しますが、非推奨であり、クラスを読み込むための新しい方法が用意されています。

サードパーティライブラリーはComposerによって提供されます

concrete5が依存するすべてのサードパーティのライブラリは、Composerの依存関係マネージャによって提供されるようになりました。このことはアプリケーションのビルド時点における変更になりますので、concrete5のリリースパッケージを使用する際は、特に変化はありません。これらのライブラリは concrete/vendor ディレクトリに格納されます。

PHP名前空間

concrete5のすべてのクラスは名前空間に対応しました。src/ ディレクトリ内のクラスはPSR-4標準規約に従って名前空間が付けられています。このディレクトリ外では、PSR-4をconcrete5用にカスタマイズしたルールに従っています。コーディングスタイルガイドラインのドキュメント（未翻訳）で詳細を解説しています。

テーマ、ページタイプ、ページテンプレートの変更

一見、concrete5.7のテーマも5.6以前と変わらないように見えますが、多くの新機能が実装されました。たとえば、新しいメソッドがテーマのページテンプレートのコンテナDIVで使われるようになりました。

<div class="<?=$c->getContainerClass()?>">

変更点はこれだけではありません。ページタイプは以前と異なり、ページテンプレート（テーマディレクトリ内のテンプレートファイル）と分離され、複数のページテンプレートを使用できるページタイプを作成できるようになりました。テーマはグリッドフレームワークのサポートなどのオプションを定義するためのclassを持つようになりました。

テーマに関する詳細は、デザインカスタマイズのセクションをご覧ください。

設定の変更

concrete5は設定オプションに定数を使用しなくなりました。その代わり、有名なオープンソースフレームワークの Laravel の設定ライブラリーを採用し、設定の記法に連想配列を採用しました。この新しい設定方法には、多くのメリットがあります。

  1. 設定値はシンプルにPHPの配列で保存することができます。
  2. データベースに保存される設定値が少なくなります。
  3. コアのデフォルト設定値はすべて特定のキーをオーバーライドすることで変更できるようになりました。もう定数が設定済みかどうかをチェックする必要はありません。
  4. 設定値は名前空間的に入れ子構造で表すことができます。
  5. 環境によって異なる設定ファイルを読み込ませることができるようになります。

このアプローチにはたくさんのメリットがありますが、これまでのconcrete5の開発者にとっては完全に新しいものです。もし config/site.php をお探しでしたら—そのファイルは無くなりました！代わりに、データベース設定は application/config/database.php に移りました。

完全に新しいアプリケーション・フロー

concrete5のディスパッチャとアプリケーション・フローはスリム化され書き直されました。コメントが追記され、以前より一目で理解しやすくなりました。

完全なルーティングコンポーネントがサポートされ、toolsは非推奨になりました

レガシーなconcrete5では、テーマのオーバーヘッドを回避し、インターフェースと分離されたシンプルなスクリプトを使用するために、toolsが使われていました。toolsは、Ajaxのリクエストや、外部APIの作成、その他にも多くのコアアプリケーションで使用されていました。

5.7では、toolsは後方互換性のために存在していますが、非推奨になりました。その代わりに、Symfony2ベースのルーティングライブラリが使用できます。コアのルーティングは concrete/config/app.php で指定されています（"routes" キーを参照）。これらはコントローラーにマッピングされていて、ビューを返します。これらのビューは concrete/views ディレクトリに格納されています。このことは、ビューからコントローラーにデータの送信が可能と言うことです。このことは、concrete5のコードベースをクリーンに保ち、開発者をよく助けてくれます。

シングルページとそのコントローラー

シングルページとそのコントローラーは、5.7では大きな変更はありません。シングルページは以前と同様に concrete/single_pages ディレクトリに格納されています。コントローラーは concrete/controllers/single_page ディレクトリに格納されています。

クラスの拡張方法の変更

クラスの拡張方法は5.7で大きく変わりました。ブロックタイプや属性タイプ、その他の src/ ディレクトリ外のファイルは application/ ディレクトリからオーバーライドして拡張できますが、concrete/src ディレクトリ内のファイルは同じ方法では拡張できません。

注意：我々は、よく使うクラスに関しては、開発者から拡張可能にしようと考えています。この件に関するフィードバックを歓迎します。

このことのメリットとして、concrete5のコアコードベースは理解しやすくなり、APIドキュメントもクリーンになりました。

エイリアスクラス

concrete5のコードが名前空間に対応しましたが、クラス呼び出しのたびに、長い名前空間を記述しなければならない、と言うことはありません。よく使われるクラス群に関しては、グローバルスコープでエイリアスを定義しています。そのため、"Page::getByID()" というコードは5.7でも動きます。それは、Page というクラス名が \Concrete\Core\Page\Page のエイリアスとして登録されているからです。これらのエイリアスの一覧は config/config/app.php から確認できます。

ヘルパーが非推奨になり、サービスプロバイダーに変わりました

レガシーなconcrete5では、ヘルパーはファイルパスに従って読み込まれていました。5.7からはより柔軟な方法が採用されました。サービスクラスはサービスプロバイダーによって自動的に登録され、それらのサービスクラスは Core::make() によって返されます。

レガシーな Loacer::helper() メソッドは存在していますが、非推奨です。例えば、このようなコードです。

$mh = Loader::helper('mail');

このコードは、5.7では下記のように代替できます。

$mh = Core::make('helper/mail');

Loader::helper($class) は5.7では単に Core::make("helper/$class") を呼び出しています。5.7では、concrete5はどのように "helper/mail" がどのクラスを差しているのかを知ることができるのでしょうか？それは、\Concrete\Core\Mail\MailServiceProvider によって登録されているからです。具体的には、このファイルの中の次の行で登録が行なわれています。

$this->app->bind('helper/mail', 'Concrete\Core\Mail\Service');

それでは、concrete5はどのようにこのクラスの register() メソッドによってクラスのバインディングが行なわれていることを知るのでしょうか？それは、concrete/config/app.php ファイルの中でサービスプロバイダーが登録されているからです。

'providers'           => array(
    ...
    'core_mail'         => '\Concrete\Core\Mail\MailServiceProvider',
    ...
);

'providers' キーの中で指定されているクラスの register() メソッドが実行されます。

なぜこのような方法が取られているのでしょうか？それは、サービスの再束縛が可能になるからです。この方法は、以前のconcrete5で採用されていたファイルシステム上の位置によるクラスのオーバーライドよりも柔軟性があります。例えば、パッケージの on_start() メソッドで 'helper/mail' を別のクラスに再束縛することができます。このことにより \Concrete\Core\Mail\Service を置き換えることができます。

これらは本当にヘルパーなのでしょうか？

名前が気になる方への補足ですが、「ヘルパー」という名前は Loader::helper() との後方互換性のために残されたものです。将来的には、helper/ という接頭辞は削除されるかもしれません。

データベース接続

5.7ではデータベースへの接続方法も変わりましたが、後方互換性のために、5.6までのAPIもほぼ100%動作するように残されています。concrete5はADODBの使用を廃止し、代わりにDoctrine DBALをデータベース接続に採用しました。しかし、カスタマイズされたラッパークラスによって、旧ADODBスタイルのクエリ呼び出しも引き続き動作します。

新しいコンポーネントの恩恵

新しいAPIドキュメントを参照してください。以下の新しいコンポーネントは、開発者にconcrete5での開発に大きな力を与えてくれるでしょう。

  • Session
  • Router
  • Events (Symfony2 の EventDispatcher)
  • Cookie
  • URL

変化

これらの変更は、長くconcrete5を使ってきた開発者にとってはショックかもしれませんが、同時にチャンスでもあります。2008年に我々が最初にconcrete5をリリースした時よりもさらに、人気のPHPフレームワークで採用されている一般的な開発モデルを採用しました。このドキュメントで説明されている内容についての詳細など、ぜひご意見をお寄せください。

Happy Developing! –Andrew.

原文：A Guide to 5.7 for Existing Concrete5 Developers