XF 2.2 Can we rebuild/resize image attachments after changing "Maximum attachment image dimensions"?

[mazzly]

Okay, so I realized we had an unlimited size set for "Maximum attachment image dimensions"...

Nowadays any phone easily uploads 4+ MB & 4000x3000px images when a forum user takes a photo of something...

Since we're not running a photo forum, we decided that a maximum of 1600x1600 would be feasible to still have high-quality images, without wasting storage/bandwidth resources...

I see that we can rebuild attachment thumbnails, but is there any option to "rebuild" the attachments so that the size limits are respected for already uploaded attachments? I understand that this is a non-reversible action once done...

 

[🔥Iggy🔥]

i think it might be best to try doing it more directly on the server level? imagick might even do it? if not im sure there are countless others.

 

[mazzly]

i think it might be best to try doing it more directly on the server level? imagick might even do it? if not im sure there are countless others.

The problem I see with doing something like that is that the AttachmentData entity stores a couple of other things like width, height, file_size and file_hash (which I'm not sure if it is a md5 hash of the actual file, or just a random hash)

Maybe @Mike @Chris D or @Kier have some input on this, as it seems I might have to write my own addon/xf:job to perform the resizing of existing images..

 

[Paul B]

It would require custom development.

There is only XFMG attachments resize built in.

 

[AndyB]

You might like this add-on:

https://xenforo.com/community/resources/resize-attachments-all.7280/

 

[mazzly]

@Paul B can you confirm if the file_hash must be an actual md5 hash of the file once we shrink it?

I see that core XF sets it with:

md5_file($file->getFilePath());

Another add-on I checked simply does the following when modifying the attachments:

md5(uniqid('xf', true));

Will it have some bad effects down the road if the filename doesn't have the correct md5 hash?

 

[K a M a L]

@Paul B can you confirm if the file_hash must be an actual md5 hash of the file once we shrink it?

No, hash is stored in attachment data table and you don't need to re-calculate or update it if you modify files

 

[mazzly]

No, hash is stored in attachment data table and you don't need to re-calculate or update it if you modify files

Hmm I'm then wondering why XF core sets it to the actual file hash, and not just any random hash...

 

[Chromaniac]

this might be completely irrelevant or inaccurate. once i tried shrinking an attachment directly on the server. xenforo did not load that file properly in post content. iirc it would only load the partial image file. made no sense tbh. but i reverted back the file to the original and it started loading properly.

 

[Kirby]

No, hash is stored in attachment data table and you don't need to re-calculate or update it if you modify files

That might be dangerous!

XF 2.2 - Is there a way to stop repeated/redundant attachment data? (taking up a lot of space)

I'm trying to find ways to free up space on my server and I first looked at the internal_data folder since it's so large. I noticed some attachments were repeated: same file_hash, so I downloaded the files and confirmed they are in fact exactly the same image. Sometimes users post the same...

xenforo.com

@MySiteGuy

While not strictly required, I'd recommend updating file_hash with the actual md5 hash.

But this might also cause issues if direct URLs (eg. image thumbs or video / audio) are shared / embedded in posts.