Media finder and file upload

[khoatran]

Hi everyone,

This is a question that help us rethink about the UX to make what we provide in OctoberCMS should be consistent.
For a long time, I am very curious with the question: why should we need 2 types of widget Media Finder and File upload?

With this question, I deeply understand the implementation of these widgets are completely different. What I want to address is just the concerns under different point of views as below:

1/ As an editor
As an editor, it really confuses me when I can do the file uploading with File upload, but I cannot pick existing file that I uploaded somewhere in the past to use. If I use the Media finder, I can do both file uploading + picking existing image if I want. Somehow, media finder is a good choice for me (as an editor).

2/ As an administrator:
I have the feeling that I would prefer the file upload for most of cases as the editor will not be able to access any where that I cannot control. They just need to upload the file... and done. The new file will 'replaced' the old one. I love this option as I don't know how to control the place they can upload the file in the whole file hierarchy.

3/ As a developer:
I love File upload widget as I can use the 'attachment model' for any entity. The real relationship is implemented inside the system_files table.
However, I would love to use Media finder for case of 1 single file needed for the entity.
With this reason, sometimes I make random choices, especially for the case of single file needed for an entity property.

4/ As the boss of the developer:
I don't really understand why my developer get messed with random choice of File upload and Media finder in the form they code.

Sometime, the end user in my company comes to my desk and ask: why I don't have the consistency at everywhere that I need to do the file uploading? -> I am getting stuck with this simple question.

What we should do?

So, let's pause some seconds to see what is the outcome we really expect. I would define the outcome as below (based on above opinions):

• As an editor, I want to have a consistent way in everywhere I need to do a file uploading/ image selection.
• As an administrator, I expect to control the path that the guy can put the file to.
• As a developer, I want to have different options that I can configure the media widget to:
  • Store the output into a property of my model (if I need the path to store at there) OR add a new record to the system_file table to implement the attachable model.
  • Can support the administrator to control the folder permission by implementing an adapter and set into an option of the media finder widget to pick the right folder for the current logged in user to upload file.
• As the boss of the developer:
  I don't want my developer mess up and make my user confused :)

The final solution should be: using only one widget which support above options.
If anyone see this is a good recommendation, please vote for this ticket.

Thanks everyone

[LukeTowers]

Feature requests as issues are only acceptable if you are using it as a pre-PR communication. If you aren't planning on implementing it yourself, then it would be better suited being asked for on one of these channels:

Forum: http://octobercms.com/forum
IRC: #october on Freenode or http://octobercms.com/chat
Slack: https://octobercms-slack.herokuapp.com/

The support demand for October is increasing, while the available time the founders have to give remains the same. Please understand that these feature requests are lowest priority for us, although they may be considered in time. However there are ways you can help:

• Submit a pull request that introduces this feature and wait for it to be reviewed
• Post a bug bounty for this specific issue so that more people can become involved with creating a fix
• Make a financial contribution to the project so we can allocate more time towards making improvements like these that benefit everyone

[khoatran]

Hi Luke,

I planed to create a PR for this. However, I would love to see if other people love this idea.

Cheers,

[LukeTowers]

Awesome, thanks. Just wanted to let you know that we don't have time to implement something like this, but are still potentially open to it being done.

Just to add my two cents on the issue, I feel like this is something that can be managed at a local policy level within your organization. Fileuploads and the Media Library cover two fundamentally different use cases. File uploads are for files that are only going to be used once (think email attachments and user profile pictures) and need the ability to be protected from public consumption while everything in the Media Library is publicly accessible and it is intended for use cases like featured images or including in more than one section of the site.

Knowing this, it should be easy for your developers to understand where to use which widget. Thoughts?

[khoatran]

Thanks for your feedback.
I would agree with your recommendation about the local policy when applying these widgets. Actually, I did it to my team :). However, there are some difficulties make me rethink about the concept of mixing 2 widgets:

Most of my end users are non-technical. They don't really much care whether we use the image once or reuse them. However, the fact is they love features of both Media finder and File upload.

The problem is: now we cannot mix their features together. Let's say an example: it's really hard to implement the 'multi select' image like the File upload if you pick the Media finder. Imaging about the use case of a post has multiple featured images. I don't see how we can implement that with Media finder with the current implementation. Even the Rainlab blog plugin still uses File upload for the featured image use case which I don't agree much about the user experience in this case.

Normally, the image reusing backend is higher than the case of using just once. If we check Wordpress as an example, Media finder is used nearly everywhere for their features.

However, I don't mean the File upload use cases are nonsense. My main idea is: if we mix 2 widget types into one. We can focus on expanding its use cases to other options in an efficient way, eg: let's say we can do all of use cases just by configuring parameters of the widget.

Anyway, let me try to create a Proof Of Concept of this idea and will share to you guys. I hope it's useful

Cheers,

[ghost]

+1 for your idea. I implemented several october website and created several plugins.

When I create a plugin, I create 2 images field, one "Image" for simple image that use the media manager widget.

One "Images" for multiple image upload that use the file upload in "image mode"

• If the customer need only one image for this content type, I activate the media manager field and disable the other.
• If a customer need several image for this content type, I activate the file upload widget and disable the media manager.

When a customer need multiple image upload and a way to choose existing image, I answer that it's not possible at the moment due to a CMS limitation, and it's frustrating !

To me, the best solution would be to improve the media manager widget to be able to handle multiple images (upload, selection, etc...).

Another viable solution would be to add a "browse" button to file upload widget to be able to popup the media manager to pick an existing image.

[Eoler]

When a customer need multiple image upload and a way to choose existing image, I answer that it's not possible at the moment due to a CMS limitation, and it's frustrating !

There's a workaround if you stay with two fields - define attachMany relations in your models with image mode file upload fields as custom descendants of System\Models\File with overriden getStorageDirectory() function pointing to cms.storage.media folder. After that you will be able to pick uploaded media files (images) from models with image mode mediafinder fields.

[LukeTowers]

@Alex360hd @Eoler #1658 has been open for over a year now, I fully intend on implementing it, but I don't have a whole lot of time to dedicate to doing so. If someone is willing to sponsor a bounty for it, then I'm willing to get it done and merged.

[fenriz07]

@Alex360hd

When a customer need multiple image upload and a way to choose existing image, I answer that it's not possible at the moment due to a CMS limitation, and it's frustrating !

Same thing, it's frustrating, I solved it with the repeater component and a field in the json database, but it is not the best practice and there is no usability for the end user.

[LukeTowers]

@fenriz07 Same thing to you that I said earlier: this functionality will be added at some point, and if you want it sooner rather than later (i.e. when I have the time to do so), then consider either adding support for it yourself and making a PR, or sponsoring a bounty so that I can get to it sooner.

[ghost]

Do you have any ideas about the bounty you need to implement this ?

[github-actions]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.