bin /、src /、var /ディレクトリは一度にSymfony 3に登場しましたが、これは私の意見では非常に便利で理解しやすいと思います。 私たちは皆、そのようなディレクトリを操作することに慣れています。 同様に、Symfony 4は同じ方向に移動し、更新されたアプリケーションディレクトリ構造を提供します。
テスト/テスト用
すべてのテストは、tests /ディレクトリに直接配置されます。 以前は、tests /ディレクトリには、テストが配置されたアプリケーションのバンドル名を持つディレクトリが常にありました。 Symfony 4では、アプリケーションはどのバンドルにもコードを実装しません（または必要ありません）。 これにより、起動用に独自のテスト名前空間を定義できます。
{ "autoload": { "psr-4": { "App\\": "src/" } }, "autoload-dev": { "psr-4": { "App\\Tests\\": "tests/" } } }
テンプレート/テンプレート用
Twigテンプレートエンジンをインストールすると、すべてのテンプレートが配置されるアプリケーションのルートにテンプレート/ディレクトリが作成されるようになりました。 以前はパブリックファイル（css、jsなど）とテンプレートの両方が含まれていたResourcesディレクトリに不快感が生じていたため、このアイデアがとても気に入っています。 ディレクトリがtpl /と呼ばれる可能性がありますが、これはまだ完全にはわかっていません。 一般に、src /ディレクトリからテンプレートを移動すると、アプリケーションがより構造化されます。 現在、src /にはコードのみが含まれています。 以前はapp /フォルダーにあったカーネルクラスも、それが属するsrc /に移動します。
config /構成用
config /ディレクトリは、既存のapp / configを置き換えます。 parameters.ymlファイルで以前に定義された環境パラメーターは、オペレーティングシステムの環境変数を使用して設定されるようになりました。 デフォルトでは、config /ディレクトリに空のcontainer.yamlファイルがあります（yamlはタイプミスではありません。Symfony4では、YAML形式の構成ファイルにymlの代わりにyaml拡張子が付きます）。 routing.yamlファイルもあります。 これらのファイルでは、独自の設定のみを定義します。 Composerを使用してインストールされたコンポーネントは、設定を環境ごとに個別のファイルに保存します。
前と同様に、構成は3つの形式（YAML、XML、PHP）で指定できます。 設定ファイルに加えて、bundles.phpがconfig /ディレクトリに表示されます。これは、システムでアクティブなバンドルの配列で表されます。
//bundles.php <?php return [ 'Symfony\Bundle\FrameworkBundle\FrameworkBundle' => ['all' => true], 'Symfony\Bundle\TwigBundle\TwigBundle' => ['all' => true], ];
Composerを使用してシステムにバンドルをインストールまたは削除すると、Synfony Flexプラグインによってこのファイルへの変更が自動的に行われます。
var / cache / cache only
小さな変更がvar /ディレクトリに影響しました。 これでvar / cache /に「永遠の」キャッシュのみが格納されます（コンテナーと翻訳のコンパイル、または教義のキャッシュなど）。 したがって、var / cache /内のすべてのファイルには、独自のウォームアップクラスが必要です。 一時ファイルはなく、プロジェクトの展開後に変更されないキャッシュのみ。 これにより、var / cache /ディレクトリが読み取り専用になります。 このアプローチを使用すると、読み取り専用ファイルシステムを使用できます（たとえば、HerokuまたはSensioCloudプラットフォームの場合）。
web / publicに名前が変更されました/
public /ディレクトリの内容も変更されました。 config.php、.htaccess、favicon.ico、apple-touch-icon.png、robots.txtファイルを削除しました。 すべてのプロジェクトがこれらのファイルを必要とするわけではありません。 これらのファイルのテンプレートが必要な場合、Symfony 4はオプションでそれらを取得する機会を提供します。
フロントコントローラーも変更されました。 これで、通常のapp.phpとapp_dev.phpの代わりに、すべての環境に1つのindex.phpファイルが作成されます。
if (!getenv('APP_ENV')) { (new Dotenv())->load(__DIR__.'/../.env'); } if (getenv('APP_DEBUG')) { if (isset($_SERVER['HTTP_CLIENT_IP']) || isset($_SERVER['HTTP_X_FORWARDED_FOR']) || !(in_array(@$_SERVER['REMOTE_ADDR'], ['127.0.0.1', '::1']) || PHP_SAPI === 'cli-server') ) { header('HTTP/1.0 403 Forbidden'); exit('You are not allowed to access this file.'); } Debug::enable(); } // Request::setTrustedProxies(['0.0.0.0/0'], Request::HEADER_FORWARDED); $kernel = new Kernel(getenv('APP_ENV'), getenv('APP_DEBUG')); $request = Request::createFromGlobals(); $response = $kernel->handle($request); $response->send(); $kernel->terminate($request, $response);
環境変数を構成に使用します
特定のプラットフォームおよび環境に固有の設定は、以前に設定ファイルapp / config / parameters.ymlに保存することが決定されていました。 このようなパラメーターは、環境変数を使用して設定する必要があります。 これはparameters.ymlを使用するよりもいくつかの利点があります。 たとえば、キャッシュをクリアすることなく、これらのパラメーターを動的に変更できます。 環境変数は、いくつかのアプリケーションとプログラミング言語で一緒に使用できます。 最後に、サードパーティのアプリケーションを使用してこれらの設定を管理できます。
戦闘サーバーでは、このアプローチは非常に魅力的に見えます。 しかし、アプリケーション開発時には、環境変数を使用することは非常に不便です。 Symfony 3.3には、問題を解決するために設計されたDotenvコンポーネントがすでに付属しています。 アプリケーションのルートには、環境変数を定義できる.envファイルがあります。 Dotenvコンポーネントを使用すると、.envファイルと実際の環境変数の使用を「切り替える」ことができます。
メイクファイルはどうですか？
多くのプロジェクトでは、PHPで記述されたスクリプトの使用が完全に推奨されないシナリオがあります（たとえば、Webサーバーの再起動や、次の展開後のphp-fpm構成の再読み込みなど）。
これらの目的のために、Makefileを使用することをお勧めします。 makeユーティリティは誰でも使い慣れています。 Composerでスクリプトを実行する（composer.jsonで記述した場合）よりも、その使用の方が優れています。 makeユーティリティもシステム上で中央で実行され、PHPから独立しています。 実世界の例を見てみましょう; Symfonyには、キャッシュをクリアしてウォームアップするためのコンソールコマンドがあります。 同じプロセスで2つのコマンドを使用しても、PHPがクラスを変更した場合、クラスをリロードできないため、正常に機能しません。 この問題は、このMakefileを使用して簡単に解決できます。
cache-clear: @test -f bin/console && bin/console cache:clear --no-warmup || rm -rf var/cache/* .PHONY: cache-clear cache-warmup: cache-clear @test -f bin/console && bin/console cache:warmup || echo "cannot warmup the cache (needs symfony/console)" .PHONY: cache-warmup
これは、Symfony 4アプリケーションの標準ビルドで取得するファイルです。
Windowsマシンでのインストールのテストで小さな問題が発生しました。 makeユーティリティがnixシステムの標準である場合、Windowsでは少しタンバリンをノックする必要があります。 問題は、Windowsのmake実装を見つけることではありませんが、スクリプトにはテストへの呼び出し、rmコマンドなどが含まれています。 この問題の議論はここにあった 。
私自身、この問題を解決する2つの方法を特定しました。
1. GitBashをターミナルとして使用します。 Gitを使用する場合、WindowsシステムにGitBashが存在する可能性が高いです。
2.今日、デフォルトのCygwinターミナルを使用するようにお気に入りのPhpStorm IDEを構成しました。 そして、GitBashを使用するよりもこのソリューションが好きでした。
今のところすべてです。 Symfony Flexプラグインを使用してアプリケーションを構築するための第一印象と手順に関する資料の先。