XF 2.3 Miscellaneous changes for XenForo 2.3

Due to time constraints and family matters, this is a slightly different HYS to what was planned, but it is still a bumper feast of new features coming in XenForo 2.3. This week we will be mostly focusing on a bunch of smaller new changes and improvements we're no less excited to show you in the near future.

This is a somewhat lengthy post so we will say goodbye here and we will see you for more 2.3 goodies next week.

Sign in with Apple​

To join our existing suite of connected account providers, in XenForo 2.3 we are adding support for Sign in with Apple. The set up for this one will be a little more onerous, requiring an Apple developer account and the creation of a certificate file that will need to be uploaded through our UI:

hys_6_apple_1.png


Before release, we will be documenting the full setup process through the XenForo manual. There is also an additional step required for users who sign up with Apple's "Hide my e-mail" feature.

Once enabled, users will be able to sign in, or sign up with the Apple button in the relevant places.

hys_6_apple_continue.png


Search users for connected accounts​

If you've ever wondered which of your users have which connected accounts connected, you can now pull that list directly from the "Search users" page in your admin control panel.

hys_6_user_search.png


Simply select the specific connected account(s) you want to search for, and the list of users who have those accounts connected will be displayed.

IndexNow support​

In XenForo 2.3 you can now enable support for IndexNow. This is a recent initiative by Bing, Yandex and others, which allows you to directly notify them whenever content is created, updated, or deleted on your forum. Whenever one of these events happens, a job is enqueued to submit the URL to IndexNow. This avoids the need for generating huge sitemap files which may or may not be read by search engines.

Due to limited support by search engines, including Google, the sitemap generation remains in place and remains unchanged, but IndexNow is available for those search engines which support it either now or in the future.

Generically queued and retryable jobs​

Starting with XenForo 2.3, the existing job system has been enhanced with additional tracking which allows it to be used as a generic queueing system. In XenForo 2.2, mails are added to a special queue table before being processed. This functionality remains largely unchanged, but instead of queueing mails to be sent in their own table, they are now queued directly into the xf_job table.

It's not just mails which are queued in this way. The sending of push notifications and webhooks are also now queued into the job system, so there is little to no noticeable delay when submitting content which might generate one or more of these to be sent.

In addition to queueing these items in this way, developers can also opt in to having their jobs be retryable in the event of failure. This maintains the current behaviour of the existing mail queue and also allows webhooks to be retried in the event of failure.

The cool off between retrying can be configured directly in the Job class or use sensible defaults so that the delay between retries is lengthened based on the number of previous attempts.

After a certain number of failed attempts, the jobs can be marked as failed and they are stored in a new xf_failed_job table.

Bundled support for remote object storage​

Thanks to some changes in the AWS SDK for PHP we are now able to ship, alongside XenForo, the parts of the library which are responsible for communicating with Amazon S3 and compatible object storage services.

The setup instructions provided by the below resource are still required:

But starting with XenForo 2.3 you will no longer need to install an "add-on" in order to configure it. Calling it an "add-on" is a little bit of a misnomer as all it really does is include the (previously) humongous AWS SDK. Now we can include just the Amazon S3 SDK parts, there are fewer steps required to offloading your storage to a remote service, like Amazon S3, Cloudflare R2 and many others.

Full InnoDB support with improved MySQL search​

In days gone by, there were good reasons for our continued use of MyISAM and MEMORY tables in MySQL. Though as the years have progressed, the need for these storage engines in databases have long been negated by better hardware performance and improvements in InnoDB.

Starting with XenForo 2.3 we are automatically converting most of the remaining tables to use InnoDB and for new installs we are making all tables use InnoDB by default.

The only table that requires manually converting is the xf_search_index table. For existing installations, due to differences in the full-text search implementation, you will need to run a CLI command named xf:convert-search-innodb, which will empty, convert and optionally rebuild the search index for you.

Full text search using InnoDB should be an improvement right out of the gate as it offers a lower default minimum word length and a much smaller set of stop-words, along with an improved scoring algorithm. We now even support relevancy search order out of the box, something that was previously a XenForo Enhanced Search exclusive feature, though this will be subject to real world testing before we can comment on whether it is useful.

