Description
| Q | A |
|---|---|
| Bug report? | yes |
| Feature request? | no |
| BC Break report? | no |
| RFC? | no |
| Symfony version | >=3.2 |
In Symfony\Bundle\TwigBundle\DependencyInjection\Compiler\ExtensionPass, you may see the following method:
private function getComposerRootDir($rootDir)
{
$dir = $rootDir;
while (!file_exists($dir.'/composer.json')) {
if ($dir === dirname($dir)) {
return $rootDir;
}
$dir = dirname($dir);
}
return $dir;
}Which looks up for the composer.json, but in our environments, the project main folder is under the open_basedir restriction, file_exists() call will generate PHP warnings; because the extension cannot find the composer.json due to open_basedir restriction. Because it does not find the file, the algorithm continues down until it reaches the filesystem root. In another scenarios, we could deploy applications without the composer.json (why not).
Is there any valid reason for doing this lookup?
In our use case, due to this buggy lookup behaviour, it will register a Twig_Loader_Filesystem instance which is plugged on the filesystem root (it seems very, very wrong to me).
In most Symfony applications, this would suffice:
$composerRootDir = dirname($container->getParameter('kernel.root_dir'));I don't understand why this was introduced, it seems to give a more flexible way of registering templates for highly customized projects, but it's also a very dangerous thing to do.
Another way of fixing this might by introducing an optional parameter we could set ourselves to the project root, such as:
if ($container->hasParameter('kernel.composer_root_dir')) {
$composerRootDir = $container->getParameter('kernel.composer_root_dir');
} else {
$composerRootDir = $this->getComposerRootDir($container->getParameter('kernel.root_dir'));
}