Subtle changes, bugs and feedback

Is it possible to get a more enlightening error message when people attempt to upload pictures larger than 3MB. A lot of mobiles have default camera pictures that are bigger than 3MB and "Internal Server Error" doesn't really give much clue as to what the problem is.

I've got a second text parser running that would linkify the URL in a pre-processor stage if it has the protocol on it.

I assume that's what was causing me trouble just now. It seemed to hang for about 5 mins before returning with a 500. Although that could be partly due to a poor connection.

A quick solution might be to just set nginx to reject large uploads?

Oh, is that the error? Must've had a regression since it was written as we originally said "image too large".

Though it occurs to me now that maybe I should stop caring.

I still need to guarantee a max size, by dimensions and resolution.... i.e. no bigger than 1200px wide or 1200px high... but maybe I don't care about keeping the original file at all? I mean, it's not like I promised that Microcosm was an image hosting service.

So perhaps the fix, rather than show the error message, is to allow all large image uploads but to automatically reduce the dimensions and/or resolution to bring it within a "good enough for the web" size. This would be least inconvenient to you all, and wouldn't use an excessive amount of resource for me.

this would be great. I screenshot and then crop on my phone to get image sizes down but offloading that work to you makes things easier.

Woah.

Did not realise anyone was doing things like this.

Yes, will make the change... however I'm going on holiday from tomorrow so this will likely be in a few weeks time.

My phone's pictures are about 6MB so I use an app, Reduce Photo Size, to reduce photo size to post on here which is a bit of a faff. Giving "messageboard-sized" images seems reasonable.

Well... I reckon it's probably reasonable to do this:

1. Configure nginx to accept 64MB or smaller
   
2. Configure the API to accept max dimension of 1920 px high or wide
   
3. Configure the API to accept max resolution of 132 dpi
   
4. If either the max dimension or the max resolution is exceeded then reduce to fit a 1920 box (but preserve aspect ratio) and reduce to 132 dpi
   
5. If either the image dimensions or dpi cannot be determined, then this is not a valid image and reject
   
   

On #5 this does mean that some PNG images may be rejected even though they are valid files. i.e. animated PNGs that use different colour palettes per frame.

Configure the API to accept max dimension of 1920 px

This is OK up to a point, but sometimes it's useful to be able to see images at original scale to zoom in on details, particularly in current projects if something looks awry and the builder doesn't seem to have caught it. I've been encouraging people to use the lfgss upload because all the other free image hosts suck so hard for various reasons and most people CBA to provide their own server.

Hmm.

Good point... let me go and check the cost of hosting images at the moment.

Maybe I should just up the file size? Super simple to do... just a question of cost.

LMAO.

The total cost for storing all of the attachments at the moment? £9.44 per month.

I'll just increase the file size for images.

I'll start by just making it 12MB. I'll see if I can do that this evening.

You use s3 don't you? Don't forget the data transfer costs will go up with bigger files...

I doubt many people share my image size considerations and reluctance to install extra apps on devices.

Reducing phone photo image size is a bit of a pain.

You use s3 don't you? Don't forget the data transfer costs will go up with bigger files...

We don't have a bandwidth charge from S3.

What I do instead:

1. Proxy S3 behind our app (long term durable storage)
   
2. Rename all files to their SHA1 hash
   
3. Serve all files from /api/files
   
4. Put an nginx file cache in front of /api/files (long term slow cache)
   
5. Put Cloudflare in front of nginx (short term fast cache)
   
6. Configure a Cloudflare Page Rule to cache everything
   
   

The only bandwidth we ever incur is the very first GET of a file after it's uploaded.

I really focused on this when our S3 cost became our biggest cost.

Now our Linode costs are our biggest costs (at just over £310 per month).

So it's just storage really... and that isn't so bad.

Ooh, this would be great. Thanks big man.

I've got it taking larger files.

Presently it's set to take 30MB.

This is in 4 places:

1. nginx on load balancers
   
2. nginx on web UI
   
3. web UI python
   
4. Go API
   
   • controllers/attachments.go
     
   • models/file.go
     
     

I've tested 5.7MB and it worked, and then tested for 29MB and that worked.

Huge files can be seen here: https://www.lfgss.com/conversations/253639/?offset=400#13663180

I have fixed the URLs not being linked within quoted text.

It did require changing the content of some 6 million comments across the 300+ sites... but oh well.

Though there is a catch, I couldn't fix existing comments with quoted text that wasn't linked... but I have made it so that future quoted text containing links does work.

I have fixed the URLs not being linked within quoted text.

Nice. I always worked around it by creating a link with the link feature of the forum, but this is better of course.

Best news ever

Yep. Tagging just got easier.

Thanks DK

Dunno if this is a bug or intended.

On mobile, but no reason to think any different on full browser.

On the following view, on any page number greater than 1.

The "Following" like k in the footer returns you to the first page of Following. The one on the top left refreshes the current page you are on.

The former is useful. The latter not so much.

By design.

The one at the top is the breadcrumb which is always contextual.

The one in the footer is just a hard link, predictable behaviour no matter which page you are on.

Fair enough