Contao not working with Symfony 3.2.7

[agoat]

This night the Symfony 3.2.7 is released. Contao will not work after Symfony is updated to 3.2.7!!

I think the reason have to do with some changes in Symfony 3.2.7 to the rootDir or webDir variables.

In the backend no css or js files could be loaded, because the symlink for the theme/flexible is wrong. In the frontend no images or css and js files could be loaded, because they will not be generated.

[aschempp]

I had exactly this issue yesterday evening! Do you know what changed in Symfony?

[agoat]

After some quick investigation it seems I was wrong. It's not the rootDir or webDir variable (wich are contao related and not from symfony).

I think the problem has to do with the changes in the makePathRelative method in the filesystem class made in https://github.com/symfony/symfony/pull/22133. But I have to do some more tests..

[agoat]

Ok, it's definitive the makePathRelative method used in the SymlinkUtil, TemplateLoader and ContaoCacheWarmer classes.

The method returns false relative paths. E.g. for the backend theme the paths are always one level to short ('../vendor/contao/xx' instead of '../../vendor/contao/xx').

I think it's a bug in Symfony!!

[aschempp]

Thanks for debugging!! Will you provide a fix for Symfony (you'll get core contributor 😉)?

[agoat]

Some other tests show that for the makePathRelative method it is necessary to have the same path roots for the endPath and startPath values.

I tested the following:

$fs = new \Symfony\Component\Filesystem\Filesystem();

dump($fs->makePathRelative('vendor/contao/core-bundle/src/Resources/contao/themes/flexible','system/themes'));
dump($fs->makePathRelative('install/dir/of/contao4/vendor/contao/core-bundle/src/Resources/contao/themes/flexible','install/dir/of/contao4/system/themes'));

Result on Symfony 3.2.6:

"../../contao/core-bundle/src/Resources/contao/themes/flexible/"
"../../vendor/contao/core-bundle/src/Resources/contao/themes/flexible/"

Result on Symfony 3.2.7:

"../contao/core-bundle/src/Resources/contao/themes/flexible/"
"../../vendor/contao/core-bundle/src/Resources/contao/themes/flexible/"

So it looks like it's because this method is used in a wrong way in contao?!

[ausi]

I think it’s a Symfony bug: ->makePathRelative('foo1/bar', 'foo2/bar') returns ./ which is wrong.

The documentation of the method defines that the parameters should be absolute paths, but there are tests for relative paths too. I think the method should either throw an exception if the path is not absolute or handle relative paths correctly.

@agoat do you want to report the issue in Symfony or should I take care of it?

[agoat]

I think it’s a Symfony bug: ->makePathRelative('foo1/bar', 'foo2/bar') returns ./ which is wrong.

As I explained above, it only works if the endPath and startPath will have the same basis (makePathRelative('foo/foo1/bar' , 'foo/foo2/bar') returns '../../foo1/bar'). But one of there tests is similar to your example (makePathRelative('/aab', '/aa') is expected to return '../aab/' but I don't think it will). The problem is not if it's absolute or relative (with or without '/../') but it fails when the endPath and startPath will have different basis.

I will have to do some more tests and will report it to Symfony.

[ausi]

The problem is not if it's absolute or relative

I think the relative paths are the problem because makePathRelative('/a/b', '/c/d') works but makePathRelative('a/b', 'c/d') does not work. I did not notice any problems with absolute paths in my tests, only with relative ones and only if their base directory is not the same.

[agoat]

Thanks @ausi, good to know. I can not go on until tomorrow because I'm on a contao meeting tonight.

Feel free to report the bug to Symfony, or I will do it tomorrow.

[ausi]

Feel free to report the bug to Symfony

Done in symfony/symfony#22321

[discordier]

Ad-hoc measurements to be taken for current installations are to add the following in composer.json of affected installations:

+    "conflict": {
+        "symfony/symfony": "3.2.7"
+    },
     "require": {
         "php": ">=5.5.0",
         "symfony/symfony": "~2.8|~3.0",

And run composer update again.

This assumes that the issue will get fixed in symfony 3.2.8 and therefore will safely upgrade to that version when it becomes available.

[leofeyer]

See #752.