Due to these changes we are going to be requiring a minimum of MySQL 5.7 or MariaDB 10.2 starting with XenForo 2.3.

Native 'sticky' and date/time inputs​

Due to ancient browser quirks which should no longer be relevant and improved HTML standards, we are now handling sticky elements and date inputs natively without the use of third party libraries.

In terms of 'sticky' support, this affects mostly the admin control panel navigation and the sticky header on the public side in some legacy cases. For the most part, you shouldn't see any difference and the experience, particularly for the admin control panel navigation, should be a lot less janky in some of the cases.

Date inputs within XenForo have now been replaced with native date inputs, rather than using a third party library. Each browser/OS will render the date picker slightly differently, as seen below (Chrome, Firefox, macOS Safari and iOS pictured):

hys_6_date_chrome.png
hys_6_date_firefox.png
hys_6_date_safari.png
hys_6_date_apple.png

But all of them are at least much more functional than they used to be and will be familiar to people who have used the date inputs before.

In addition to supporting date inputs with the existing <xf:dateinput> tag, we also support date and time inputs with the <xf:datetime> tag and time inputs using the <xf:timeinput> tag, which correspond to the HTML standard <input type="date">, <input type="datetime-local"> and <input type="time"> tags respectively.

Auto refresh "board inactive" page​

For those times when you need to turn your forum off, you will have used the "board is active" toggle to do so. This page will now automatically refresh every 60 seconds so when the forum is back up, people will be back using your site sooner without needing to hit refresh.

Anchor links for headings​

Every time a heading is used within content, it now has an automatic anchor link generated which can be accessed on hover via the link icon that appears next to the heading:

hys_6_heading.png


This will allow you to link directly to headings within your content.

Email notifications for moderators​

Sometimes it can be tricky keeping up to date with the various goings on with a busy forum, or if you're a small team, sometimes it can be difficult to respond to various moderator tasks.

To make that easier in XenForo 2.3, moderators can now opt-in to email alerts for new reported content or new content awaiting approval,

hys_6_moderator_emails.png


With these preferences enabled (on a per-moderator basis under account preferences), whenever any of those actions require attention, an email will be sent to those moderators.

User ID matches expression​

New for 2.3 is an addition to the user criteria selector that allows CSS-style :nth-child selectors against user IDs. While this might initially sound like gobbledygook, there is a powerful application for this tool.

1698099926187.png


Let's imagine that you have a user group promotion that grants access to a 'Testing group' user group, and applies to all users with a 2n value for 'User ID matches expression. This promotion will apply to any user whose user ID is even. You can then enable specific functionality for users in the 'Testing group', and use various tools to measure their engagement with those tools, compared to those not in that group who do not have access to the changed functionality. In short, you have a quick and easy way to do A/B testing on your entire user base.

Of course you don't have to limit your testing to one group. You could set up 3n, 3n+1 and 3n+2 criteria on three separate promotions to divide your user base into three groups, or set up segregation however you like.
 
Last edited:
For existing installations, due to differences in the full-text search implementation, you will need to run a CLI command named xf:convert-search-innodb, which will empty, convert and optionally rebuild the search index for you.
Interested in knowing how to do it, a simple guide would be helpful to me (us).
 

Email notifications for moderators​

Sometimes it can be tricky keeping up to date with the various goings on with a busy forum, or if you're a small team, sometimes it can be difficult to respond to various moderator tasks.

To make that easier in XenForo 2.3, moderators can now opt-in to email alerts for new reported content or new content awaiting approval,
Nice :)

Is there any chance to expand this to Alerts (including Push Notifications) as well and not just emails?
This would allow us to get rid of another bunch of custom code :)

E-Mails are nice but push notifications are much more vibrant, especially for reported / approval awaiting content.

 
Last edited:
Nice :)

Is there any chance to expand this to Alerts (including Push Alerts) as well and not just emails?
This would allow us to get rid of another bunch of custom code :)

E-Mails are nice but push alerts are much more vibrant, especially for reported / approval awaiting content.

Not sure I understand the "lying" emoji. But I agree, I think we can review that, and consider adding push notification support here.

This is where they'd talked about this before. :)
 
This will allow you to link directly to headings within your content.
Awesome!!!
Will you please add a Table of Content bbcode or function, so that we link to chapters in articles?
This would be used a lot.
 

