Skip to content
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

Merged
merged 17 commits into from
Sep 22, 2022
Merged

Keep file name of attached media files #10570

merged 17 commits into from
Sep 22, 2022

Conversation

DrewBrasher
Copy link
Contributor

No description provided.

@dnfadmin
Copy link

dnfadmin commented Oct 27, 2021

CLA assistant check
All CLA requirements met.

@Skrypt
Copy link
Contributor

Skrypt commented Oct 27, 2021

Awesome we have a new contributor 🐰

@sebastienros
Copy link
Member

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.

@deanmarcussen
Copy link
Member

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

@DrewBrasher
Copy link
Contributor Author

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

@DrewBrasher
Copy link
Contributor Author

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?

Copy link
Member

@deanmarcussen deanmarcussen left a 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());
Copy link
Member

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

Copy link
Contributor Author

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
Copy link
Member

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 .

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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>\
Copy link
Member

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.

Copy link
Contributor Author

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

@DrewBrasher
Copy link
Contributor Author

@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.

@deanmarcussen
Copy link
Member

merge conflicts to fix

# Conflicts:
#	src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.js
#	src/OrchardCore.Modules/OrchardCore.Media/wwwroot/Scripts/media.min.js
@DrewBrasher DrewBrasher marked this pull request as draft December 14, 2021 13:44
@DrewBrasher
Copy link
Contributor Author

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.

@deanmarcussen
Copy link
Member

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

@DrewBrasher DrewBrasher marked this pull request as ready for review February 10, 2022 20:23
@DrewBrasher
Copy link
Contributor Author

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
@sebastienros
Copy link
Member

Is it breaking anything in its current state when migrating from a previous version? What happens if the metadata is not preset?

@DrewBrasher
Copy link
Contributor Author

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:

  1. Checked out the release/1.4 branch and ran the cms.web project.
  2. Created a site with the Agency Theme and added a content type with a media field set to use the attached editor
  3. Created a new item, attached a document, and published.
  4. Checked out my branch and ran the cms.web project.
  5. Viewed the content item and inspected the file object using the Vue explorer in Chrome.
    image
  6. Attached another file to the same content item as before and published.
  7. Viewed the content item and inspected the file objects using the Vue explorer in Chrome.
    image

@PiemP
Copy link
Contributor

PiemP commented Sep 22, 2022

Related to #4563

@sebastienros sebastienros merged commit e2d8c29 into OrchardCMS:main Sep 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants