🇬🇧United Kingdom @gMaximus

This is really frustrating for me too. I hadn't tested iPhones. I've been inundated with paid work. I use this module on a personal project.

When things have calmed down again, I will 100% be investing more hours into this.

I'll quickly release if you make the fix.

Do things work on Mac's? Or is it only an iPhone issue? I ask because I don't have access to a Mac.

You may find this of interest https://www.drupal.org/project/instagram_feeds/issues/3319317 ✨ Add video and carousel support + Upgrades for social network use cases. Needs review .

It adds video and carousal support.

It will import the video file but Drupal can make a thumbnail. I think I needed contrib modules to get that to happen. To memory media_thumbnail and ffmpeg modules. I can look that up if it's of interest.

# comment 13

My understanding of topics is that each message can have one. It is specified when a message is sent. If there is a previous message still unopened for their browser, it will be replaced by the latest one?

# comment 12

Thank you for confirming the tech works and that it's a module issue. I think the rest I covered with my last comment

# comment 7

My understanding at present is that the module will allow the connection. As in trigger the browser prompt and save the endpoint when allowed. Passed that there is no bidirectional communication in relation to settings.

That said, there is a lot of code that suggests it was being worked on. There is JS code and a Drupal route.

I have a bit of a problem in that the only Apple device I have access to is a iPhone. After setting the module up fresh, I used the iPhone and saw no modal.

I had successfully tested notifications on Firefox, Edge and Chrome on both Windows and Android. I've done the same today.

Comment #5
I'm seeing the same for my site. Interestingly, this didn't happen for anonymous. See my screenshot. 1-6 were created when I accepted push notifications as admin once using Chrome. Whilst 7-9 was three different browsers, inc Chrome, as anonymous. When testing, duplicate messages was not received.

Comment #17
Cron information is on the module page, README.md and video. This is because a site could hopefully have 1000's of subscribed browsers. By adding them to a queue to be processed on cron runs we won't blow up our machines.

Comment #18
Pls see attached patch that should address the issues relating to that particular code.

There is logging in this patch. The correct result in the console for un-supporting browsers is this:

Service worker registered with scope: https://yourdomain.com/ main.js:26:19
Background Sync is not supported. main.js:31:21
Sync registration failed or Service worker registration failed, error: Background Sync is not supported main.js:42:19

I don't believe push notifications is related to this. From what I can tell it is all about caching resources. Not all browsers support background sync. So this patch provides a fallback for those browsers. However device caching isn't being done at all on these browsers from what I can see.

(All logging will be removed when committed. The patch will be tidier)

So to be clear, I haven't got push notifications working on my partners iPhone because the modal didn't appear. Confusingly, you have? Judging by the mentioned Apple endpoints.

I shall continue working on this as a matter of urgency. Thursday will be the next day I can be on the case. No support for Apple devices isn't an option for me. The whole of next week I'm away working annoyingly lol. As soon as I'm back I'll be on the case.

I started maintaining this module after it's original development, so I'm still learning it if I'm brutally honest. There are areas of the module I haven't needed to understand yet. Like you, I wanted push notifications, that was my motivation with this module.

I've updated the help text for the image fields. It now specifies that they must be the exact dimensions.

I currently have more pressing issues in the queue to work on.

Any assistance would be greatly appreciated.

I would like the feature.

The file system scheme was fixed in the related issue.

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.

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.

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.

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.

With the push notifications, after clicking Drupal's confirm button on the prompt, the browser should then prompt you for permission with something like allow/block.

I've tested chrome, Firefox and edge.

Edge blocked the request for access. It showed me a little icon in the address bar to indicate this. I clicked that to allow requests and all was fine.

Conversations about push notifications should be a different issue. There are conversations being had in the queue already. More the merrier.

After you give this your sign of approval for the above patch, I'll be considering this particular issue resolved. I'll then push it to dev

This issue was all to do with the original developers getting the default file system for the website from configuration. I hadn't picked up on this because I never really use the private file system feature. I do understand it though.

I've now searched all files for instances of this and hardcoded it to public. The patch above corrects those.

I really appreciate you helping with testing.

Let me know if you're satisfied that this is resolved and I'll update dev.

