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

Screenshot 2023-10-11 at 00.59.50.png
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:
To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

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 🌎🪝
 
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.

 
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
Extremely dissapointing imo. My users uploaded 400GB of video in posts and I know the savings would be significant if xenforo utilised ffmpeg properly.
 
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
 
Last edited:
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
 
H

Image optimization with WebP support​

Arguably, we could have talked about this in our bumper Boosting performance entry but it wasn't quite ready to be shown at that point. (I started working on it this week and I haven't yet mastered the art of time travel).

Initially the scope of our WebP support in XenForo 2.3 was to merely allow users to upload WebP files and have them correctly displayed inline. This would have been a positive change on its own as the format becomes more prevalent across the web, but it doesn't really do much on its own to solve the issue of disk usage which, of course, then also has a positive effect on performance.

But, this wasn't enough.

View attachment 292273

If you wish to optimize, automatically, all future image uploads you simply need to enable this option.

On upload, all currently supported image types (except GIFs) will be saved to WebP format.
Side note: As is the case now, thumbnails, profile banners and avatars (and anything else that has a programmatically set file name) will be served with a .jpg extension, regardless of the underlying file format.

If you have custom content types which already use the attachment system, such as we do with Media Gallery and Resource Manager, images uploaded to those will be automatically optimized too.

In fact, if your add-on handles uploads via the default approach, namely the XF\Http\Upload class, all new image uploads will be optimized automatically. This extends out into pretty much every system we have, including the admin asset upload system.

As a developer, if you wish to opt-out of this behaviour for any reason, you can do so with the following one-liner:

PHP:
$upload->setImageOptimize(false);

That deals with future uploads, but, many of you will be wondering how to optimize existing files. So you'll be pleased to hear that you are able to rebuild all of your existing attachments, avatars and profile banners automatically.

View attachment 292274

These are somewhat typical rebuilds that you can kick off from within your admin control panel on the "Rebuild caches" page.

With this being a rather intensive and lengthy process, if you'd prefer to run this without the risk of browser timeouts and supervision, you can also use one of the built in commands:

Code:
xf-rebuild:attachment-optimization
xf-rebuild:avatar-optimization
xf-rebuild:profile-banner-optimization

As a developer, adding support for your own content types is trivial by extending the AbstractImageOptimizationJob class.

We have run this already on a development copy of the XenForo Community forum. In doing so, the file size reported via the xf_attachment_data table before the conversion was around 40GB. The file size reported after the conversion is around 19GB.

These are significant savings and will also have a positive impact on performance.

The "not so good" news​

WebP is now supported by every single major browser. Anyone using an up to date browser will not experience any issues with viewing images. However, certain Apple devices and browsers prior to September 2020 do not support WebP.

Specifically, if you are using iOS 14 or above, there is no issue at all. Safari 14 and above is great, too but you must be running at least macOS 11 Big Sur for WebP images to display.

In earlier browsers, these users will simply not see WebP images at all. They will appear as broken images.

As time progresses, this is naturally an ever decreasing issue as people update their software and hardware. But it is something you should be aware of and think about before blanket converting all images to WebP.
Hello,
I have 2.3 but ı cant upload webp
 
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
Same as a script I used for a video website clone, video was uploaded and a progress bar was shown, the video was uploaded and converted into MP4 by ffmpeg and even back then this was fast, 3 videos were created, a low res file something like 240p, 720 and HD put through flash player. The end result was the uploader does the waiting and it's good to go when posted. We had a queue set up also so it didn't try to convert 20 files at the same time, blowing up the small server.
 
Last edited:
AVIF support would be very welcome in XenForo. The format is now supported by all browsers (Microsoft Edge was the last one to join today). It was designed to replace WEBP completely. Please don't leave XenForo in the last decade.

Original request from August 2023:

 
I'm sure we'll add more comprehensive AVIF support before long, but client support is still catching up to WebP (87.4% vs. 96.7%), and server support requires PHP 8.1 at a minimum. Safari is the only browser engine available on iOS, unfortunately, and it's not an evergreen browser like the rest. Safari only gained partial support for AVIF in the last year, and mobile Safari still lacks support for animated AVIF.

Even WebP support excludes iOS<14 and Safari on macOS<11, which rules out some devices. While I can appreciate wanting to be on the bleeding edge, WebP strikes a better balance between support and performance for the time being.
 
@Jeremy P Can you guys at least add minimal AVIF support to 2.3? Like being able to upload files and set avatars/signatures? It really doesn't require much code (can already be hacked in). I suppose full support like converting existing attachments etc can wait, at least for those who have the server space.
 
While AVIF support is on our radar, right now we're pretty focused on some other improvements that we believe will have a broader impact. We will revisit this in the not-so-distant future.
 
