Closed sovetski closed 4 months ago
@garak should be fine now
This change broke our whole implementation. Why was this not done in a major release?
We're using flysystem as our storage backend.
Before this change, everything resolved fine, e.g. to a URI like:
https://bucket.ams3.digitaloceanspaces.com/media/cache/filter/subdir/c5b74a86da9c6a4e4c7132a2be83d3f43c9cade7.jpeg
After this change the following was resolved:
https://bucket.ams3.digitaloceanspaces.com/media/cache/filter/https---bucket.ams3.digitaloceanspaces.com/subdir/4ea7859db76e4befaf27ad97864ac36b4976e29d.jpg
We are using the helper to get the path, and then attempt to read it using our flysystem cache adapter, e.g.
$path = $this->helper->asset($entity);
$content = $this->defaultStorage->read($path);
Hi @alcohol, what does your helper exactly? Can you put the code here? The problem can also be related to your custom adapter, do you have all required methods implemented? If you can provide your code here, it will be easier to debug it and see the problem.
The helper is simply an instance of Vich\UploaderBundle\Templating\Helper\UploaderHelper
.
Instead of returning a path it is now returning a full uri.
@alcohol if in your helper, you change the "resolveUri" by "resolvePath" does it work?
@alcohol if in your helper, you change the "resolveUri" by "resolvePath" does it work?
It is not my helper, it is vendor code from this library. Previously we were getting $mapping->getUriPrefix().'/'.$path;
, now we are getting the $fs->publicUrl($path);
@alcohol if in your helper, you change the "resolveUri" by "resolvePath" does it work?
It is not my helper, it is vendor code from this library. Previously we were getting
$mapping->getUriPrefix().'/'.$path;
, now we are getting the$fs->publicUrl($path);
As I am not able to do it at the moment, you can try to edit the vendor's code just to see what happens and put the original code back? I am not using S3 or this helper, that is why I need more details from your side if possible, to be able to find a fix
The behaviour documented here has changed if you use the FlysystemStorage
implementation: https://github.com/dustin10/VichUploaderBundle/blob/master/docs/generating_urls.md#generating-a-url-in-a-controller
I am not saying this change is bad, but it drastically differs from what is documented and was previously default behaviour. The FlysystemStorage
storage was falling back to the resolveUri
method from the AbstractStorage
implementation. By overriding that method the returned value can be very different suddenly. While this might be considered a "bugfix", I feel such a major change should have been done in a new major version.
Hello
I had the same issue, I guess bundle like https://github.com/1up-lab/OneupFlysystemBundle/tree/main are not "ready" for this change because I can't see where we can configure public urls (https://flysystem.thephpleague.com/docs/usage/public-urls/) Or maybe I miss something ?
Never used flysystem myself, please let me know if I need to revert this change
@Cryde I don't know if it can help, but for Flysystem, I am using this package and it works as expected: thephpleague/flysystem-bundle, documentation: https://github.com/dustin10/VichUploaderBundle/blob/master/docs/storage/flysystem.md#integrating-with-thephpleagueflysystem-bundle
@garak as mentionned @alcohol, maybe you can put it in a major release instead?
I could put it in a major, but a major release is not currently planned
This update broke things for us too. We are storing images in S3 using a Cloudfront URL as a uri_prefix
. The uri_prefix
config is now completely ignored and the S3 URL is returned when using the \Vich\UploaderBundle\Templating\Helper\UploaderHelper::asset
method.
This update broke things for us too. We are storing images in S3 using a Cloudfront URL as a
uri_prefix
. Theuri_prefix
config is now completely ignored and the S3 URL is returned when using the\Vich\UploaderBundle\Templating\Helper\UploaderHelper::asset
method.
It solves a problem that shouldn't be there in the first place. I'm not opposed to reverting this change, but do you have a better approach to suggest?
Reverting is just a way to put the problem back; I find suggesting an improvement more interesting than wiping everything out at once.
If everyone agrees to test, I can submit a new pull request to fix the issue for existing projects. But again, just because it works with a makeshift solution doesn't mean it should never evolve (in my opinion)
What about adding an alternate storage? We need to avoid breaking existing implementations
I understand that it solves a problem, but it does so by breaking existing functionality.
Forgive me if I'm misunderstanding, but looking at this code:
The code within the try
block completely ignores the uri_prefix
config, doesn't it? So it breaks for anyone using any uri_prefix
?
@andyexeter yes you are right, it prioritizes the publicUrl instead of uri_prefix. As @garak said, we should avoid to break existing implementations, I will do a PR to revert changes, and maybe in the future it will be implemented as a major change
@garak the PR is ready to rollback changes: https://github.com/dustin10/VichUploaderBundle/pull/1444
It resolves a lot of problems related to Flysystem.
Without this PR, if we are using S3, Cloudflare images or other cloud storage, the public url is not the CDN one but a local url which is incorrect.
For the people who will suggest using
uri_prefix
, as I mentionned here: https://github.com/dustin10/VichUploaderBundle/issues/1434#issuecomment-2041172155 In my case it is impossible to adduri_prefix
manually, because in Cloudflare, the file name is not at the end, it is something likehttps://imagedelivery.net/qsdazd54azd98a4z69d5/image3.jpg/public
the/public
at the end makes it impossible because it is not just a prefix, we have to do some sprintf etc.The problem existe since more than 8 years, I think it is time to automatise it with this PR.
I hope that it will be ok for maintainers.
Related:
https://github.com/dustin10/VichUploaderBundle/issues/1418 https://github.com/dustin10/VichUploaderBundle/issues/1434 https://github.com/dustin10/VichUploaderBundle/issues/502 https://github.com/dustin10/VichUploaderBundle/issues/1089 https://github.com/dustin10/VichUploaderBundle/issues/539