Vichuploaderbundle: StorageInterface -> resolvePath() does not resolve directory path

Created on 5 Jan 2016  Â·  24Comments  Â·  Source: dustin10/VichUploaderBundle

I have the following lines:

    /**
     * @var StorageInterface $storage
     */
    private $storage;

  public function getFilePath(Entity $entity)
    {
         $file = $this->storage->resolvePath($entity, 'file');

        if ($file && file_exists($file)) {
            return $file;
        }

        return null;
    }

But the resolvePath() method only resolves file name instead of path name. I already tried switching $relative param to use use absolute and relavant but I had no luck. I am also using oneup_flysystem for file storage but it not seem to be the issue.

Is there any workaround to retrieve absolute file path while using vich uploader mappings?

Awaiting PR Support

All 24 comments

How did you configure uri_prefix option?

Closing for missing feedback.

@garak uri_prefix is not relevant to this issue (not related to filesystem path).

I am having the same problem. @rasanga did you overcome it?

Because the file is not properly located in the fs, the DownloadHandler is also failing, despite the file being uploaded properly. I require the uploads to be stored outside the pubic space (web/uploads) and served via controller.

oneup_flysystem:
    adapters:
        document_adapter:
            local:
                directory: "%kernel.root_dir%/../attachments"

    filesystems:
        document_fs:
            adapter: document_adapter
            mount: document_fs

vich_uploader:
    db_driver: orm
    storage:   flysystem
    mappings:
        document:
            uri_prefix:         /attachments
            upload_destination: document_fs
            delete_on_update:   true
            delete_on_remove:   true
            namer:              vich_uploader.namer_uniqid
            inject_on_load:     true


See #858

@garak and what should we see there? it's a completely different problem

@garak I think in FlysystemStorage method doResolvePath does not work correctly. It must return smth like this ‌‌$fs->getAdapter()->applyPathPrefix($path); What do you think?

Sorry, I don't use Flysystem

@garak What do you mean you don't use Flysystem, VichUploaderBundle package assumes the use of an adapter for Flysystem. I mean this file
https://github.com/dustin10/VichUploaderBundle/blob/master/Storage/FlysystemStorage.php#L64

You ask for my opinion ("what do you think"). I'm sorry, but since I don't use Flysystem I can't give you my opinion.
This doesn't mean that this bundle is not supporting Flysystem

@garak ok, why did you close this issue?

Hi Garak !
I find this

    protected function doResolvePath(PropertyMapping $mapping, ?string $dir, string $name, ?bool $relative = false): string
    {
        $fs = $this->getFilesystem($mapping);
        $path = !empty($dir) ? $dir.'/'.$name : $name;

        if ($relative) {
            return $path;
        }

        return (string) $fs->get($path)->getPath();
    }

I use phpstorm and it said that
return (string) $fs->get($path)->getPath();
$fs->get($path) and exactly the (->get) is deprecated...
If this could be a way.
sans titre-1

That's true, method is deprecated in Flysystem.
This is not a problem for now, since the only version you can currently use is 1.*

Hi Garak i worked
Here is my config

vich_uploader:
    db_driver: orm
    form: true
    twig:  true
    storage: flysystem
    mappings:
        front_banners:
            uri_prefix: https://storage.googleapis.com/bucket/images
            upload_destination: google_filesystem
            inject_on_load: false
            delete_on_update: true
            delete_on_remove: true
            namer: vich_uploader.namer_origname

oneup_flysystem:
    adapters:
        google_adapter:
            googlecloudstorage:
                client: top.google_storage_client
                bucket: top.google_storage_bucket
                prefix: images
                storage_api_url: https://storage.googleapis.com

I will try to learn more about uri dfinition
Thank for all

This is still an issue. FlysystemStorage::doResolvePath does not return a path, it only returns the filename.

At present we have:

        return (string) $fs->get($path)->getPath();

In order to work correctly I believe it should be:

        return (string) $fs->getAdapter()->applyPathPrefix($path);

Feel free to open a PR

When is this going to be merged in to a stable release ?

Yeah there seems to be some confusion... the 'Awaiting PR' label was added... but a PR was submitted by myself a month before the label was added?

@Dark-reaper this is an issue, it can't be merged

@garak well the Fix for this issue has been made, when is it going to be merged into the package ?
https://github.com/leigh-ols/VichUploaderBundle/pull/1

@leigh-ols your PR is still not merged

@garak yes i'm aware... although i'm a touch confused... I've been waiting for someone with authority to merge it. Is there some action you are awaiting from myself?

https://github.com/dustin10/VichUploaderBundle/pull/1007

Tests are failing

There were 2 errors:
1) Vich\UploaderBundle\Tests\Storage\FlysystemStorageTest::testResolvePath with data set #1 (null, '/absolute/file.txt', false)
Error: Call to undefined method Mock_FilesystemInterface_bc4f7d31::getAdapter()
/home/travis/build/dustin10/VichUploaderBundle/Storage/FlysystemStorage.php:64
/home/travis/build/dustin10/VichUploaderBundle/Storage/AbstractStorage.php:86
/home/travis/build/dustin10/VichUploaderBundle/Tests/Storage/FlysystemStorageTest.php:159
2) Vich\UploaderBundle\Tests\Storage\FlysystemStorageTest::testResolvePath with data set #3 ('foo', '/absolute/foo/file.txt', false)
Error: Call to undefined method Mock_FilesystemInterface_bc4f7d31::getAdapter()
/home/travis/build/dustin10/VichUploaderBundle/Storage/FlysystemStorage.php:64
/home/travis/build/dustin10/VichUploaderBundle/Storage/AbstractStorage.php:86
/home/travis/build/dustin10/VichUploaderBundle/Tests/Storage/FlysystemStorageTest.php:159

Fixed

Was this page helpful?
0 / 5 - 0 ratings

Related issues

andrea-daru picture andrea-daru  Â·  3Comments

nobady90 picture nobady90  Â·  3Comments

archie18 picture archie18  Â·  6Comments

webkmua picture webkmua  Â·  4Comments

jcg678 picture jcg678  Â·  6Comments