XF 2.3 What's new for developers in XenForo 2.3?

As promised, this week we're going to take a quick look at some of the more developer-centric changes coming in XenForo 2.3.

If a certain topic interests you more than others, click one of the links below:

• JavaScript
• SwiftMailer to Symfony Mail
• Doctrine Cache to Symfony Cache
• Updated Emogrifier
• Registry preload event
• Native IP conversion methods
• Support for class strings
• Updates to <time> tags - short date format
• Template names in HTML output
• AbstractCollection nth method
• Smart Javascript cache buster
• XF.createElement
• Template macro syntax changes
• Direct messages

Please note that the following libraries are no longer bundled with XF 2.3:

• ccampbell/chromephp
• doctrine/cache
• league/flysystem-ziparchive
• swiftmailer/swiftmailer
• symfony/debug
• web-token/jwt-signature-algorithm-eddsa
• web-token/jwt-signature-algorithm-hmac
• web-token/jwt-signature-algorithm-none
• web-token/jwt-signature-algorithm-rsa

While we do have a little more to show you, the next couple of weeks is going to be focused on getting XenForo 2.3 ready to be installed here and some additional "Have you seen...?" posts may arrive between then and a public beta release. Until then, thanks for coming on this journey with us.

 

[Jeremy P]

While including jQuery may significantly reduce the number of changes required, it still wouldn't be fully compatible in many cases because our own JS API no longer accepts or returns jQuery objects or includes custom jQuery functions/plugins.

 

[cwe]

QR code generation​

We include a QR code generation library mostly for aiding the setup of TOTP as a two-factor authentication method. ...

Will this allow us to display custom user fields as QR codes?

 

[Jeremy P]

Not out of the box (this thread is aimed at add-on developers), but the library enables developers to generate arbitrary QR codes. A similar library is already bundled in previous versions so this isn't really new functionality.

 

[NDavid]

Would there be updates on Font Awesome?

 

[Jeremy P]

No: https://xenforo.com/community/threads/when-will-we-get-fontawesome-6-support.207148/

 

[Kirby]

Template macro syntax changes​

[...]

<xf:macro name="m" /> ➡ <xf:macro id="m" />​

[...]

<xf:macro template="t" name="m"> ➡ <xf:macro id="t::m" />​

This also affects template extensions.

While I understand the reasoning for these changes and I think it's generally a good idea I already hate this change with passion - it breaks tons of template modifications

 

[Gene Steinberg]

My concern is whether large number of add-ons will be incompatible. Not every add-on out there is still being developed, but provides useful and sometimes mission-critical functions to board owners without any current options. (AddOnFlare) Paid Registrations for example. I hope this is being factored into the code changes so only a small number of problems will result.

 

[cdub]

(AddOnFlare) Paid Registrations for example. I hope this is being factored into the code changes so only

Yes I will need to find an alternative to paid registrations before upgrading... But considering how many add-ons I have that also need to be updated it'll be a while. Honestly I'm in no rush whatsoever though. 2.2 is working great.

 

[Gene Steinberg]

I have two forums that don't require that add-on. So maybe I'll upgrade them.

But I don't see why another developer isn't taking over Paid Registrations, and the only other option that has potential doesn't support PayPal or existing upgrades. I'd think there's an audience for such an add-on. Some of us can't live without.

 

[Paul B]

I hope this is being factored into the code changes so only a small number of problems will result.

While third party developers are considered when developing new versions, XF will do what is best for the long term when it comes to development, even if that means introducing BC breaks.

As always, the onus is on the developers to update their add-ons and styles to work with the latest version, and on you to ensure you have compatible versions installed.

 

[Gene Steinberg]

Well if most developers upgraded be compatible, no problem. I assume they will.

But not when there is no alternative to a product no longer developed.

 

[Ozzy47]

We have also deprecated the <xf:macro template="template-name" name="macro-name" /> syntax, in favour of id="template-name::macro-name" format, which again assists with the ability to see a sensible outline of the structure.

We can still use syntax like this in our addons <xf:macro template="myaddon_this_macros" name="username_row" /> without any issues to accommodate backwards compatibility?

 

[Jeremy P]

You can, though support for this syntax (among other deprecations) may be removed in XF 3.

 

[Ozzy47]

Hmmmm

 

[Jeremy P]

I think template modifications can be updated to support either syntax, after which you could switch to the newer syntax. It’s likely many templates will have to be at least partially rewritten for XF 3 anyway.

 

[Ozzy47]

Possibly, but that's double and triple the work. It might be easier to just drop support for anything below 2.3

 

[Newsman]

So I'm a bit confused: XF.proxy doesn't need an event - yet the suggested replacement is XF.on which requires an event like 'click' etc.

I have to be missing something; how can I proxy a function without having to mention any events?

 

[NikitOS]

@Newsman, you need to bind the function that needs to be called as a callback. For example:

XF.on(target, 'click', this.onClick.bind(this));

 

[Chris D]

Probably better as a discussion in the XenForo development discussions forum if you need more help after this point.

It's probably best if you provide details of what you're trying to do (in a new thread if needed). We are not suggesting XF.on() as a replacement for XF.proxy(). These are two different things.

This is the example from the original post:

XF.on(form, 'reset', this.formReset.bind(this))

The exact code this is replacing from XF 2.2/jQuery is:

$form.on('reset', XF.proxy(this, 'formReset'));

on is used to listen for a specific event on an element. XF.on(el, 'event') replaces $el.on('event').

What XF.proxy() was used for previously is binding the this object. The reason to do that is because by default functions passed into event listeners lose the this context, and this would usually refer to the element itself.

This is all a very long way of saying that the replacement for:

XF.proxy(this, 'formReset')

Is actually:

this.formReset.bind(this)

 

[Newsman]

This is all a very long way of saying that the replacement for:

XF.proxy(this, 'formReset')

Is actually:

this.formReset.bind(this)

This is what I've been looking for - but it doesn't seem to work for me (unless I put it in a setTimeout wrapper) which is probably due to my code. Either way, thanks for the quick and detailed explanation!!