This patch should conclude these issues with the private file system set as default.

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.

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.

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?

My bad. I missed a step. I originally believed that by using the correct commit message, everything else happened.

Thanks for pointing this out. I'll do the same for other fixed issues.

Hi @sarwan_verma,

Crediting is something very important to me.

In the commit above, it shows committed by me and authored by you?

Am I missing something? I want it to be right

You've certainly given me some reading. I'll come back to you soon.

I've always tested using a website that is online. That maybe why they aren't being sent for you. Well unless yours is already online, its worth a try.

Also, did you watch the videos for the three modules? They reliably works for me as demonstrated.

I've been testing 8.2, I'll test PHP 8.3. For me everything is working on my websites. I'm working on these things for others for my love of opensource.

I'm really sorry to have wasted your time. I thought I had committed the changes to deal with this and I was mistaken.

Apologies, the changes that I expect to fix your issue are now in dev. Thanks for being so quick to test.

I have tested this module lots on sub-domains and am confident that it isn't an issue. I just haven't tried it with different installs in sub-folders. In theory it should be fine.

I'm convinced your difficulties have stemmed from your default file system being set to private. I hadn't tested that, it is nothing that you done wrong.

There was a line of code that used that default scheme for the website. That is now hardcoded to public://. So we should be good.

Let me know if we're good now.

Pls retest dev. I've made changes that will hopefully rectify your issues. It would require public:// files system being configured.

I believe part of the errors you gave me was related to the private file system. It is now hardcoded to public. So all is well as long as public is configured. Please test the latest dev and let me know if things work for you now.

If it's configured, is the default file system on your site set to private?

I've been working quite a bit on this. I have a couple of questions to help me understand the use case.

1) Why can't you configure your public directory for this purpose? All other configurations would be unaffected.
2) Is there a reason that you would want to restrict access to the manifest and push images?

I've looked at the latest release of the PWA module and it is hard coded to store in the public:// file system. It's not configurable. This leads me to think that you tested the PWA Module on a install with the public directory configured.

Thank you

Thank you.

After some time modal dialog appears to be shown again?

This is a setting on the push configuration page. You can specify how many days to wait before repeating the prompt again.

Yes, I have no installations using the private files feature of Drupal.

I will set one up for testing.

I'm thinking the file system option should be in manifest settings. Like a usual image field.

The folder for icons should be created though. When things are corrected, you would have icons and setting per subdomain. That is expected.

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.

Thank you for your help. It's appreciated and what I love about opensource.

I have a production website with this module installed. I have 2 staging websites that are an exact copy. One for dev and another for QA. Both are subdomains.

For me everything is working. So there is hope.

The first thing I'm going to do is check if my keys are the same. I can't remember if I set things up pre or post launch.

The video tutorial is also a subdomain.

Thanks for that.

I believe this is related to another issue about using the private file system. The above error suggests that the public:// directory is not set on the website?

I plan to spend 2-3 days on this project starting tomorrow. I think I know what needs tweaking to resolve this.

Please send me a link to the issue.

I'm not sure if this module will work in the case of multi site in folders and push notifications. This is because the push notifications are registered for the domain.

There is another issue in the queue that is discussing allowing users to register to paths.

In the case of multi site in folders, I only see sharing tables as a viable option.

I'm also considering whether to add a rules action to send a push notifications to flagging users of an entity.

Currently, the extending modules allow this for nodes and users.

This way a non programmer could create an entity type for "subscriptions" for example. Add some flags to it. Then use rules to send out the notifications.

It was a little disappointing not hearing back from you on the last issue.

I appreciate your input.

I admit I haven't checked editing a node but I did test new comments being posted.

I literally had a couple of mins yesterday. I found the manifest worked in either case.

I'll spend time investigating your issue. I should be able to work on this next week.

Pls confirm your version of Drupal.

What did you do when this error was given?

I'll sort out that typo. Thanks for the info.

I created perfectly sized icons. All works well. Using other ratios wouldn't be a good end result for you.

Although if the right ratio is uploaded, arguably this module should be able to resize it.

I'd love your help implementing this if able. I'm limited on time. I'll get around to it though.

I'm keen for that upgrade.

