FFCMS 3.0.0リリース-新しい再設計されたシステム

今日はhabrahabrの住人、今日はffcmsの新しいリリース-3.0.0についてお話しし 、以前のリリース-2.0.4からシステムに加えられた基本的な変更を簡単に強調したいと思います。



システムは無料配布モデルとオープンソースコード（MIT）を保持していましたが、ソースコードはMVCアーキテクチャとPSR-0スタートアップ用に完全に書き直されました。 多くの「バイク」がシステムから削除され、symfony http財団、laravel eloquentなど多くの人気のあるコンポーネントがその場所を占めました。

リサイクルシステムアーキテクチャ

システムの2番目のバージョンについて議論する多くのhabrahabrユーザーは、現在の傾向を考慮してシステムを大幅に再設計することを推奨しました：依存関係とコンポーザーのバージョンマネージャーを追加し、確立されたMVCアーキテクチャを導入し、コードを単一のPSR-1 / 2スタイルにします。 2番目のバージョンのコードは実際にはかなり低品質であり、それについて脚を破ることができました（ あるいはその両方 ）。 また、2番目のバージョンの拡張機能の開発モデルは非常に混乱し、冗長であり、カーネルAPI構文とともに、一部のユーザーに苦痛を与えたことにも留意されました。



単に最新のツールとアプリケーション開発の原則を実装する必要がありましたが、既存のコードを書き換えることはほとんど不可能でした。したがって、システムアーキテクチャをゼロから再設計することにしました。



システムは、基本構造、カーネル、コンソールといういくつかの機能部分に分割されました。 パーツごとにリポジトリが作成され、コンポーザーが構成され、プロジェクトがpackagistで公開されました。 すべてのパーツは、ベースコンポーネントのcomposer.jsonの依存関係を使用してリンクされます。

自転車の放棄

過去数年間のアプリケーション開発で、symfony、laravel、yii、codeigniterなどの一般的なフレームワークのほとんどに出会いました。 奇妙なことに 、私がCMSに独立して実装しようとした「相互作用のアイデア」のほとんどは、すでに人気のあるフレームワークに既に実装されています-それらは途方もなく複雑で、どこかシンプルすぎて十分に機能していません。 私はそれらの多くが好きで、ffcmsでそれらを実装して、今日までそれらを使用しています。



そのため、「自転車」の次の部分は、定評のある人気のあるコンポーネントに置き換えられました。

• ネットワーキング：symfony http Foundation
• データベースの操作（DBマネージャー）：laravel eloquent
• HTMLコードセキュリティ：HTMLピューリファイヤー
• コンソールの操作：symfonyコンソール
• キャッシュコア：PHP高速キャッシュ
• デバッグ：debugBar
• メールの操作（メーラー）：swiftmailer
• oAuth 2.0認証：hybridauth

使用されるコンポーネントの一部については、「子孫」が記述され、システムのニーズに合わせてコンポーネントの機能を拡張または簡素化しました。 これらのコンポーネントを使用することで、システムの基本的なコアを簡素化し、他の開発者のしきい値を下げることができました。

パフォーマンスと互換性

しかし、php-5.2サポートを導入し、polyfillを使用する必要がありますか？ いや、いや、もう一度。 現在、PHP 7.1と非推奨の5.5への移行により、古いバージョンのPHPをサポートする意味はまったくありません。 もちろん、ポリフィルを使用する誘惑は素晴らしいですが、すでに困難なシステムを複雑にしないために、それを拒否することもできます。



FFCMS 3は、バージョン5.5以降のnginxバンドル-php-fpm、apache2-phpまたはその他のバンドル（uriの書き換えルールが書き換えられている場合）で動作するphpインタープリターで動作します。



システムのパフォーマンスはそれほど低下しませんでしたが、リソースの消費量は2番目のバージョンよりも多少大きくなりました（驚くことではありません） が、それでもbitrixレベルに達することはできませんでした 。 ページのロードはまだ<0.1秒、メモリ消費は<7mbです（opcacheなしのphp 5.6の場合）。 最新のパフォーマンステストは、virtualboxの下のテストコンテナとともにgoogle.docsで見つけることができます。

テンプレート化（ または裸のphp？ ）

この紛争では、戦闘機は多くの剣を破壊しましたが、この問題に関するコンセンサスはありません。 多くの人は、PHP構文自体でテンプレートを作成するのに十分であると考えています。 システムの2番目のバージョンでは、twigが使用されましたが、ビューでhtmlコードを生成するための古典的なphp構文に制限することにしました。





UIのすべては同じままです。jqueryとbootstrapは実績のある束です。

DB、クエリ、およびActiveRecord

PHP内のデータベースとやり取りするには、さまざまな方法があります。 誰かが裸のPDOで、誰かがDoctrineとQueryBuildersで動作します。 FFCMSはlaravel eloquentライブラリを使用します。これにより、クエリビルダーツールとActiveRecordsアプローチを使用してデータベースと対話できます。



ActiveRecordはデータベースを操作するのに非常に便利で、クエリの構文を大幅に簡素化および削減します。 もちろん、これは本格的なDoctrine ORMではありませんが、CMSの目的には十分です。

移行

移行とそれらのさらなる「展開」がなければどこにもありません。 いいえ、もちろんmysqldump / pg_dumpを使用している人もいますが、この道をたどりません。 ffcms 3には、移行の標準実装があります-up（）、seed（）、down（）の3つのメソッドを持つクラス、移行を作成、適用、ロールバックする機能。 標準の移行は/ Private / Migrationsに保存されますが、MigrationsManagerを使用して任意のディレクトリからの移行を実装できます。

デバッグ

迅速なデバッグと要求のプロファイリングの利便性のために、fpdebugbar機能がffcmsに組み込まれています。 このメカニズムにより、xdebug / zenddebugに接続する可能性や時間がないときに迅速にデバッグできます。 デバッガはパネルのように見え、管理パネルの設定に含めることができます。

テスト中

手動の製品正常性テストは、現代の開発の傾向ではありません。 システムコードとUIの自動テストを目的として、自動テストシステムが導入されました。これは、標準的なユニットテストとインターフェイスの受け入れテストを組み合わせたcodeceptionです。



クロムまたは別のブラウザーのドライバーでセレンを実行した後、codecept runコマンドを使用して、ルートからテストを実行できます。 レイヤーのテスト環境設定（/tests/acceptance.suite.yml）を編集することも必要です。 テストを構成するために、使用説明書が記載された小さなドキュメントがあります （ドキュメントは元々「すべての目」を対象としていませんでした、すみません）。

拡張機能

PSR-0スタートアップが利用可能になったため、拡張システムが改訂されました。 現在、すべての拡張機能は、アプリケーションとウィジェット、最初の2つのタイプに分かれています。コントローラーに応じて特定のルートURIを占有し、アクションの助けを借りて特定のリクエストを処理します。 2つ目は、ウィジェットクラスに直接アクセスすることにより、任意の場所で表現を表示することを目的としています。



さらに、「実装」のセット全体を1つのパッケージにラップし、gitおよびcomposerを使用して、autoload標準に従って、自給自足の実装として配布できます。 顕著な例は、 フォーラムまたはデモパッケージの 実装です 。



さて、私の話は十分に引きずり出されましたが、おそらくすべてを1つの記事に収めることは不可能です。 私はあなたの質問に答えて、あなたの願いに耳を傾けます。



→公式ウェブサイト： ffcms.org （ミラー： ffcms.ru ）

→githubでのプロジェクト： phpffcms

→管理者および開発者のドキュメント： doc.ffcms.ru （開発中）。