OrchardCore
OrchardCore copied to clipboard
Keep file name of attached media files
Awesome we have a new contributor 🐰
It's making us wonder if we want to display something that actually doesn't exist. Also if it would make sense to keep the original filename in the new file computed one.
For reference when we discuss this further. That's what a file name looks like
https://localhost:44300/blog1/media/mediafields/Article/41vqf90jr6ey03m859ts1tb759/0deb0e222f66fc43f580f76f8b51d522.jpg
/mediafields/.../GUID/MD5Hash.jpg
What if instead of prepending a guid to the file name and then hashing that for the final file name it used that guid for another sub folder to keep from overwriting files with the same name and then just keep the original name?
So then the path would look like this: /mediafields/.../ContainerItemGuid/FileGuid/OriginalFileName.jpg
It's making us wonder if we want to display something that actually doesn't exist. Also if it would make sense to keep the original filename in the new file computed one.
I would prefer the original name be kept if it can be. That way if a user downloads the file it will have the original name. What do you think of the suggestion in my previous comment?
@deanmarcussen I will update my changes to only store the file name, not display it and make the other changes you suggested here.
I do think something needs to be done to the admin display for files that don't have a thumbnail image like pdfs because right now it just shows a blank thumbnail and a hashed name so admin users have no indicator of what files they have already attached. But maybe that should be a separate issue or discussion.
merge conflicts to fix
merge conflicts to fix
The conflicts were with the wwwroot\Scripts\media.js and media.min.js files. I resolved the conflict by overwriting mine with the OrchardCMS main. These files were updated by gulp. Should they be excluded from git? If not, I will add my generated files back to this once it is working.
These files were updated by gulp. Should they be excluded from git? If not, I will add my generated files back to this once it is working.
You'll need to regenerate with gulp, and commit to source control (we have to keep the generated files in source control because not all users, use the NuGet releases, some use the repository directly)
I recomend using gulp watch
and just changing the media.js file so it rebuilds, rather than trying to rebuild the entire pipeline
Since this pull request has code that was changed then reverted, if it would make for a cleaner pull request, I can cancel this and make my changes on a fresh fork and do a new pull request if you want. Just let me know.
Is it breaking anything in its current state when migrating from a previous version? What happens if the metadata is not preset?
Is it breaking anything in its current state when migrating from a previous version? What happens if the metadata is not preset?
@sebastienros It does not seem to be breaking anything when migrating from a previous version. Files that were attached before the migration will have the metadata added with a null value.
Here is what I did to test it:
- Checked out the release/1.4 branch and ran the cms.web project.
- Created a site with the Agency Theme and added a content type with a media field set to use the attached editor
- Created a new item, attached a document, and published.
- Checked out my branch and ran the cms.web project.
- Viewed the content item and inspected the file object using the Vue explorer in Chrome.
- Attached another file to the same content item as before and published.
- Viewed the content item and inspected the file objects using the Vue explorer in Chrome.
Related to #4563