XF 2.1 Push notifications

Welcome to the first of our "Have you seen...?" series for XenForo 2.1. We've got a lot to show you over the course of the next few weeks so you may well be hearing from us quite frequently... To ensure you're kept up to date, we strongly recommend clicking the "Watch forum" link here and enabling email notifications if you haven't done so already 🙂

But first...

The first thing that we should announce before we get started is something which we have talked about over the last year which is related to the minimum server requirements of XenForo 2.1. XenForo 2.0 currently requires a minimum of PHP 5.4, but with XenForo 2.1 we are increasing this to a minimum of PHP 5.6. Now, PHP 5.6 is still pretty old by today's standards, so you may be interested to understand why we have settled on that as our new minimum PHP version.

The answer is fairly simple, in that we are essentially trying to strike a balance between the features in PHP that we need to use, the requirements of third-party packages that we include with XenForo, and ultimately the common PHP versions that customers are using on their servers. Since XF 2.0.2 we have been keeping track of this, and these are the current results:

1539019830210.webp

To the one customer who is running PHP 7.3 Alpha I sincerely hope you are doing so in a test environment 😉
As you can see, it seems like a fairly safe bet for us to consider leaving behind PHP 5.4 and PHP 5.5 as that amounts to only 6.5% of the total customer base. One could argue that PHP 7.0 would be an ok target too as the total PHP 7.x usage is at 55.3% but leaving behind a total of 44.7% of the total customer base seems unreasonable at this point. We'd strongly recommend everyone consider upgrading to PHP 7.2 as soon as possible.

That all said, we have mentioned previously that there is one feature which will require a minimum version of PHP 7.1 to use...

Push it real good...

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
Sorry, I couldn't help myself! 🙂

That's right, we're kicking off our XF 2.1 series of HYS threads by announcing that our most popular suggestion is implemented! Let's first look at how to set it up.

1539022286792.webp

If the above browser/device requirements are frustrating then please direct your complaints to @WebKit on Twitter!

So, yes, first and foremost, you will need PHP 7.1 to enable this functionality. This enabled us to implement the functionality in a way that is compatible with as many browsers as possible, including Microsoft Edge on Android and Windows.

In addition to this, your site must be running over HTTPS with a valid SSL certificate, and you must have support for the GMP extension.

Unfortunately for reasons beyond our control (read: it's Apple's fault) the list of supported devices/browsers notably exclude Safari on macOS and any iOS-based browser. This functionality is made possible by making use of a number of APIs including the Push API and Notification API which most browsers support already.

On supported devices, the process looks something like this:

21push1.gif

You can also see that, just like alerts, we have provided a mechanism for you to be able to opt out of receiving certain push notifications. You may want to get forum alerts for everything, but only be notified by your browser for the things you find important.

The content of a push notification will be a slightly stripped down version of the default alert template. A brief note for developers; although there is code which will automatically convert HTML to a text-only version of the notification, the preferred method would be to create specific push template for each content type and action, and these will look similar to this:
HTML:
{{ phrase('x_quoted_your_post_in_thread_y', {
   'name': $user.username ?: $alert.username,
   'title': prefix('thread', $content.Thread, 'plain') . $content.Thread.title
}) }}
<push:url>{{ link('canonical:posts', $content) }}</push:url>

As you would expect with push notifications, you do not necessarily need to be viewing the forum when the notification is received, nor does the browser even need to be active, as demonstrated here:

21push2.gif

Naturally, clicking on the notification will take you straight to the content.


Alert read marking

Going straight to the content from wherever you are on your device is certainly convenient, but given that push notifications essentially represent forum alerts, it would be somewhat inconvenient to have to mark those as read too.

Therefore when you now visit content which you have previously been alerted to, the corresponding alert(s) will now be automatically marked as read.


"But I have an Apple device, will you support push notifications another way...?"

Unfortunately, this is unlikely. Although Apple devices represent a significant number of mobile users, the current approach other browser vendors are taking is standardised (meaning Apple devices could be nearly automatically supported in the future), free and seamlessly integrated with your browser. Any other approach, be that a separate app, or a third party service would, frankly, be a sub-par (and potentially expensive!) experience.

The overall solution is simple, but it is down to Apple/WebKit to take on board and implement. According to the WebKit Feature Status page, if there are any features missing you can reach out to @webkit on Twitter or contact the webkit-help mailing list. Consider doing that today to help them understand why push notifications are important for your forum 🙂


And, sadly, that brings the first HYS for XF 2.1 to an end! But don't worry - as mentioned earlier we have lots more to get through 🙂 And we may well see you for that fairly soon 😉
 
Last edited:
Again, it would be a browser update that would be required to solve most anticipated issues. We rely on a third party library and that may have its own issues but then they can be addressed with XF updates if needed.

@Chris D are there any performance degradation when a large number of people subscribe to notifications and a popular thread is "liked" hence multiple instance of notification is fired off to the end user.

OneSignal and its XF2 plugin suffers from this quite badly. I end up turning off the "like" notification in the onesignal notification section
 
@Chris D are there any performance degradation when a large number of people subscribe to notifications and a popular thread is "liked" hence multiple instance of notification is fired off to the end user.

OneSignal and its XF2 plugin suffers from this quite badly. I end up turning off the "like" notification in the onesignal notification section
I need to double check but technically the notifications are sent in as few HTTP requests as possible.

Even so, the XF Notifier framework batches most alerts out into the Job system.