Sign in with Apple​

Why was this approach chosen?
https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api There is a rest
This functionality remains largely unchanged, but instead of queueing mails to be sent in their own table, they are now queued directly into the xf_job table.
Can you see what it will look like now?
The cool off between retrying can be configured directly in the Job class or use sensible defaults so that the delay between retries is lengthened based on the number of previous attempts.
What would the implementation of such an interface look like?
 
They're still listed as moderators, and still help out a little, but they definitely won't be wanting to get emails.
They are disabled by default.

2) I really appreciate the moderator emails for content requiring approval.

What about new users requiring approval or username changes requiring approval? My site would greatly benefit from these email notifications as well.
It’s for anything requiring approval.


Interested in knowing how to do it, a simple guide would be helpful to me (us).
it will be in the manual, but running commands is a common thing that already exists.

Nice :)

Is there any chance to expand this to Alerts (including Push Alerts) as well and not just emails?
This would allow us to get rid of another bunch of custom code :)

E-Mails are nice but push alerts are much more vibrant, especially for reported / approval awaiting content.
Yeah have been speaking to @Naz who took the point on this one.

Awesome!!!
Will you please add a Table of Content bbcode or function, so that we link to chapters in articles?
This would be used a lot.
Not for 2.3


We are using the REST API, I didn’t comment on the approach we took.

It’s not using their JS framework. It integrates with connected accounts as all others do


Can you see what it will look like now?
It’s basically the same but has a field containing the number of attempts.


What would the implementation of such an interface look like?
It’s just a trait called Retryable. You can adjust the behaviour, such as cool offs, by extending a method. There’s a few methods to indicate that the job should be retried rather than resume or complete. There’s a new fail method for when you want a job to fail immediately.
 

Generically queued and retryable jobs​

Starting with XenForo 2.3, the existing job system has been enhanced with additional tracking which allows it to be used as a generic queueing system. In XenForo 2.2, mails are added to a special queue table before being processed. This functionality remains largely unchanged, but instead of queueing mails to be sent in their own table, they are now queued directly into the xf_job table.

It's not just mails which are queued in this way. The sending of push notifications and webhooks are also now queued into the job system, so there is little to no noticeable delay when submitting content which might generate one or more of these to be sent.

In addition to queueing these items in this way, developers can also opt in to having their jobs be retryable in the event of failure. This maintains the current behaviour of the existing mail queue and also allows webhooks to be retried in the event of failure.

The cool off between retrying can be configured directly in the Job class or use sensible defaults so that the delay between retries is lengthened based on the number of previous attempts.

After a certain number of failed attempts, the jobs can be marked as failed and they are stored in a new xf_failed_job table.

This bit seems like it could cause issues, if it queues every email as a separate job, and something happened that triggered a few thousand emails to be sent wouldn't that block any other jobs from running until all of those emails have sent? Currently the mail queue job has a limit on how long it can run, and then it gets queued again so the other jobs that were added are able to run before it's triggered again. Seems like this could potentially cause a substantial delay for other jobs
 

Anchor links for headings​

Every time a heading is used within content, it now has an automatic anchor link generated which can be accessed on hover via the link icon that appears next to the heading:

hys_6_heading.png


This will allow you to link directly to headings within your content.
Great feature. Can you give us an example of the format of a URL or anchor tag hash that's linking to a heading within a user's content?
 
Last edited:

Generically queued and retryable jobs​

Starting with XenForo 2.3, the existing job system has been enhanced with additional tracking which allows it to be used as a generic queueing system. In XenForo 2.2, mails are added to a special queue table before being processed. This functionality remains largely unchanged, but instead of queueing mails to be sent in their own table, they are now queued directly into the xf_job table.

It's not just mails which are queued in this way. The sending of push notifications and webhooks are also now queued into the job system, so there is little to no noticeable delay when submitting content which might generate one or more of these to be sent.

In addition to queueing these items in this way, developers can also opt in to having their jobs be retryable in the event of failure. This maintains the current behaviour of the existing mail queue and also allows webhooks to be retried in the event of failure.

The cool off between retrying can be configured directly in the Job class or use sensible defaults so that the delay between retries is lengthened based on the number of previous attempts.

