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 🌎🪝
 
Does the rebuild process change xf_attachment_data.file_hash?

Although users shouldn't do that, I am sure there could be a dozen posts when users embedded thumbnails via [IMG].

So if xf_attachment_data.file_hash ist changed, this would also change the URL of attachment thumbnails and break those embedded images.

If it is not changed but the files are modified, this could cause issues with deduplication.

Good question.
Also, the addresses of mp4 files...
 
Last edited:
Does the rebuild process change xf_attachment_data.file_hash?
Sorry for going off-topic.
If I manually add a watermark to all the images (data files of the script), the file's hash will change, and it won't match the hash in the database. Is this critical?
 
I modified just a few webp files on the forum, and I received a message from a user. They mentioned they have a 2013 MacBook with Safari, which doesn't support webp. They also mentioned that Apple no longer releases updates. What should I do? Will there be support for older formats in version 2.3, perhaps through picture/srcset?
 
Tbh up-to-date safari support more image formats like jxl compared to up-to-date Chrome. But yes. It's a problem in cases where people are either using safari on old macos or any browser on old iOS. 🫣
 
Tbh up-to-date safari support more image formats like jxl compared to up-to-date Chrome.
Yeah, it's a shame that JXL support was removed from Chromium and Firefox despite community protest :(

IMHO the format has so much potential, hopefully Apple market share can generate enough pressure to revert the decisions.
 

Enhanced image resizing​

[...]

Starting with XenForo 2.3, the "attachment manager" which powers the file upload system for things like resources, media gallery and other attachments, is now able to resize images before they reach your server.
The attachment manager uses flow.js, Froala insert image dialog doesn't (in 2.2).
Will client side image resizing also work with images inserted via Froala insert image dialog?

Which format will be send to the server, always the original image format?
If this is the case it could mean that the browser converts HEIC to JEPG, XenForo JS resizes that, sends it to the server - and XenForo PHP on the server might convert that to WebP?
 
Last edited:
Will client side image resizing also work with images inserted via Froala insert image dialog?
It's on our radar but a little tricky.

Which format will be send to the server, always the original image format?
If this is the case it could mean that the browser converts HEIC to JEPG, XenForo JS resizes that, sends it to the server - and XenForo PHP on the server might convert that to WebP?
We attempt client-side conversion and fall back to server-side conversion, except for GIFs where client-side conversion is not supported.
 
It's on our radar but a little tricky.
I am sure you will find a way.

To support our chunked uploads Add-on I ended up just bypassing Froala uploads (via Insert Video dialog) and routing everything through flow.js, a similar approach could work for Images as well.

While you are working on uploads the following kinda annoying bugs could be fixed as well:

We attempt client-side conversion and fall back to server-side conversion, except for GIFs where client-side conversion is not supported.
Hmm, yeah - that doesn't really answer my question ;)

Assuming a user with Safari 17.0 attempts to upload a 4000x4000 HEIC image while XenForo is configured for a maximum attachment size of 1920 x 1920 and to automatically covert to WebP.

What will be send to the server in this case:
  • A 1920x1920 JPEG
  • A 1920x1920 WebP
  • A 1920x1920 HEIC
  • A 4000x4000 HEIC
  • Smth. else?
?
 
To support our chunked uploads Add-on I ended up just bypassing Froala uploads (via Insert Video dialog) and routing everything through flow.js, a similar approach could work for Images as well.
Yeah we're looking at just routing everything through the attachment manager.

Hmm, yeah - that doesn't really answer my question ;)
It does, but to be clearer we attempt WebP conversion client-side prior to upload. So, a 1920x1920 WebP.
 
The first step is to use the AssetVariantTrait in your Entity which has one required method to implement:

PHP:
public function getAssetVariantSizeMap(): array
{
return [
'image_url' => [
's' => 128,
'm' => [512, 456]
]
];
}

[...]

HTML:
<img src="{{ base_url(asset_display($entity, 'image_url', 's')) }}" />
Am I right to assume that there are also changes to <xf:assetuploadrow /> ?
 
Only a subset, as the full set bloats the JS from 18kb to 70kb and we only use 9 values in XFMG. We can consider unbundling the library to make it easier for add-ons to swap in a build with a bigger set if it's an important use case, but we're unlikely to ship more ourselves.
Just circling back to this one.... any subsequent thoughts about letting the full EXIF be captured for add-ons that use it?

If not, will the client side processing be something we can disable so we can carry on using the same as currently?

I'm looking forward to playing with 2.3, just have some hesitation about losing add-on functionality of capturing EXIF.
 
Not yet, but we'd likely just take the approach I outlined where add-ons are free to swap in a build of the library with a bigger set. 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").
 
Top Bottom