Hi, thanks for feedback!
aran4649 wrote:- Default timezone: since my server is not in the same timezone as myself, all the photo times are off (by 8 hours). It could be possible to figure out the actual timezone for each photo by checking GPS coords inside them (where present), but it sounds like a lot of work for a detail. Could you have a default timezone in the options instead? Like that most times would be correct, at least for the photos taken locally.
Interesting :thinking: Files on your server have "modified time" and that number is simply converted to date. I suppose it's possible to read timezone of server and then create offsets based on browser(user) timezone. This wouldn't be logical with photos where DateTimeOriginal is stored in the image (from camera EXIF) though ... If a photo is taken on 03. Jan 2021 at 15:40:21, that time is atomic and shouldn't be affected by timezones obviously. As for checking GPS coordinates where one has to consider all global timezones vs browser timezone vs server time, seems dodgy ... Besides, images that have GPS coordinates should normally contain EXIF DateTimeOriginal? I don't see any scenario where a photo's own DateTimeOriginal should be offset based on browser timezone ...
aran4649 wrote:-Public folder: for most of my uses, having a guest login is probably overkill. Still, it would be nice ro grant full upload rights available to everyone JUST FOR ONE FOLDER. This would let my friends to share their photos easily while keeping the rest of the server safe.
Indeed :ok_hand: This is definitely on the agenda, but first we need to implement a proper multi-USER system with permissions so that file manager features can be assigned per user. With multi-user, you would also be able to assign user-'ROOT', which means each user can see and access a different root folder. As for assigning different permissions for different folders per-user (as you are requesting), I must admit that's a big challenge. This means we need to store folder paths inside user configs, which means things will break if you rename folders on server. Optionally, we can store permission-configs inside each folder, although my aim for Files app is primarily to remain passive without adding app-files into user's directories.
aran4649 wrote:-Default grid size: it's already possible to set the default display type between list, grid and so on. Could it be possible to preset grid size too (equivalent to having the UI slider already moved)?
It's actually possible already with custom CSS. I might keep these options in CSS, because
1. the option itself is pure CSS, and
2. I don't want to start adding hundreds of minor cosmetic options into the core PHP config. Just create an empty file _files/css/custom.css, and add this:
#files {
--grid-size: 200px;
}
Keep in mind, grid will "snap" to available browser width so the above is just the "target" width.
aran4649 wrote:-GPX preview: I'm using your script to record my hikes. So far, I'm just saving a GPX record file inside their folders, for local download. But it would be great to have them displayed in the browser too. It could be done quickly the leaflet.js library or a simple link to gpx.studio and would be a great addition for all hikers using the script
That could be an interesting plugin. I found a demo of how it could look:
http://mpetazzoni.github.io/leaflet-gpx/
In Files app, when user clicks a GPX file, it would then open some modal/popup displaying a map similar as the above.
aran4649 wrote:-Local CDN caching: admittedly making this a single file script was a huge selling point for me, and I thank you for the headaches it must have caused you. Still, relying on CDN downloads for core components casts a shadow for the the future. This will be my own photo album and I might want to keep it for the next 10 or even 20 years, who knows of all downloads will be available then? Is it technically possible to have an option for all CDN libraries to be stored locally too, so that they can still be accessed if their online counterparts fail later?
Yes it's possible and I believe it's already requested. This of course means you will need to install Files app with required JS/CSS assets folders, and it won't then be "portable" like a single-file app. It also means that when you want to update Files app, you will need to update the assets also (which would be included in the "full" download package). Not too complicated for persistent Files app installations ...
As for CDN, personally I don't see much problems. We use
jsdelivr.com, and like with other public CDN services (like Google and Cloudflare), they never went down, never go down and I don't see that they ever will. In addition, they provide faster loading resources to your visitors than your own server ever will.
Ok thanks!