Describe the bug
when using the option to change the default public directory to another folder (see https://symfony.com/doc/current/configuration/override_dir_structure.html#override-the-public-directory) the filename stored in db contains the complete path to the file on the filesystem not only the relative part
the property is configured like:
- property: image
type: 'file_upload'
type_options: {
upload_dir: 'html/uploads/',
download_path: 'uploads/',
upload_filename: '[timestamp].[extension]'
}
and in composer.json i have:
"extra": {
"symfony": {
"allow-contrib": false,
"require": "4.4.2"
},
"public-dir": "html"
},
now in the database column something like '/home/user/dev/project/html/uploads/file.jpg' is stored, but there should be nothing about the root
To Reproduce
This also happens under Symfony 5 with the default public directory, storing the full path to the file (with an additional path separator before the final file name, but I am not sure if that is a config error on my end). My config is basically default, just with upload_dir: 'public/cast/', download_path: 'cast/' and the default upload_filename; resulting in <project_root>/public/cast/\file.png where one would expect a simple file.png.
After looking through the code, it looks like this is intended behavior (and it happens in all cases, not just when the public folder is moved). If the path is relative, the configuration input normalizer in Form\Type\FileUploadType (line 159, specifically) will prepend the project directory to the input and store that as the configuration. Other places in the code base seem to rely on this value being an absolute path, though I'm sure many if not all of them could be converted to the expected relative path (the big one I believe being the StringToFileTransformer that gets used for mapping paths to File objects).
It would be nice if we could get relative paths, as it would make it so much easier to do offline stuff on another box before pushing the resulting database to production. But otherwise it's not too difficult to work around, especially if all you need is the basename of the file.
Now FileUploadType compatible with ImageType, but StringToFileTransformer is also hardcoded. Maybe we need add to constructor custom Transformer?
Most helpful comment
After looking through the code, it looks like this is intended behavior (and it happens in all cases, not just when the public folder is moved). If the path is relative, the configuration input normalizer in
Form\Type\FileUploadType(line 159, specifically) will prepend the project directory to the input and store that as the configuration. Other places in the code base seem to rely on this value being an absolute path, though I'm sure many if not all of them could be converted to the expected relative path (the big one I believe being theStringToFileTransformerthat gets used for mapping paths toFileobjects).It would be nice if we could get relative paths, as it would make it so much easier to do offline stuff on another box before pushing the resulting database to production. But otherwise it's not too difficult to work around, especially if all you need is the basename of the file.