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:
Great news. So starting with new version, no need to install or make any configuration for push notification.

It is also great to have a separate settings for it, great job
 
Normally read content. So if you venture upon a post via new posts or an email or click straight into the thread that will mark the relevant alerts read too.
Nice, I can junk a pile of code out of my Alert Improvements add-on :)

I assume this is done(or can be done) for stuff like XFRM/XFMG/etc and other sources of alerts?
 
Looks good!

Hopefully people will move away from 5.6 in the future, considering it is 4 years old and better versions are available.. then again.. people are still running 5.2 which is 12 years old.
 
Nice, I can junk a pile of code out of my Alert Improvements add-on :)

I assume this is done(or can be done) for stuff like XFRM/XFMG/etc and other sources of alerts?
Yeah it's not an especially "magic" approach, it has to be explicitly called where needed:
PHP:
/** @var \XF\Repository\UserAlert $userAlertRepo */
$userAlertRepo = $this->repository('XF:UserAlert');
$userAlertRepo->markUserAlertsReadForContent('post', $posts->keys());
 
Yeah it's not an especially "magic" approach, it has to be explicitly called where needed:
PHP:
/** @var \XF\Repository\UserAlert $userAlertRepo */
$userAlertRepo = $this->repository('XF:UserAlert');
$userAlertRepo->markUserAlertsReadForContent('post', $posts->keys());
Well that is basically what I've been doing in Alert Improvements. So about what I expected. FYI, I found that doing a select and if rows are found doing a conditional update produces the least amount of contention on my sites as this can be run without a transaction across multi-statement actions. Also works well with master-slave setups where the select can afford to be run on a difference MySQL instance.

I do have one case where I only mark particular actions for a content as read, but that is a corner case.
 
Well that is basically what I've been doing in Alert Improvements. So about what I expected. FYI, I found that doing a select and if rows are found doing a conditional update produces the least amount of contention on my sites as this can be run without a transaction across multi-statement actions. Also works well with master-slave setups where the select can afford to be run on a difference MySQL instance.

I do have one case where I only mark particular actions for a content as read, but that is a corner case.
We have support for that too :)

The full signature for that method is:
PHP:
public function markUserAlertsReadForContent($contentType, $contentIds, $onlyActions = null, \XF\Entity\User $user = null, $viewDate = null)
I guess the only functional difference there is that $onlyActions can be a string of a single action (or an array of actions) and we just make sure it's an array for the eventual query ($contentIds works the same, FWIW). Not sure we actually use it anywhere by default but it seemed worthwhile.
 
Great news! This explains why Chris's Push Notification add-on hasn't been ported to XenForo 2 then. ;)

I look forward to having this feature, it'll be a real boon to users. Let's just hope that Apple gets its act together soon.
 
Top Bottom