File Manager

[rallisf1]

Is your feature request related to a problem? Please describe.
Primo only allows for image uploads. My websites also include videos, custom fonts, pdfs etc.

Describe the solution you'd like
A simple file manager that can upload/download/rename/delete files per site. Image editing would be nice as well. I'd be happy to implement this myself. I found this nice library to manage uploading and image editing, and I'll DIY the rest of the UI/backend.

Describe alternatives you've considered
In v1 I manually uploaded any files I needed through Supabase dashboard in the assets folder. In v2 having 2 buckets kinda confused me. Like: should I put my fonts in sites bucket or images? Maybe I should manually create a fonts or a files bucket? Why images bucket and not just assets? Having multiple buckets will make the file manager unnecessarily more complicated IMHO.

Additional context
Since everything deploys to github now; maybe the assets should be deployed there as well so the CDN of the client's choice (a.k.a. wherever he actually deploys the site) serves them instead of supabase.

We can also automatically create thumbnails through this without using Supabase's Storage Image Transformations.

Moreover; the file manager should also be aware of supabase's and github's quotas and show a progress bar meter. Also when trying to upload something that won't fit it should cancel the upload and produce an error.

[mateomorris]

Seems like a 'File' field type would solve this. Initially I thought about having a 'files' button in the toolbar to see all the files used on the site, but that would separate that from the modular context they're being used, so if you add files from there you'd then have to go into the Block where they're used and select them. It could possibly be used in conjunction with adding/removing files from the Block fields, but adding the field would be the first step.

I like the idea of adding another bucket named 'files' since Primo's going to treat images and files separately (at least with different field types). And that way we can avoid breaking changes.

[rallisf1]

I still prefer having a "file manager" for the entire site as I am not necessarily using the files in a component; thus a simple files field, similar to how image field works minus the thumbnail, won't cut it.

What I propose

Bucket Structure

Sites - not available in file manager, for internal use
Images - available in file manager plus image editor
Files - available in file manager for any other file type

Needless to say that you need to have the site open in Primo and you can only access that site's folders.

Functionality

• Upload with multi-file support
  • We can use filepond, dropzone or just a plain upload button
• Download File(s)
• Rename File which should update the paths in components' used files
• Delete File(s) which should first check the components for used files
• Edit
  • Adding an image editor is cool but not essential. It can help people create thumbnails or filter variants, which can also be automated in code (e.g. have an option to autocreate X custom resolutions on image upload).
  • The Pintura image editor suggested by filepond is great but it is not free (it adds a watermark on the free version), we could definitely add it later as an option for whoever wants to pay it as it also has a video editor ^^
  • Next one on my list is filerobot
  • Another one is tui.image-editor, but I believe will be a pain to integrate as it is a part of a much larger ui library
  • We can also throw in a code editor for anyone who wants to upload & edit json or markdown files or whatever; this is already bundled in Primo anyway

Fields integration

Image Field

Instead of directly uploading an image it opens the file manager straight in the images bucket. You can select an image from there or upload a new one.

Different image variants the user may have created (e.g. full, thumb-small, thumb-medium, full-filter-sepia etc.) could all live in a dropdown selector:

• right click context menu inside the file manager or
• a <select> after he has selected the image exactly below the description input

Files Field

Instead of directly uploading a file it opens the file manager straight in the files bucket. You can select a file from there or upload a new one. Some files can even have previews (e.g. PDFs).

UX Issues

1. Should the user be able to upload images to the Files bucket or files to the Images bucket? I believe not.
2. No move/copy/cut functionality. At least the API doesn't provide it. We could manually "download" the file to localstorage and reupload it but each browser's limit is different and varies from 3MB to 10MB.

UI

I'll prepare some drafts

[mateomorris]

Great ideas! When would you upload files but not use them in particular blocks? I could see it being useful to manage all of the images/files on the site from one place though.

Thinking about it some more, the two categories (images and files) could just be folders corresponding to buckets. Those would just be the default two folders, but you could replace them or add more folders, setting accepted file types for each (e.g. SVGs, fonts, videos). Then the image field and file field would have access to all of the images/files, categorized by folder and have the capability to upload new images/files.

[rallisf1]

I prepared some UI drafts based on the current primo layout and theme. Don't expect them to be perfect. I didn't invest much time; just something to brainstorm on.

Files Pane with a JSON file selected

Image Pane with an image selected

Image Pane with an image being edited (filerobot)

[Amerlander]

I was looking for a alternative to uploading the files to supabase and found this issue.
I would love to see an option to upload files to github instead of supabase and then deploy them together with the html files.

Maybe it is possible to include some image optimizations, like https://kit.svelte.dev/docs/images#sveltejs-enhanced-img
So a uploaded Image could be rezised at buildtime.

Benefits:

• No file limit on github, Supabase has a 1GB limit in free plan
• Further image optimizations
• Page can be deployed without having to rely on a database to be available
• In case of some kind of file explorer: files can be refferenced multiple times