Symfony 4: application structure

This post is based on the publication of Fabien Potencier.



At one time, the bin /, src /, var / directories appeared in Symfony 3, which in my opinion is very convenient and understandable. We are all used to working with such directories. In turn, Symfony 4 is moving in the same direction and offering an updated directory structure for the application.

tests / for tests

All tests will now be located directly in the tests / directory. Earlier in the tests / directory there were always directories with the names of the bundles of your application in which there were tests. In symfony 4, applications will not (or need not) implement the code in any bundle. This will allow you to define your own test namespace for autoloading:

{ "autoload": { "psr-4": { "App\\": "src/" } }, "autoload-dev": { "psr-4": { "App\\Tests\\": "tests/" } } } 

')

templates / for templates

When installing the Twig template engine, the templates / directory will now be created in the application root, where all templates will be placed. I really like this idea, because the Resources directory, which previously contained both public files (css, js, etc.) and templates, made some discomfort. It is possible that the directory will be called tpl /, this is still not completely known yet. In general, moving templates from the src / directory makes the application more structured. Now only the code is in src /. The Kernel class, which was previously located in the app / folder, is also moved to src / where it belongs.

config / for configurations

The config / directory replaces the previously existing app / config. Environment parameters that were previously defined in the parameters.yml file are now configured using the operating system environment variables. By default, in the config / directory you will find an empty file container.yaml (yaml is not a typo, in Symfony 4 configuration files in YAML format, now have the extension yaml, instead of yml) in which you can define the container configuration as before. There will also be a routing.yaml file. In these files, you will only define your own settings. Components installed using Composer will store their settings in separate files for each environment.



The configuration, as before, can be set in three formats: YAML, XML, PHP. In addition to the configuration files, bundles.php will appear in the config / directory, which will be represented by an array of bundles active on your system.

 //bundles.php <?php return [ 'Symfony\Bundle\FrameworkBundle\FrameworkBundle' => ['all' => true], 'Symfony\Bundle\TwigBundle\TwigBundle' => ['all' => true], ]; 

Changes to this file will be made automatically by Synfony Flex plug-in, when installing or removing any bundle in the system using Composer.

var / cache / cache only

Minor changes were made to the var / directory. Now only the “eternal” cache will be stored in var / cache / (compiled container and translations, or doctrine cache for example). Thus, all files in var / cache / should have their warmup class. No temporary files, only cache, which does not change after the project deployment. This will make the var / cache / directory read-only. With this approach, you can work with read-only file systems (for example, on the Heroku or SensioCloud platforms).

web / renamed to public /

The content of the public / directory has also changed. Removed files config.php, .htaccess, favicon.ico, apple-touch-icon.png, robots.txt. Not every project needs these files. If you need templates for these files, then Symfony 4 will give you the option to get them optionally.



Changed and the front controller. Now, instead of the usual app.php and app_dev.php, there will be one index.php file for all environments:

 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); 

We use environment variables for configuration

Settings that are specific to a specific platform and environment have previously been stored in the configuration file app / config / parameters.yml. Now such parameters should be set using environment variables. This has some advantages over using parameters.yml. For example, you can dynamically change these parameters without having to clear the cache. Environment variables can be used together in several applications and programming languages. Finally, you can administer these settings using third-party applications.



On the battle server, this approach looks very attractive. But at the time of application development, using environment variables can cause a lot of inconvenience. Symfony 3.3 is already shipped with the Dotenv component, which is meant to solve the problem. At the root of your application, there will be an .env file in which you can define environment variables. The Dotenv component allows you to "switch" between using the .env file and real environment variables.

How about a makefile?

In many projects, there are scenarios for which the use of scripts written in PHP is not entirely advisable (for example, such things as restarting the web server or reloading the php-fpm configuration after the next deployment).



For these purposes it is proposed to use a Makefile. The make utility is familiar to everyone. Its use is better than running scripts using Composer (if you have registered them in composer.json). Also, the make utility runs centrally on your system and is independent of PHP. Let's look at a real-world example, symfony has console commands for cleaning and warming up the cache. Using two commands in one process does not work as it should, because PHP cannot reload classes if they have changed. This problem can be easily solved using the following 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 

This is exactly the file you get in the standard Symfony 4 application build.



I ran into a small problem testing the installation on a Windows machine. If for nix systems the make utility is standard, then on Windows you need to knock a little tambourine. The problem is not to find the make implementation for Windows, but that the scripts contain calls for such commands as test, rm, etc. Discussion of this issue was here .



For myself, I identified two ways to solve this problem:



1. Use GitBash as a terminal. If you are using Git, then most likely GitBash is present on your Windows system.

2. Today I set up my favorite IDE PhpStorm to use Cygwin's default terminal. And I liked this solution more than using GitBash.



That's all for now. Ahead is a story about first impressions and instructions for building an application using the symfony Flex plugin.