went through the initial posts. not sure if this has been answered already. would there be an option to set quality/compression setting for webp conversion? thanks!
 
Regarding this:


I had been thinking all this time that this feature would only work on images that were proxied. Not sure if the language of the post has been updated or I just read something that wasn't there. Probably this phrase lol if the dimensions have been stored by the image proxy. I was posting a feature request to let admins proxy images till a certain size and let other images load directly. But I decided to test it out first. And I hotlinked an image and checked the code of the post. Image is not proxied but the dimensions are still present in code. So, from the looks of it, proxying images are not required for this feature to work? Kind of cheered me up a bit.
 
That's correct. Proxying images is not required for this to work.

The reference to image proxy here only pertains to rebuilding the embed metadata for existing content. For images we have already cached via the image proxy; we can just look at those files and determine the image sizes and store them so at least some of them can benefit from this feature right from the get go.
 
So, just curious. Would it be a good idea to let proxy cache all images on the forum for like a few weeks and then disable it. And that should sort of record image sizes for past hotlinked images on the forum?
 

Image optimization with WebP support​

Arguably, we could have talked about this in our bumper Boosting performance entry but it wasn't quite ready to be shown at that point. (I started working on it this week and I haven't yet mastered the art of time travel).

Initially the scope of our WebP support in XenForo 2.3 was to merely allow users to upload WebP files and have them correctly displayed inline. This would have been a positive change on its own as the format becomes more prevalent across the web, but it doesn't really do much on its own to solve the issue of disk usage which, of course, then also has a positive effect on performance.

But, this wasn't enough.

View attachment 292273

If you wish to optimize, automatically, all future image uploads you simply need to enable this option.

On upload, all currently supported image types (except GIFs) will be saved to WebP format.
Side note: As is the case now, thumbnails, profile banners and avatars (and anything else that has a programmatically set file name) will be served with a .jpg extension, regardless of the underlying file format.

If you have custom content types which already use the attachment system, such as we do with Media Gallery and Resource Manager, images uploaded to those will be automatically optimized too.

In fact, if your add-on handles uploads via the default approach, namely the XF\Http\Upload class, all new image uploads will be optimized automatically. This extends out into pretty much every system we have, including the admin asset upload system.

As a developer, if you wish to opt-out of this behaviour for any reason, you can do so with the following one-liner:

PHP:
$upload->setImageOptimize(false);

That deals with future uploads, but, many of you will be wondering how to optimize existing files. So you'll be pleased to hear that you are able to rebuild all of your existing attachments, avatars and profile banners automatically.

View attachment 292274

These are somewhat typical rebuilds that you can kick off from within your admin control panel on the "Rebuild caches" page.

With this being a rather intensive and lengthy process, if you'd prefer to run this without the risk of browser timeouts and supervision, you can also use one of the built in commands:

Code:
xf-rebuild:attachment-optimization
xf-rebuild:avatar-optimization
xf-rebuild:profile-banner-optimization

As a developer, adding support for your own content types is trivial by extending the AbstractImageOptimizationJob class.

We have run this already on a development copy of the XenForo Community forum. In doing so, the file size reported via the xf_attachment_data table before the conversion was around 40GB. The file size reported after the conversion is around 19GB.

These are significant savings and will also have a positive impact on performance.

The "not so good" news​

WebP is now supported by every single major browser. Anyone using an up to date browser will not experience any issues with viewing images. However, certain Apple devices and browsers prior to September 2020 do not support WebP.

Specifically, if you are using iOS 14 or above, there is no issue at all. Safari 14 and above is great, too but you must be running at least macOS 11 Big Sur for WebP images to display.

In earlier browsers, these users will simply not see WebP images at all. They will appear as broken images.

As time progresses, this is naturally an ever decreasing issue as people update their software and hardware. But it is something you should be aware of and think about before blanket converting all images to WebP.
awesome <3 thx
 
Ok. So, this is not a bug report or a feature request. Just posting what I noticed about the update about image dimensions in this thread! I was pretty excited about this feature, but it sort of does not work as I would have liked it to. But I can see why that would be hard to implement.

The good thing. Any third-party image you embed using the toolbar button gets the dimensions fetched so it works well. Attached images also of course get their dimensions fetched and they seem to load with some kind of progressive animation which looks nice.

What doesn’t happen. If you post a BBCODE of a third-party image and paste it in the editor… Dimensions are not fetched. One way around is to just use the replace image button on the image and press replace and it’s done! This step is kind of annoying to use tens of times a day as you cannot access it over the image. You have to scroll to the bottom of the image in editor to get the menu. I also do not like that Drop Image option comes as default lol. Andy has an addon to get rid of it so that’s nice.

I was hoping that turning on proxy feature for all images would somehow get XenForo to record dimensions of all images. That does not seem to happen. But still, pretty cool stuff!
 
Top Bottom