Add support for multiple subscriptions per site

I'm not sure yet. All ideas so far mean users would need to be signed in so that we can store their preferences.

Once the popup has confirmed, then allow is clicked in the browser, the subscription is stored. That would be the point to store the path. The popups aren't then shown again. This is the way the browser works as opposed to Drupal. If a user clicks block in the browser popup, it definitely won't show. Well I believe that to be the case.

That said, we have an example of this being achieved, so why shouldn't we have it.

These are the thoughts I have ATM in terms of an approach for signed out users.

1) how can we get that popup to trigger more than once after the allow button has been clicked?
2) how can we repeat the prompt per path as per the settings? Perhaps cookies would be the way to go.
3) if we can work that out, we could save the 1st argument of the path with each subscription to the database.
4) if we work that out, I could make another complementing module that uses this data in rules. That way the push notifications are easily configurable.
5) how do we then allow unsubscribing? I'm currently blank on this tbh. This is because in this setup, we don't know what device belongs to what user. If we did, this should be possible.

I have done a little research about the feasibility of this. My feeling is one way to achieve support for multiple subscriptions would be to enable subscriptions per View.

e.g In the example above we could have a technology view, and also a science view

Now we can use something like Rules module to create an action when a new node is published. I notice this module also has the option to trigger notifications for newly published nodes.

Now it might be possible to know which View a node belongs to after running some queries. e.g. we can check if a node is returned in the results for a view or not

$view_result = call_user_func_array('views_get_view_result', $params)


// check if new nodeid belongs to a view
foreach (view_result as $row) {
    if ($row->nid == $nid) {
//
      return TRUE;
    } 
}
return FALSE;
 

or

use Drupal\views\Views;

  $nid = 123  // load newly published ;

  $view = Views::getView('my_view_machine_name');  
  $view->setDisplay('my_display_machine_name');
  $view->execute();
  foreach ($view->result as $row) {
    if ($row->nid == $nid) {
//
      return TRUE;
    } else {
return FALSE

  }
}

Is true then we could then trigger an alert or notification for that view.

The problem is I have a list of subscribers, but they can either subscribe or not. It seems reasonable that each subscriber can have one or more subscriptions, and could be notified when a node is updated on a subscription that have subscribed to. Where a node appears across multiple subscriptions or views, it is possible a user will be notified more than once, once for each subscription or view the subscriber has subscribed to.

Alternatively, I guess you could simply allow multiple subscriptions from a single user for a single site.

I am not sure exactly how this does or is supposed to work at the moment?

I'm not sure yet. All ideas so far mean users would need to be signed in so that we can store their preferences.

I am assuming that most subsrribers do not have to login to Drupal for their subscription to be registered on a page or view. Apologies if I have missed something.

how can we get that popup to trigger more than once after the allow button has been clicked?

This is happening for me now.

My feeling is that a user should only have to click allow once per subscription, at least until a user clears their browser cache etc. Cookies can be used for this. User should be notified about the use of cookies. Cookie could expire after some time.

how do we then allow unsubscribing?

Good point. Cookie could be used to determine button to show e.g. subscribe/unsubscribe

However if browser clears cookies that is not the same as unsubscribing.

We could develop the subscriptions to store extra info.

We could create categories with a machine name and display. I'm talking settings.

After that we could make a way for these categories to go on the dialog in the form of check boxes for the user to configure.

I've seen there's a route already for unsubscribing.

As per the documentation, there is a link available to trigger the modal. So surely we could do the same to trigger the dialog to update categories. By putting the markup for both links in places, in theory only one will ever be displayed.

On my own website, I only allow signed in users to use push notifications. This is so I can save the user id on the subscription to use later with the rules modules for personalised notifications.

This is happening for me now.

My feeling is that a user should only have to click allow once per subscription, at least until a user clears their browser cache etc. Cookies can be used for this. User should be notified about the use of cookies. Cookie could expire after some time.

To be clear, you're seeing the modal after agreeing to push notifications? Or clicking block in the browsers popup?

Also, each user can have multiple devices subscribed to the website. The push notifications are for the browser being used at the time of allowing the notifications. So the options for categories will also be per browser.

The links could be subscribe/manage subscriptions. Depending on whether they have allowed push notifications for the website.

My thinking is on the basis that our tech knows if a browser is subscribed. I'm not sure of intricacies past that at present.

On my website I have notification settings on the user entity. In the description I have put the link. I also have a subscribe flag on nodes and users.

My website is a community website as opposed to a news website that wants anonymous to subscribe browsers. So my websites use case is quite different. This is feeling good though as an additional feature.

It would compliment my set up.

I've learned that webpush has a topic feature. That way the user only see's the last message with the topic. I'm definitely going to be making use of that.

To be clear, you're seeing the modal after agreeing to push notifications? Or clicking block in the browsers popup? In either case, I believed it wouldn't. I haven't noticed that behaviour.

At the moment I have been unable to trigger web notifications at all with this module!

After spending longer that I care to admit trying to get this working, I have decided to use https://www.drupal.org/project/web_push_notification →

The reasons for this are:

1. It works
2. It still has some issues but, does supports browser notifications, Safari, Chrome, Firefox
3. Simplified, I am not really interested in PWA, but I am interested in push notifications
4. You are only requested to sign up once!

While this may have some scalability issues, it seems to work well for my purposes. I have also created a patch to accept user generated notifications.

In fact, one feature missing there is the UI for managing the modal window/cta. While I have implemented a crude work around to get this working in Safari, my feeling is that really this should be the default option for all browsers (accept notifications via cta/modal). That is one feature I think this module does very well and I also like the way bootstrap 5 modal are supported here.

As someone else mentioned, if you were to coordinate your efforts, the Drupal community will be all the better off for it.

FYI I have opened up an issue to add support (similar to advanced pwa) for modal window.

My feeling is this could be the default means to prompt users into accepting Notifications in the future.

https://www.drupal.org/project/web_push_notification/issues/3462638#comm... ✨ Add support for modal window Active

May be this is something you can help with implementing?

Sorry to hear that. I've appreciated having your mind.

Did you give users permission to see the prompt? I haven't tested safari as I don't have apple devices. My partner does so I'll try it out with hers. The other browsers have been fine.

Firefox and chrome were fine. Edge displayed and icon in the address bar indicating it had blocked it. I clicked that to allow the browser prompt.

I was the same in terms of the pwa. My interest was the push notifications side of things.

That was until I learned a pwa can be published in app stores and would show an install prompt on mobiles. Then I was hooked on pwa's for user engagement.

I don't use the caching at present on my live website.

The reason a Drupal modal is good is because when they click the decline button (I have it set to maybe later) we can still show them that prompt.

If they click block on the browsers prompt, we can't ask again.

It's not simple to come up with a subscription/notification framework.. I suggest you also look into danse → and push_framework → modules, to allow sending granular messages (based on specific events) to the specific users that subscribed.

Modal patch is working for me with Web Push Notifications. It is a little opinionated. The template for this is added via a twig template using a custom block. This allows you to customise the modal depending on your theme implementation.

Tested on Safari, Chrome and Firefox (mac)

I am not been able to test on Edge browser.

There is one module I think called modal block but this looks like a sandbox or has not been updated to include Drupal X support. Easier just to implement a custom block type and customise the template for that.

There are other modules such as modal page but this looks like overkill to me. I think it makes sense to use block to display a modal as this is editable and can be placed on any page you want depending on path content type etc/

In this case the modal, it is triggered only if the push notification via the browser fails (as is the case with Safari and certain versions of FF as notification needs to be triggered by a user gesture)

With regards to the original issue here, these are my observations:

1. Push Notifications state is kept in the browser. This is per site or domain. e.g. domain.com and www.domain.com have each have different states.
2. State of Notification is either enabled, disabled or deleted. There is no option to extend this AFACT. You cannot say have a token of flag different groups of notifications (client side)
3. Notification token is stored in the browser, and is also kept server side. This is sent when sending out notifications and used by the notificstion centre to push the notification to the browser
4. JS based Service worker is employed to Trigger the push notification service. Service workers can stop and started on a site per site basis or globally.
5. It is possible for a user to use notifications in different browsers. So a single user could have multiple notifications set up
6. To be able to keep track of subscriptions
7. TBH I think the example given (BBC) work differently. Here you can subscribe by section and notifications are sent to your inbox etc. This is not really using web push notifications afaict
8. I am not sure how the push notification service keeps track of which notifications have been enabled, disabled or deleted. I think I did read somewhere that a notification will be flagged appropriately using some algorithm (I will try and find the article). My feeling is there is probably a method that can be used prior to sending out the tokens to send notifications to. The benefit here is that we could have an action to also delete any deleted notifications server side. This could also open up the possibility of also flagging any disabled notifications.
9. I am not sure, but sending out notifications that have been either deleted or disabled could also prevent active notifications from being delivered

.

The main point really is how the push state notification is kept. My feeling is this is a limiting factor when trying to offering push notifications per section.

Certainly from a server side perspective there are other ways of storing the state, most of which probably need a user to register in order to be persistent (i.e. db storage per user).

At this point I am content to use the browser state. This opens up notifications for anonymous users, which I think is what I want now. I also have the option to restrict notifications to newly published nodes by content type etc.

Although it would be nice to be able to filter and send notifications per view (possible) triggered on an event (possible) such as node publish, it is not really possible to have multiple notifications per notification for anonymous users as these are handled per domain restricted to the 2 or 3 different states AFACT.

I therefore think it makes sense to mark this issue as won't fix for now.

Just to follow up on this here is the flow:

Example A - as is

1. User visits site for first time and is prompted to either accept or reject notification (per site or domain)
2. User accept or rejects site notifications
3. User visits another section and is not prompted to sign up notifications as they have previously accepted or rejected the notification

Example B - Support for multiple paths.

1. User visits site and page for the first time
2. Section has cta to subscribe to section only if:
a) they have not subscribed previously to the section
b) they have not rejected notifications from site previously
3. User subscribes to site and section (path)
4. User visits another section and there is a cta to subscribe to notifications only if:
a) they have not subscribed previously to the section
b) they have not rejected notifications from site previously
5. User subscribes to site and section (path)

In the second example we have the option to display subscription per region or view.

The only way I see this working is as we already using db state to record a list of tokens registered by all users, we could also add an additional field that keeps a list of subscribed paths.

e.g when a new node is published, we simply filter the list of push notifications to those that have a matching path. This would require some fairly heavy calculations to determine if a node belongs to one or more of the subscribed paths. It may also result is a use being notified more than once if the node is tagged across both views.

If a user has subscribed to different sections/paths then we can either record a separate entry per section or allow a single client (token) to have multiple subscriptions.

Example of button (and container) that displays only when push notifications are not set for the site:

<div class="onesignal-customlink-container hide">
<p class="onesignal-reset onesignal-customlink-explanation large state-unsubscribed">Want direct access to more helpful content? Subscribe to notifications to stay in the loop.</p>
<button class="onesignal-reset onesignal-customlink-subscribe large button state-unsubscribed" style="background-color: rgb(225, 45, 48); color: rgb(255, 255, 255);">Subscribe to Notifications</button>
</div>

https://onesignal.com/blog/push-notification-design-anatomy/

In theory it should be possible to hide show if push notifications are not set for the site AND push notification token is mapped to path

Slack offers notifications based on tag

Basecamp even offer notification options including restrictions on what times notifications can be sent.

https://www.smashingmagazine.com/2019/04/privacy-better-notifications-ux...

also

Some websites are quite a character, aren’t they? Self-indulgent, impolite at heart, and genuinely unlikeable too. How often do you stumble on a seemingly modest, unpretentious page just to be greeted with a wondrous permissions prompt begging to send you notifications? You haven’t read a single word yet, but there it is, already asking for a long-term commitment — and frankly, quite an invasive one.
https://www.smashingmagazine.com/2019/04/privacy-better-notifications-ux...