Twig cache contains absolute paths
I noticed this in a Symfony app but while trying to see where the error was, I noticed that it's actually Twig core behaviour. Yet reproducing it is probably easier using Symfony Flex:
composer create-project symfony/skeleton . 4.4.*composer req twigAPP_ENV=prod ./bin/console cache:warmup
You'll see that the cache contains files along the following lines:
<?php
use Twig\Environment;
use Twig\Error\LoaderError;
use Twig\Error\RuntimeError;
use Twig\Extension\SandboxExtension;
use Twig\Markup;
use Twig\Sandbox\SecurityError;
use Twig\Sandbox\SecurityNotAllowedTagError;
use Twig\Sandbox\SecurityNotAllowedFilterError;
use Twig\Sandbox\SecurityNotAllowedFunctionError;
use Twig\Source;
use Twig\Template;
/* @Framework/Form/time_widget.html.php */
class __TwigTemplate_884348209061bf9effea81fda27c890a9a31886d0f62de99211558053cc7ec90 extends \Twig\Template
{
private $source;
private $macros = [];
[...]
public function getSourceContext()
{
return new Source("", "@Framework/Form/time_widget.html.php", "/absolute/path/to/project/vendor/symfony/framework-bundle/Resources/views/Form/time_widget.html.php");
}
}
Actually this is the only place where I noticed absolute paths in a typical Symfony cache which causes issues if e.g. you have a chrooted SSH user and a different path in the web process.
Not sure how to fix it though. The FilesystemLoader seems to provide absolute file paths by contract.
@fabpot @nicolas-grekas maybe we should dump the source path by building a path relative to __DIR__, as we do in Symfony when dumping the container.
What do you think ?
The drawback I see is that this would make the code generation dependant on the internal cache implementation (and the fact that it is stored on the filesystem), unless the cache layer itself is responsible for performing the replacement.