truist / gallery Goto Github PK

We've decided to password-protect our gallery and share the password only with family and friends. For a quick first iteration, I've implemented this by configuring HTTP basic auth in my web server.

This doesn't play well with feeds, because most feed readers don't know how respond to HTTP auth challenges. I believe the typical solution for feed publishers is to generate a secret feed URL that includes an authentication token, and then only disclose the private feed URL to web users who are logged in.

For my needs, I think what I'm wishing for is a configuration option in Gallery to require in-app login before displaying albums/images/feeds, so that I can enable the option in my Gallery instance.

When clicking/tapping to the right of the last image (and probably also left of the first image) in an album, it "navigates" anyway -- to the full-size image. Maybe better to do nothing in that case?

Maybe it could try to generate a thumbnail from a rotated image that is only partially written?

In my "week2" album, the image list is in this order:

• ...
• IMG_5950.JPG
• IMG_5963.JPG
• ...

If I click on IMG_5950.JPG's thumbnail, then navigate "right", the next image is not IMG_5963.JPG, but rather IMG_5958_edit.png.

(Probably applies only to sort_images_by => 'date')

A friend was clearing his cache by deleting a particular album from the cache dir. That's not sufficient, because of the .rotated dir. Change how the cache dirs are structured so people won't trip over this.

Idea: $CACHE_DIR/album1/album2/image.jpg/{original,800x600,150x150-square}

Some Mojolicious upgrade must have broken the gallery program:

$ ./script/gallery prefork -H 300 -m production -l 'http://127.0.0.1:36366'
Route pattern "/*path" contains a reserved stash value at /home/schleierdav/sites/theschleiers.com/photos/gallery/script/../lib/Gallery.pm line 56.

where line 56 is the last line of this stanza:

my $router = $self->routes;
$router->get('/')->to('controller#route', path => '');
$router->get('/*path')->to('controller#route');

It might be the most recent Mojolicious update in pkgsrc, because I only noticed this today after my weekly update completed. I saw the system load was higher than usual, noticed there kept being a new perl process ID, and couldn't reach my gallery site (503 Service Unavailable, probably from my reverse proxy). Currently I have p5-Mojolicious-9.17 and -- yep, that looks like a big enough change -- last week I was on p5-Mojolicious-8.59.

This issue looks sort of like mine. This method looks related to whatever this is about. This commit shows the changes between 8.59 and 9.17.

My photo-sharing workflow used to be as simple as "mount the WebDAV folder and copy some images over". I'd like to get that back.

Apple devices have defaulted to creating HEIC images for a while now. But it seems browsers generally don't ship with HEIC support. What would you suggest users do to publish such images at present -- batch-convert to JPEG before adding to the gallery?

How involved would it be to teach gallery to handle HEIF in some useful way, perhaps by automating this conversion? I see a couple imlib2 plugins that might help. Another option might be to call out to ImageMagick (which can be linked with libheif) to do the conversion.

Generate cache files as temp files and rename them, to eliminate issues with e.g. the server being killed while a file is being copied.

make the local.css file not be in the repo

stream the album page, instead of waiting to render it, so load_album doesn't cause a mojolicious (or apache) timeout. also MOJO_INACTIVITY_TIMEOUT

figure out some way to make cache invalidation safer (i.e. so you don't accidentally delete the originals)

put 'cache_' in every file and directory name, so you can always be sure when you're looking at the cache?

turn this whole thing into a website generator? just build it on top of ikiwiki?