If content is generating a significant number of likes then it’s possible that could have an impact as it would be a new HTTP request for every alert but future approaches could mitigate that.
 
I need to double check but technically the notifications are sent in as few HTTP requests as possible.

Even so, the XF Notifier framework batches most alerts out into the Job system.

If content is generating a significant number of likes then it’s possible that could have an impact as it would be a new HTTP request for every alert but future approaches could mitigate that.

This is what I wanted to hear, that alerts are being sent in batches and UX isn't being impacted.

Great work guys :)
 
No such thing is required because customers don’t need tomprovision a Firebase account to use this feature. That’s managed entirely by the browser vendor. Again, it would be a browser update that would be required to solve most anticipated issues.
When I say Firebase, I'm referring to Firebase Cloud Messaging, which replaced Google Cloud Messaging, and for older versions of Android particularly those without the browser update that include VAPID support, an account is required for a FCM/GCM sender ID.

"If they don't update the mobile browser, that's their problem", in practice, does not work out well, particularly for boards in non-western countries.
@Chris D are there any performance degradation when a large number of people subscribe to notifications and a popular thread is "liked" hence multiple instance of notification is fired off to the end user.

OneSignal and its XF2 plugin suffers from this quite badly. I end up turning off the "like" notification in the onesignal notification section
Every OneSignal implementation I've seen simply didn't develop a solution for performance and it's why a lot of people uninstalled it.

After a lot of trial and error, the fastest and best performing system I came to was timestamp-ascending queue limit (500 +/- messages to remote push server p/m, adjustable for server capability) + remote deferred.php trigger every minute + batch requests.

Without the queue limit, boards can choke up from a spike in activity, which compounds for bigger boards, and messages are lost. Without remote cron, messages in queue can be delayed until a visitor triggers deferred.php. Without batch requests, too much HTTP overhead.

Theoretically, a user should be able to set up a cron job locally, but in the bigger picture I found is that the more steps I took out for webmasters/admins to take, the more of them got to use the product as intended with the least issues and support requests.
 
Last edited:
If the idea is, if they don't update, that's their problem, in practice it does not work out well, particularly for boards in non-western countries.
We’re only officially supporting OS/browser versions with generally a current version - 1 pattern. In reality, much older devices should work with XF but we can’t guarantee it and the represent such a small minority that we don’t need to concern ourselves with it.

Android 4 is 5 years old this year and it supports the latest versions of Chrome, Firefox and I think MS Edge at minimum, all of which will provide adequate push notifications support.

If you’re expecting us to support older versions than that, then it’s a fairly unreasonable expectation.
 
We’re only officially supporting OS/browser versions with generally a current version - 1 pattern.

In reality, much older devices should work with XF but we can’t guarantee it and the represent such a small minority that we don’t need to concern ourselves with it.
The current version - 1 pattern would work if it were mostly iOS users. I recall looking at mobile suite usage statistics, and it's a very valid concern for many forums outside the USA and EU.
Android 4 is 5 years old this year and it supports the latest versions of Chrome, Firefox and I think MS Edge at minimum, all of which will provide adequate push notifications support.
The assumption being made is that the majority of people on these older versions update their mobile browser. The January statistics say 18.9% of people are on some version of Android 4, but those statistics do not illustrate the country distribution, or their browser version.
If you’re expecting us to support older versions than that, then it’s a fairly unreasonable expectation.
I have only been referring to Android 4+, because older versions didn't have push notifications..
 
The assumption being made is that the majority of people on these older versions update their mobile browser. The January statistics say 18.9% of people are on some version of Android 4, but those statistics do not illustrate the country distribution, or their browser version.
If stock browser in Android 4 supports Push Notification with the help of Service Workers(I'm assuming that we are using service workers), then we shouldn't have any problems.
 
Ultimately if people don’t want to update their browser we just have to assume they wouldn’t care about push notifications in the first place. If they do care about it, I guess they’ll have to make a trip to the Play Store to update or download a new browser.

You can take a horse to water, but you can’t make it use push notifications.
 
we are not interested in using htts/ssl

I'd definitely recommend against avoiding https. There aren't really any downsides to using it since you can get free SSL certificates using LetsEncrypt (And any host using a relatively recent version of cPanel will do this automatically). You're also going to have a (soon-to-be red) "Not Secure" notification in your address bar on Chrome, and I suspect Firefox and the others will follow suit. FireFox will also show this notification on any page with a password or card input.

Chrome:
Screen Shot 2018-10-15 at 7.49.48 AM.webp


Firefox:
Screen Shot 2018-10-15 at 7.51.54 AM.webp
 
I'd definitely recommend against avoiding https.
HTTPS/SSL is a requirement, not an option, for push notifications on Chrome. Service Workers. My memory is foggy, but I don't think it's the case for macOS Safari Push, and definitely not for the Facebook fallback/iOS.
 
HTTPS/SSL is a requirement, not an option, for push notifications on Chrome. Service Workers. My memory is foggy, but I don't think it's the case for macOS Safari Push, and definitely not for the Facebook fallback/iOS.

My post wasn't really related to push notifications, just the quote where someone said they're not interested in https/ssl
 
Sorry if this has been covered, but is there a way to auto select all notifications when the user enables them, or do they need to go through and select each one individually?
 
Does this mean the red dot in the favicon and the alert count on any open (and logged in) XF tab will be updated asynchronously too (when a notification arrives)?
 
Back
Top Bottom