In Symfony 3.3, we're introducing a lot of changes and simplifications to prepare us for the fascinating Symfony 4.0 release that will take place on November 2017.
Some of those changes are technically minor but will have a profound effect in
your applications. In Symfony applications, the well-known getRootDir()
method of the Kernel class and its counterpart kernel.root_dir parameter
are misleading.
They return the path where the application kernel (usually AppKernel.php) is
stored. In Symfony 2 and 3 this is usually the app/ directory, so it's common
to use expressions like %kernel.root_dir%/../var/ or %kernel.root_dir%/../web/.
In Symfony 4, the kernel class has been moved to the src/ directory, so the
previous expressions won't break.
However, given that most of the times getRootDir() is used to get the
project root directory, in Symfony 3.3 we've decided to add a new method to the
Kernel class called getProjectDir() which will give you exactly that.
This new method finds the project root directory by looking for the first
directory that contains a composer.json file starting from the directory
where the kernel is stored and going up until composer.json is found.
In practice, this means that your application can simplify most or all the
expressions that use %kernel.root_dir%. For example:
use %kernel.project_dir%/web/ instead of %kernel.root_dir%/../web/.
Second
%is missing in the examplesThis is absolutely awesome!
@Marius fixed! Thanks.
Small changes, however, with very good impacts!
So true. Most of the time a create a parameter in my projects with the name "project_dir" myself.
Looks like those days are almost over. :) Cannot wait for 3.3. I personally think this version has a few of the best features ever.
As a Symfony newcomer this was one of the things I found confusing. Definitely a great addition ;)
@Javier What is on production where maybe no composer.json are exist because this file are excluded from deployment?
Why would you not use composer for production deployment ?
@Tommy if we look at the code here: https://github.com/symfony/symfony/pull/22315/files, if there's no composer.json I think it goes up and up until the root directory of the computer.
Maybe you can try it in some of your project to verify this and open an issue if there's a bug. We have time to fix it until the end of May, when Symfony 3.3 is released.
If you are not deploying the composer.json file, override the getProjectDir() method in your Kernel.
It's unusually to see static methods in Symfony and it's little bit confusing :|
It's not a static method: https://github.com/symfony/http-kernel/blob/master/Kernel.php#L317
@Oleksandr it's not static. We use the notation "ClassName::methodName" for any method, static or not. We even use that notation in the profiler and the debug toolbar.
@James We use composer on a CI server but transfer only the relevant files to production. And there can the composer.json file are excluded.
@Javier Thanks for the answer. I will try.
@fabien Good point.
I don't think it's wise rely on a component that is not part of symfony framework itself, i suspect it's slower than a "%kernel.root_dir%/../web/" (compiled the difference will be near zero, of course), and i guess that more people than you think exclude composer.json in deploy phase. But -hey- your framework, your rules. It's the first feature that i don't agree at 100% :-)
I may be stupid or too attached to th ZF way to do things, but ZF just uses a chdir(dirname(__DIR)) in public/index.php, which makes the default path from the project root. Using this and some other DIR related paths, I never encountered any problem. Wondering what use cases may not be covered with this solution...
Hey @Matteo Contri I am full of your opinion. I just stumbled upon deploying process.
Cool!