Regarding multi sites. Are there any errors you can give me? I see no reason you'd be having a problem with that.

Are the multi sites sub-folders of the same domain?

After uploading the icon, can you access it as anonymous?

If you can't, I know the code to change. This would then save the file in the public files directory.

After clicking the confirm button, did the browser then ask for confirmation?

When testing on Microsoft edge, I noticed that they blocked the request for access.

In other words, I clicked confirm button but it didn't show the browsers confirmation with block and allow on.

I have to agree that it would make sense. I do think that PWA and Push notifications belong together. That's what originally attracted me to this module instead of the others. As well as the availability of a service for using in my other modules to send push notifications. I was a little less informed back then tbf.

I've done a lot of work on this module. It's my first position as a maintainer, so was driven more by learning how to do things. As well as developing a cool module that would help others.

Check out the video on the home page to see what this module does now. All of it could be readily copied to your module.

I've also developed 2 supporting modules that implement Rules actions to send push notifications. One also integrates with the Flag module. Again, they are mentioned on this project page. Also easy enough to alter.

So although it's late, I'm open to discussion. I just love coding :)

Hi @efpapado

I started working on this project a short while ago. I've since become a maintainer. I realise this issue is old but felt it was worth responding, albeit late.

This has been my first project/module on d.o. So it's been a great learning experience. I've played with Drupal for a long time, since Drupal 6. I love it!

So firstly, the modules mentioned.
1. Only 3 installs and no recommended release.
2. Only available for Drupal 7.
3. 42 installs and no recommended release.
4. No recommended release and 1 install.
5. This module.

For my own website I wanted a module that could give me push notifications and make it installable. I kind of think of them as the same thing. An app.

I didn't realise what a PWA was at the time if I'm honest. In terms of being able to publish it to App stores.

This module was originally a combination of PWA and Browser push notification. I've since developed Rules and Flag integrations.

Checkout the new video on this project page. It'd be great to discuss further.

New release made. Thanks again people.

Thanks for that @mortona2k. I'll do a release this week. I've got more work to do first.

Can the push_framework update previously sent push notifications? Ie 1 person like your post becomes 2 people liked your post.

I hear what you're saying. For the moment all works as expected. Many modules seem to be guilty of this on my Drupal installs. If you're able to help with these changes, I'll be quick to release. I'm short of time at present. I'd be deeply grateful and would see the value of the upgrade.

I'm interested in doing the same supporting modules for ECA as I've written for Rules. It hopefully won't be too hard on the basis that I have the same for rules. You've educated me on that point, I didn't realise this ECA was the successor. I've been using Drupal since 6 was the recommended release and rules was the thing. Someone else mentioned about Rules on YouTube but not ECA. However, many more sites report using Rules (13,246) next to ECA (3,477).

Are you able to contribute code to this for the other points? I'd be deeply grateful for any assistance and will release quickly.

I've just spent the best part of two weeks moving this project forward in the area of device caching and the manifest. I've nearly finished improving the manifest settings inc screenshots.

Tbh, I need to do cash work now. I've made myself late in favour of contributing these upgrades (I couldn't put it down lol). I've got at least a months worth in the pipeline and I need to eat ;)

@Freddy Rodriguez. Did it work you in your setup?

gMaximus → created an issue.

gMaximus → created an issue.

This caused errors when saving the push notifications settings page. There are a few reports of the dependency injection. I'm closing this to focus efforts in one place.

Your help would be appreciated.

This caused errors when saving the push notifications settings page. There are a few reports of the dependency injection. I'm closing this to focus efforts in one place.

Your help would be appreciated.

gMaximus → created an issue.

If you preserve the logs in the console, you'll see logs relating to caching. Prior to merging, these will be removed. They're useful for testing purposes though.

Well, I'm excited to share that I think we should be good to go. Well I hope so, because I can't put in any more time.

Pls test the latest commit and let me know if it works for you.

p.s Chat GPT is my new best friend thanks to you. It's not perfect though. Well, not yet.

I haven't stopped working on this. I'm stuck though since my last comment. If you know how to code, an answer here would be good: https://drupal.stackexchange.com/questions/320003/why-isnt-my-eventsubsc...

I think the JS will work and we'll be laughing. That is ready hopefully. I'm just stuck on firing the event.

The idea is that the subscriberevent will attach the library when a user logs out. That library has one JS file, it sends a message to the service worker that the user has logged out. The service worker listens for that message and then clears the device cache.

I really need to do some cash work but feel so close.

Both of those look like they wouldn't break hook_user_logout implementations. I'll work on this now and see what I can come up with. That hook feels right. I might be wrong though, we'll find out soon enough. I feel like we're close to having this production ready.

The defaults didn't work correctly. Just done another commit. Message - Fixed defaults for excluded urls.

I've just done another commit to add defaults to the exclude urls field. The last commit message is "Added default setting for excluded urls's."

Separately I've just released https://www.drupal.org/project/advanced_pwa_rules → . There's a video of using it on there.

I'm not experiencing this at present. Things seem to work well now. A lot of work has been done on this module. Pls open if you're finding this issue on the latest release.

This is being dealt with in this issue https://www.drupal.org/project/advanced_pwa/issues/3446692 🐛 Develop the device caching & settings form Active .

I've written a sub-module. After uninstalling the main module, you need to install and leave the sub-module installed. It adds a little JS to the page that unregisters the service worker for returning visitors.

I'm closing this to focus efforts there.

This and other caching issues are being worked on in this issue: https://www.drupal.org/project/advanced_pwa/issues/3446692 🐛 Develop the device caching & settings form Active . In fact the setting to exclude urls from being cached is already done.

I'm closing to this focus efforts on the related issue.

It is in this module where hook_user_logout will need to be implemented. Currently, it is a JS file loaded on all pages. See js/logout.js. That JS then tells the service worker to flush device cache and then reload the page. It reacts on links being clicked that point at /user/logout. I wonder if I could attach that logout.js to the hook somehow. Hmm...

I've just done another commit that adds cache by role settings.

The code you want can be found here: https://git.drupalcode.org/issue/advanced_pwa-3446692/-/tree/3446692-dev.... To ensure you have the right code, run "git log" inside this modules directory. The last commit at this point should be "Added device caching by role setting."

I appreciate you testing things for me. This is what I love about the opensource eco-system. We're working with each other for a common goal without a financial exchange. Where else does that happen? lol

So a few things. Currently this reacts on the click of any link pointing to /user/logout. When those links gets clicked, we tell the service worker to flush the device cache, then it reloads the current page. I didn't think about people who use an alternative method that doesn't use that link. So I'll have to think of another route to trigger the flushing of device cache.

In your setup, would hook_user_logout be fired? Perhaps that might be a route to explore. I'm not sure if it is viable. I had wondered whether that would be a better route. However, at that point it was working for me and it was late.

Currently the service worker caches all pages for all users on their devices, excluding URL's specified on the new "Device Caching" settings tab. Where you can also turn off device caching altogether. We'd need to expand on your idea so that we can activate the cache by role perhaps. Then it would cater for everyone.

I need to supply defaults to the excluded URL's field. I ran out of time last night. These are the ones I have in mind:

• /admin/*
• /node/*/edit
• /node/*/delete
• /system/ajax
• /views/ajax

Are there any others that I should add in your view? I think they're the ones applicable to everyone.

What we do have now, in code, is a json endpoint where we can output any data from Drupal. The service worker then fetches that json to use in the service worker. So cool things are now possible.

After updating the code, flush the caches, logout and then unregister the service worker via the console.

That's what I've been doing during development

The service worker remaining active is expected. Am I missing something on that note?

Hey @Freddy Rodriguez,

I've just committed device caching settings to this fork. Perhaps, this will resolve the issues you've reported?

I'm not experiencing the logout issue. When I logout, it redirects to the home page (logged in cached page), when the device cache clears, it reloads the page. I don't like this solution! It's looks like it jumps. I'll look into other options. Do you have any ideas?

If I logout and open a new browser window, I get the logged out page.

I'm closing this now. The solution for this is in that issue fork.

I've also developed a little more in order to unregister the client-side service worker after uninstalling this module.

Any help you can give testing would be greatly appreciated.

I'm closing this. Pls see the issue linked above. I'm developing the device caching there.

I think that fork will resolve all these issues.