XF 2.3 Image optimization, enhanced image resizing, and more!

We hope you're enjoying the "Have you seen...?" series for XenForo 2.3 so far. We still have quite a bit more to show you while we work on adding the last finishing touches before we unleash XenForo 2.3 on this very forum.

This week we're going to talk about various improvements we have made which are mostly focused around images.

Check out the index below to skip to a specific post:

• Image optimization with WebP support
• Enhanced image resizing
• Use any emoji for smilies and reactions
• Size variants for the admin asset uploader
• Tracking sizes for embedded images

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

While that is all for this week, we continue next week! We will be focusing on only a single new feature next week, it is a doozy and we're excited to hook you even further into the exciting world of XenForo 2.3

 

[Kirby]

We don't have a built-in option to disable client-side processing, but it is a simple toggle on the attachment manager (data-resize-images="false").

IMHO an option to entirely turn this off (and probably have this off by default for upgrades) is a must have.

Otherwise customers who have not read this info might just upgrade and notice after some time that previously available EXIF data is no longer recorded for new uploads and there is no way to recover this (without applying the mentioned template-modification and re-uploading the affacted images).

So I would consider this a serious data-loss regression.

Ideally there should be fine-grained control where to apply client-side processing, eg. some admins might be okay with that for attachments in posts, but would like to have full EXIF data for gallery uploads.

Add options to control client-side image processing

XenForo 2.3 will add client-side image processing. What does this mean? If XenForo is set up to only accept images with a maximum dimensions or to automatically convert uploaded images to WebP the client (browser) will resize the image and convert it to WebP before it is sent to the server. In...

xenforo.com

 

[D.O.A.]

No love for video files? I would expect ffmpeg support by this time in posts but it seems to be ignored again. Video is a major part of any social website

 

[Jake B.]

No love for video files? I would expect ffmpeg support by this time in posts but it seems to be ignored again. Video is a major part of any social website

It's been a suggestion for ages, not sure why it hasn't have been implemented since it's already supported through XFMG anyways

 

[D.O.A.]

It's been a suggestion for ages, not sure why it hasn't have been implemented since it's already supported through XFMG anyways

Extremely dissapointing imo. My users uploaded 400GB of video in posts and I know the savings would be significant if xenforo utilised ffmpeg properly.

 

[Kirby]

It's been a suggestion for ages, not sure why it hasn't have been implemented since it's already supported through XFMG anyways

I assume it is not implemented because it is problematic:
Let"s assume a user attaches a HEVC/H.265 video to a post and immediately wants to submit the post

This video needs to be transcoded (as H.265 is not natively supported on a browsers) but transcoding does take time.

So what would you want to do?

1. Block submission of the post until transcoding has finished. Drawback: Annoying for the user and might take too long (user gives up)
2. Immediately accept post submission but delay making it visible (and send notificstions, etc.) until transcoding has finished; use original timestamp. Drawback: Might take some time until the post appears, if further posts have been made in between the video post might get overlooked
3. Immediately accept post submission but delay making it visible (and send notificstions, etc.) until transcoding has finished; use timestamp when transcoding finishes. Drawback: Might take some time
4. Immediately accept the post with the original video, replace video when transcoding has finished. Drawback: Users might see the original video but might not be able to watch it leading to complaints

If you have an idea how to support transcoding for videos in posts without those drawbacks please let me know

Supporting transcoding in XFMG is a lot easier as the video is the content and not just an attachment

 

[Jake B.]

Immediately accept post with the original video, replace video when transcoding has finished. Drawback: Users might see the original video but might not be able to watch it leading to complaints

Compared to the alternative of it accepting the post and users might not be able to watch it ever, also leading to complaints? I definitely think that would be better, yes. And considering it'd know the state it could say that it's still being processed and that it may not be able to play on some devices. Is it less than ideal? Sure, but it's better than the current state where you could upload a video that some users can literally never play