-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The public link for uploaded media is not finable for users, made worse by the file name not being displayed consistently in different states #4209
Comments
Hi @equivalentideas thank you for opening this.
Mapping between the file and the public URL requires some prior knowledge by the CMS on how the build process works and where file will eventually be available. I classified this as a feature request as it would require some design |
Thanks @erezrokah , the CMS wouldn't need knowledge of the build process to know the public path for a file though would it? Because 'public_folder' is set in admin/config.yml ? Showing a path without knowledge of whether the file has been deployed could be confusing, in the same way that the view live links are, but it could be a step forward? One suggestion for how to present this could be to turn the file name display into a link to the file path? |
Also, :) wondering if your answer above applies to this element of the issue as well:
Thanks @erezrokah 💐 |
Good point. That would only work when not using editorial workflow mode and for deploy previews we would need to use something like: In both cases we would need a good way to figure out when the build is finished (or even started so we could display some kind of loading indicator). Maybe there is a bigger feature here for improving integration with CI systems. |
This is a bug, I recommend opening a separate issue for it. |
Describe the bug
When CMS users upload a document, they cannot determine what the public URL for it is, so that they can share it with others.
My colleague uploaded a pdf document, titled "Response to Coles and Woolies.pdf", after which the media upload screen appeared like this:
From here, they were unable to work out what the URL for the file they had just uploaded was. Not that on their screen, the file name is the same as what they uploaded.
They called me to try and work it out for them, and when I loaded the media centre I saw this:
I wasn't sure if this was the same file because the file name was different.
Knowing that our public media folder path was
/downloads/
I suggested to my colleague to see if putting the file name that they see on the end of/downloads/
worked.They replied, 'Nup. tried a bunch of different permutations. with the spaces, without spaces between words, using underscore between words'.
I then showed them the document named
response-to-coldes-and-woolies.pdf
that I saw in the media folder, and unexpectidly, this was the same document as what was collectResponse to Coles and Woolies.pdf
in their media folder.This flow was very confusing and frustrating to my colleague, who was trying to share a document very quickly to a deadline.
To Reproduce
Expected behavior
My colleague expected to see a link to the public document somewhere in the interface, so that they could copy it and use it as needed.
They also expected for the file name in the interface to be consistent between them uploading the file and me looking for it in the media centre. There's no obvious reason why this would change over time. I understand that we want to transform the file name to be nice in a URL, in this case, it should be transformed before it is shown to the initial uploader in the first place, so that it is consistent over time.
Screenshots
See above.
Applicable Versions:
*Chrome Version 84.0.4147.135 (initial uploader), Firefox 79.0 (me)
CMS configuration
n/a
Additional context
Thanks as always :) love your work.
The text was updated successfully, but these errors were encountered: