Appears to be adding an extra /media to the path and returning /media/media/some_file_path/file.ext which isn't valid and won't download.
In Translation Manager we have a call that we use to calculate where a file is accessible when its placed in the media section. for this we use a
mediaFileSystem.GetUrl(path) call:
(the path value something like /media/xliff_translation/somexlifffile.xlf)
On a local Umbraco site configured with azure blob storage provider -
this returns the correct url of the media - in these cases :
if we have AzureBlobFileSystem.UseDefaultRoute:media = true
the call returns /media/xliff...
if we have AzureBlobFileSystem.UseDefaultRoute:media = false
returns /your-blob-thing/xliff...
if we disable virtual providers ( AzureBlobFileSystem.DisableVirtualPathProvider)
however as stated above on Umbraco Cloud (vNext) we get :
/media/media/xliff_translations/somefile.xlf
Question:
Is there something else configured on Umbraco vNext cloud blob storage that we need to be aware of ? (Is Umbraco Cloud vNext actually using the Public AzureBlobFileSystem provider or does it roll its own ?)
Answering my own question (with help from morten @ HQ)
It looks like the Umbraco Cloud Storage provider works assuming that the path you pass in is already rooted in the media folder .
e.g :
/xliff_translatation/somefile.xlf is in /media so it append that when returning the URL.
The Community AzureBlobStorageProvider can work both ways, so it also accepts the full /media/xliff_translation/ version which it will clean and only add /media if its missing.
You can pass rooted paths to the Community provider - so you should use this method only - to stop different behavior on Umbraco cloud sites.
MediaFileService.GetUrl on Umbraco Cloud vNext
On Umbraco.Cloud vNext calling
Appears to be adding an extra
/mediato the path and returning/media/media/some_file_path/file.extwhich isn't valid and won't download.In Translation Manager we have a call that we use to calculate where a file is accessible when its placed in the media section. for this we use a
mediaFileSystem.GetUrl(path)call:(the path value something like /media/xliff_translation/somexlifffile.xlf)
On a local Umbraco site configured with azure blob storage provider - this returns the correct url of the media - in these cases :
AzureBlobFileSystem.UseDefaultRoute:media = true/media/xliff...AzureBlobFileSystem.UseDefaultRoute:media = false/your-blob-thing/xliff...AzureBlobFileSystem.DisableVirtualPathProvider)https://[something].blob.core.windows.net/[your-blob-thing]/xliff_translations/somefile.xlfhowever as stated above on Umbraco Cloud (vNext) we get :
Question:
Is there something else configured on Umbraco vNext cloud blob storage that we need to be aware of ? (Is Umbraco Cloud vNext actually using the Public AzureBlobFileSystem provider or does it roll its own ?)
Answering my own question (with help from morten @ HQ)
It looks like the Umbraco Cloud Storage provider works assuming that the path you pass in is already rooted in the media folder .
e.g :
The Community AzureBlobStorageProvider can work both ways, so it also accepts the full
/media/xliff_translation/version which it will clean and only add /media if its missing.You can pass rooted paths to the Community provider - so you should use this method only - to stop different behavior on Umbraco cloud sites.
is working on a reply...