-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Keep file name of attached media files #10570
Conversation
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
|
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: |
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewing the issue, I agree with @matiasmolleja when this was originally designed, the hash was an important part of the design for the feature.
The suggestion was to provide a less well known field, which could be used when displaying the media item (in the front end, not the admin) to provide some context to the user as to the file they might be downloading.
I'm open to being convinced we could show this information in the admin as well, but it would have to be an addition the the actual file name created from the hash.
I'm open to seeing how we could maintain the hash and the original file name (without hacks), but I don't see a particular way forward there.
@@ -123,6 +145,8 @@ public override async Task<IDisplayResult> UpdateAsync(MediaField field, IUpdate | |||
|
|||
field.Paths = items.Where(p => !p.IsRemoved).Select(p => p.Path).ToArray() ?? new string[] { }; | |||
|
|||
field.SetAttachedFileNames(items.Where(i => !i.IsRemoved).Select(i => i.AttachedFileName).ToArray()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should only happen when the editor is attached. Around line 115
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved that line up in 5280f52
{ | ||
var lastSlash = items[i].Path.LastIndexOf('/'); | ||
var nameOnly = items[i].Path[(lastSlash + 1)..]; | ||
items[i].AttachedFileName = nameOnly[36..]; // remove unique id from name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better if the javascript app includes the AttachedFileName
on it's post, than having to do this .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this code in 99ece16 but I'm still trying to figure out where to include it in the JavaScript app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deanmarcussen, If I understand how this works correctly, when you select or drop in a file it immediately posts the file and saves it to a temporary location and then moves it once you save the content type the file is attached to. Is that correct and if so, at which step should the AttachedFileName be set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I figured it out but I'm not sure I did it the best way. Stepping through the JavaScript I did not see another way but I may have missed something. It's in this commit: 481d4f3
@@ -3351,7 +3356,7 @@ Vue.component('mediaFieldThumbsContainer', { | |||
<div class="media-container-main-item-title card-body">\ | |||
<a href="javascript:;" class="btn btn-light btn-sm float-right inline-media-button delete-button"\ | |||
v-on:click.stop="selectAndDeleteMedia(media)"><i class="fa fa-trash" aria-hidden="true"></i></a>\ | |||
<span class="media-filename card-text small text-danger" :title="media.name">{{ media.name }}</span>\ | |||
<span class="media-filename card-text small text-danger" :title="media.name">{{ media.attachedFileName == null ? media.name : media.attachedFileName }}</span>\ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @sebastienros here, we shouldn't be showing anything different in the edit UI here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reverted my changes to the admin display in 5cd1a81
@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 |
# Conflicts: # src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.js # src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.min.js
…e name not the original file name
…the Attached editor
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. |
…e name not the original file name.
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 |
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. |
# Conflicts: # src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.js # src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.min.js
# Conflicts: # src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.js # src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.min.js
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:
|
Related to #4563 |
No description provided.