After a certain number of failed attempts, the jobs can be marked as failed and they are stored in a new xf_failed_job table.
retryable jobs for Failed Push Notifications will be nice.

developers can also opt in to having their jobs be retryable in the event of failure. This maintains the current behaviour of the existing mail queue and also allows webhooks to be retried in the event of failure.
This is super nice and will come in very handy for several custom addons (and for Pickem related to auto picks, reminders and survivor eliminations).

The cool off between retrying can be configured directly in the Job class or use sensible defaults so that the delay between retries is lengthened based on the number of previous attempts.
This is awesome.

After a certain number of failed attempts, the jobs can be marked as failed and they are stored in a new xf_failed_job table.
About time! I've been wanting this for years!!!
 

Email notifications for moderators​

Sometimes it can be tricky keeping up to date with the various goings on with a busy forum, or if you're a small team, sometimes it can be difficult to respond to various moderator tasks.

To make that easier in XenForo 2.3, moderators can now opt-in to email alerts for new reported content or new content awaiting approval,
Has it really been 13 years I've been waiting for this? When did I get so old? 😭😭😭

🤣🤣🤣
 
This bit seems like it could cause issues, if it queues every email as a separate job, and something happened that triggered a few thousand emails to be sent wouldn't that block any other jobs from running until all of those emails have sent? Currently the mail queue job has a limit on how long it can run, and then it gets queued again so the other jobs that were added are able to run before it's triggered again. Seems like this could potentially cause a substantial delay for other jobs
By the time we release, this shouldn't be an issue. We've got plans in place to mitigate that.

retryable jobs for Failed Push Notifications will be nice.
The PushSend job isn't currently marked as Retryable though we think that might be an oversight, so that should be in place in due course.

This is awesome.
Mostly for the benefit of @kick who asked earlier, but this is what the default logic for cooling off retryable jobs looks like:

PHP:
    protected function calculateNextAttemptDate(int $previousAttempts): ?int
    {
        switch ($previousAttempts)
        {
            case 0: $delay = 5 * 60; break; // 5 minutes
            case 1: $delay = 10 * 60; break; // 10 minutes
            case 2: $delay = 20 * 60; break; // 20 minutes
            default: return null; // give up
        }

        return time() + $delay;
    }

You can override this and apply your own retry logic. This is what we do with the MailSend job:

PHP:
protected function calculateNextAttemptDate($previousAttempts): ?int
{
    switch ($previousAttempts)
    {
        case 0: $delay = 5 * 60; break; // 5 minutes
        case 1: $delay = 1 * 60 * 60; break; // 1 hour
        case 2: $delay = 2 * 60 * 60; break; // 2 hours
        case 3: $delay = 6 * 60 * 60; break; // 6 hours
        case 4: $delay = 12 * 60 * 60; break; // 12 hours
        default: return null; // give up
    }

    return time() + $delay;
}

Making use of retryable jobs is as easy as applying the use Retryable trait. There are no required methods so it basically works magically. This trait contains the attemptLaterOrComplete method which counts the previous attempts, calculates the next attempt date, and either requeues the job for later or completes it.
 
By the time we release, this shouldn't be an issue. We've got plans in place to mitigate that.
Hopefully there's some sort of job priority you can set. An email newsletter queued to 1,000,000 users was already problematic with it blocking emails that are more immediately important (like a password reset email), but now it also potentially blocks other non-email jobs.

I'm sure you guys have it worked out, but it would be nice to just have a priority system so someone could send an email newsletter (or other jobs that aren't time sensitive) to the job queue in a way that they only run when there's nothing else to run.
 
Hopefully there's some sort of job priority you can set. An email newsletter queued to 1,000,000 users was already problematic with it blocking emails that are more immediately important (like a password reset email), but now it also potentially blocks other non-email jobs.

I'm sure you guys have it worked out, but it would be nice to just have a priority system so someone could send an email newsletter (or other jobs that aren't time sensitive) to the job queue in a way that they only run when there's nothing else to run.
Funny you should say that but that is basically the solution @Naz has been planning (it was noted down but didn't make it to the backlog)

1698160496319.webp
 
Gosh this is cool!
We're going to have the coolest software features in 2.3
Have you got a potentional release date in mind?
 
Top Bottom