Wie man Webpushr Push-Benachrichtigungen für WordPress einrichtet

Webpushr ist eine Web-Push-Benachrichtigungsplattform, die Echtzeit-Browser-Benachrichtigungen an angemeldete Benutzer sendet, selbst wenn diese Ihre Website bereits verlassen haben. Im Gegensatz zu E-Mail oder SMS benötigt Web Push keine persönlichen Kontaktdaten — Abonnenten erhalten Benachrichtigungen direkt über das native Benachrichtigungssystem ihres Browsers über das Web Push Protocol und die Push API.

Diese Anleitung führt Sie durch den gesamten Einrichtungsprozess: von der Kontoerstellung und WordPress-Plugin-Konfiguration bis hin zu erweiterter Segmentierung, triggerbasierter Automatisierung und Abonnentenanalysen. Sie behandelt auch technische Sonderfälle — Service-Worker-Konflikte, HTTPS-Anforderungen, iOS-Kompatibilitätslücken und Leistungsaspekte — die die meisten Tutorials vollständig auslassen.

Voraussetzungen vor dem Start

Bevor Sie das WordPress-Dashboard öffnen, überprüfen Sie, ob Ihre Umgebung die folgenden Mindestanforderungen erfüllt:

• HTTPS ist obligatorisch. Die Push API und Service Worker sind auf sichere Ursprünge beschränkt. Eine Website, die auf einfachem HTTP läuft, kann keinen Service Worker registrieren und daher keine Web-Push-Benachrichtigungen senden. Wenn Ihre Website noch nicht gesichert ist, benötigen Sie ein gültiges SSL-Zertifikat — AlexHost bietet SSL-Zertifikate an, die diese Anforderung abdecken.
• WordPress 5.0 oder höher wird für vollständige Gutenberg-Block-Editor-Kompatibilität mit der Webpushr-Meta-Box empfohlen.
• PHP 7.4 oder höher auf der Serverseite, um veraltete Funktionswarnungen zu vermeiden, die die Plugin-Initialisierung still zum Scheitern bringen können.
• Browser-Kompatibilitätsbewusstsein: Chrome, Firefox und Edge auf Desktop und Android unterstützen das Web Push Protocol. Safari auf macOS hat die Unterstützung in Safari 16 (macOS Ventura) hinzugefügt. iOS Safari hat in iOS 16.4 eingeschränkte Unterstützung für Home-Screen-PWAs hinzugefügt — standardmäßiges browserbasiertes Web Push auf iOS bleibt zum Zeitpunkt dieser Dokumentation unzuverlässig.
• Keine konfligierenden Service Worker. Wenn Sie bereits ein PWA-Plugin oder einen anderen Push-Benachrichtigungsdienst betreiben, können deren Service Worker mit denen von Webpushr in Konflikt geraten. Überprüfen Sie Ihre aktiven Service Worker unter chrome://serviceworker-internals/, bevor Sie fortfahren.

Schritt 1: Webpushr-Konto erstellen und konfigurieren

Navigieren Sie zu webpushr.com und registrieren Sie ein neues Konto. Während des Onboardings werden Sie nach der Domain Ihrer Website gefragt. Geben Sie die genaue Domain ein, wie sie in der Adressleiste Ihres Browsers erscheint, einschließlich des www-Präfixes oder dessen Fehlen — dieser Wert wird verwendet, um den Service Worker zu begrenzen, und Abweichungen führen zu Anmeldefehlern.

Nach der Registrierung stellt Webpushr zwei wichtige Anmeldedaten bereit:

• API Key — wird vom WordPress-Plugin verwendet, um REST-API-Aufrufe zum Senden von Benachrichtigungen zu authentifizieren.
• Auth Token — wird für serverseitige API-Anfragen verwendet, wenn Sie später benutzerdefinierte Integrationen erstellen.

Beide Werte finden Sie unter Account > API Keys im Webpushr-Dashboard und bewahren Sie diese sicher auf. Der API Key ist im traditionellen Sinne kein Geheimnis (er ist in clientseitigen Anfragen eingebettet), aber der Auth Token muss privat gehalten werden.

Webpushr Free vs. Bezahlte Plan-Limits

Für die meisten kleinen WordPress-Websites ist der kostenlose Tarif ausreichend, um den Kanal zu validieren, bevor man sich für einen bezahlten Plan entscheidet.

Schritt 2: Webpushr WordPress-Plugin installieren

Melden Sie sich in Ihrem WordPress-Adminbereich an und folgen Sie diesem Pfad:

1. Gehen Sie zu Plugins > Neu hinzufügen.
2. Suchen Sie nach Webpushr.
3. Suchen Sie das offizielle Plugin, das von Webpushr Inc. veröffentlicht wurde — überprüfen Sie den Herausgebernamen, um die Installation eines ähnlich benannten Plugins zu vermeiden.
4. Klicken Sie auf Jetzt installieren und dann auf Aktivieren.

Alternativ können Sie die Installation über WP-CLI durchführen, wenn Sie WordPress über die Befehlszeile verwalten:

wp plugin install webpushr-web-push-notifications --activate

Nach der Aktivierung erscheint ein neuer Webpushr-Menüpunkt in der linken WordPress-Navigation.

Was das Plugin tatsächlich auf Serverebene tut

Das Verständnis der Plugin-Architektur hilft Ihnen, Probleme intelligent zu beheben. Bei der Aktivierung führt das Plugin folgende Aktionen durch:

1. Registriert eine Rewrite-Regel, um die Service-Worker-Datei (webpushr-sw.js) aus dem Website-Stammverzeichnis bereitzustellen. Dies ist entscheidend — Service Worker müssen aus dem Root-Bereich bereitgestellt werden, um den gesamten Ursprung zu kontrollieren.
2. Fügt über wp_enqueue_scripts ein JavaScript-Snippet in jede Frontend-Seite ein, das das Webpushr SDK lädt und den Service Worker registriert.
3. Hängt sich in die WordPress-Aktionen publish_post und publish_page ein, um automatische Push-Benachrichtigungen auszulösen, wenn Inhalte veröffentlicht werden.

Wenn Ihr Caching-Plugin die Service-Worker-Datei aggressiv zwischenspeichert, erhalten Abonnenten möglicherweise veraltete Push-Payloads oder können sich überhaupt nicht registrieren. Schließen Sie webpushr-sw.js von Ihren Caching-Regeln aus.

Schritt 3: Plugin mit Ihrem Webpushr-Konto verbinden

Navigieren Sie in Ihrem WordPress-Dashboard zu Webpushr > Einstellungen. Sie sehen ein Feld mit der Bezeichnung API Key. Fügen Sie den API Key ein, den Sie in Schritt 1 aus dem Webpushr-Dashboard abgerufen haben.

Klicken Sie auf Änderungen speichern. Das Plugin sendet eine Validierungsanfrage an die Webpushr API. Wenn der Schlüssel gültig ist, erscheint eine Erfolgsbestätigung. Wenn Sie eine Fehlermeldung sehen:

• Stellen Sie sicher, dass im eingefügten Schlüssel keine führenden oder nachfolgenden Leerzeichen vorhanden sind.
• Überprüfen Sie, ob Ihr Server ausgehende HTTPS-Anfragen an api.webpushr.com senden kann. Einige gehärtete VPS-Konfigurationen blockieren standardmäßig ausgehende Verbindungen. Testen Sie auf einem Linux-Server mit:

curl -I https://api.webpushr.com

Eine 200 OK– oder 301-Antwort bestätigt die Konnektivität. Wenn die Verbindung abbricht, überprüfen Sie Ihre Firewall-Regeln mit iptables -L OUTPUT oder der Netzwerk-ACL Ihres Hosting-Anbieters.

Wenn Sie WordPress in einer VPS-Hosting-Umgebung betreiben, haben Sie die volle Kontrolle über Firewall-Regeln und können den Webpushr API-Endpunkt direkt auf die Whitelist setzen.

Schritt 4: Opt-In-Aufforderung konfigurieren

Die Opt-In-Aufforderung ist der Browser-Berechtigungsdialog, der Benutzer fragt, ob sie Benachrichtigungen zulassen möchten. Der native Berechtigungsdialog des Browsers kann nicht gestaltet werden — er wird vom Browser selbst gerendert. Webpushr bietet jedoch eine Vor-Berechtigungs-Aufforderung (ein benutzerdefiniertes Overlay, das vor dem nativen Dialog erscheint), die Sie vollständig anpassen können.

Konfigurieren Sie die Vor-Berechtigungs-Aufforderung im Webpushr-Dashboard unter Einstellungen > Opt-in Prompt:

• Aufforderungsstil: Wählen Sie zwischen einem Glocken-Widget, einer oberen Leiste, einem Einschub-Feld oder einem benutzerdefinierten Modal.
• Aufforderungstext: Schreiben Sie einen Text, der den Mehrwert des Abonnierens klar kommuniziert. Vage Aufforderungen wie „Benachrichtigungen zulassen?” schneiden konsequent schlechter ab als Aufforderungen, die angeben, was Abonnenten erhalten werden, wie z. B. „Werden Sie sofort benachrichtigt, wenn wir neue Sicherheitshinweise veröffentlichen.”
• Aufforderungsverzögerung: Legen Sie eine Verzögerung (in Sekunden oder Seitenaufrufen) fest, bevor die Aufforderung angezeigt wird. Das sofortige Anzeigen beim Laden der Seite führt zu niedrigeren Opt-In-Raten als das Warten, bis ein Benutzer mindestens einen Inhalt gelesen hat.
• Erneutes Aufforderungsintervall: Legen Sie fest, wie viele Tage vergehen müssen, bevor einem abgelehnten Benutzer die Aufforderung erneut angezeigt wird. Aggressives erneutes Auffordern beeinträchtigt die Benutzererfahrung und erhöht die Absprungrate.

Opt-In-Raten-Benchmarks nach Aufforderungstyp

Kontextuelle Aufforderungen — die angezeigt werden, nachdem ein Benutzer eine bedeutungsvolle Aktion abgeschlossen hat, wie z. B. einen Artikel bis zum Ende zu lesen — übertreffen konsequent alle anderen Ansätze.

Schritt 5: Benachrichtigungszustellungseinstellungen konfigurieren

Automatischer Push bei Beitragsveröffentlichung

In Webpushr > Einstellungen steuert der Schalter Auto-Push Notification, ob eine Push-Benachrichtigung automatisch ausgelöst wird, jedes Mal wenn Sie einen Beitrag veröffentlichen. Wenn aktiviert, ruft Webpushr automatisch den Beitragstitel, den Auszug und die URL des Beitragsbilds ab und erstellt die Benachrichtigungs-Payload automatisch.

Sonderfall: Wenn Sie einen Staging-zu-Produktions-Workflow verwenden, bei dem Beiträge importiert oder ihr Status programmgesteuert geändert wird (z. B. über WP-CLI oder ein Migrationsskript), wird der publish_post-Hook für jeden importierten Beitrag ausgelöst, was Ihre Abonnenten möglicherweise innerhalb von Sekunden mit Dutzenden von Benachrichtigungen überflutet. Deaktivieren Sie Auto-Push vor der Ausführung von Massenimporten:

wp option update webpushr_auto_push 0

Aktivieren Sie es nach Abschluss des Imports wieder.

Manueller Push aus dem Beitragseditor

Für eine detaillierte Kontrolle deaktivieren Sie Auto-Push global und verwenden Sie die beitragsspezifische Webpushr-Meta-Box im Beitragseditor. Diese Meta-Box erscheint unterhalb des Hauptinhaltseditors und bietet folgende Steuerelemente:

• Push-Benachrichtigung senden: Ein Kontrollkästchen, das, wenn aktiviert, eine Benachrichtigung bei Veröffentlichung oder Aktualisierung in die Warteschlange stellt.
• Benutzerdefinierter Benachrichtigungstitel: Überschreiben Sie den Beitragstitel mit einer klickwürdigeren Überschrift für die Benachrichtigung.
• Benutzerdefinierte Benachrichtigungsnachricht: Überschreiben Sie den automatisch generierten Auszug.
• Benutzerdefinierte Benachrichtigungs-URL: Leiten Sie Abonnenten auf eine bestimmte Zielseite statt auf den Beitrags-Permalink um — nützlich für Werbekampagnen.
• Benutzerdefiniertes Benachrichtigungssymbol: Überschreiben Sie das Standard-Website-Symbol mit einem kampagnenspezifischen Bild.

Anatomie der Benachrichtigungs-Payload

Eine Web-Push-Benachrichtigungs-Payload besteht aus:

• title — wird fett oben in der Benachrichtigung angezeigt.
• body — der beschreibende Text unterhalb des Titels.
• icon — ein quadratisches Bild (empfohlen 192×192 px), das neben der Benachrichtigung angezeigt wird.
• image — ein großes Bannerbild, das unterhalb des Textkörpers auf unterstützten Plattformen angezeigt wird (Chrome auf Android, Chrome auf Windows).
• badge — ein kleines monochromes Symbol, das in der Android-Statusleiste angezeigt wird.
• url — die Ziel-URL, wenn der Benutzer auf die Benachrichtigung klickt.
• actions — bis zu zwei Aktionsschaltflächen mit benutzerdefinierten Beschriftungen und URLs (unterstützt auf Chrome und Edge).

Das Halten des title unter 50 Zeichen und des body unter 120 Zeichen verhindert Abschneidungen auf den meisten Plattformen.

Schritt 6: Push-Benachrichtigungen End-to-End testen

Das Testen in derselben Browser-Sitzung, in der Sie in WordPress eingeloggt sind, gibt Ihnen kein genaues Bild der Abonnentenerfahrung. Verwenden Sie ein separates Browser-Profil oder ein Inkognito-Fenster:

1. Öffnen Sie Ihre Website in einem privaten/Inkognito-Fenster.
2. Die Vor-Berechtigungs-Aufforderung sollte nach Ihrer konfigurierten Verzögerung erscheinen.
3. Klicken Sie auf den Call-to-Action der Aufforderung und dann auf Zulassen im nativen Berechtigungsdialog des Browsers.
4. Kehren Sie zu Ihrem WordPress-Dashboard zurück und veröffentlichen Sie einen Testbeitrag, oder verwenden Sie die Schaltfläche Testbenachrichtigung senden im Webpushr-Dashboard.
5. Überprüfen Sie, ob die Benachrichtigung mit dem richtigen Titel, Text, Symbol erscheint und ob das Klicken darauf zur richtigen URL navigiert.

Häufige Fehlerursachen beim Testen:

• Benachrichtigung erscheint nicht: Überprüfen Sie, ob Browser-Benachrichtigungen nicht auf Betriebssystemebene blockiert sind (Windows Fokus-Assistent, macOS Nicht stören, Android-Benachrichtigungskanäle).
• Service Worker registriert sich nicht: Öffnen Sie DevTools > Anwendung > Service Worker und bestätigen Sie, dass webpushr-sw.js als aktiv aufgeführt ist. Wenn er als „wartend” angezeigt wird, blockiert ein anderer Service Worker die Aktivierung.
• Symbol wird nicht geladen: Die Symbol-URL muss absolut sein (beginnend mit https://) und das Bild muss mit permissiven CORS-Headern bereitgestellt werden, wenn es auf einem CDN gehostet wird.

Schritt 7: Erweiterte Funktionen — Segmentierung, Planung und Trigger

Zielgruppensegmentierung

Die Segmentierungsmaschine von Webpushr ermöglicht es Ihnen, Abonnenten basierend auf folgenden Kriterien zu markieren:

• URL-basierte Segmente: Markieren Sie automatisch Abonnenten, die bestimmte URLs oder URL-Muster besuchen (z. B. werden alle Benutzer, die /category/security/ besuchen, mit security-readers markiert).
• Benutzerdefinierte Attribute: Übergeben Sie beliebige Schlüssel-Wert-Paare über das JavaScript SDK, um Segmente basierend auf Benutzereigenschaften zu erstellen, die Ihre Anwendung bereits verfolgt.
• Engagement-Segmente: Webpushr verfolgt automatisch Zeitstempel des letzten Besuchs, sodass Sie Re-Engagement-Kampagnen für Abonnenten erstellen können, die seit mehr als 30 Tagen keine Benachrichtigung erhalten haben.

Die Segmentierung erfordert einen bezahlten Plan und wird im Webpushr-Dashboard unter Segmente konfiguriert.

Geplante Benachrichtigungen

Die Planung ermöglicht es Ihnen, eine Benachrichtigung jetzt zu verfassen und sie zu einem zukünftigen Datum und einer zukünftigen Uhrzeit mit Zeitzonenunterstützung zu liefern. Dies ist besonders wertvoll für:

• Zeitkritische Aktionen mit einem festen Ablaufdatum.
• Inhalte, die außerhalb der Hauptverkehrszeiten veröffentlicht werden und während Hochengagement-Fenstern geliefert werden sollen.
• Wiederkehrende Digest-Benachrichtigungen (z. B. wöchentliche Zusammenfassungen).

Benutzerdefinierte triggerbasierte Benachrichtigungen

Benutzerdefinierte Trigger lösen Benachrichtigungen basierend auf JavaScript-Ereignissen auf Ihrer Website aus. Zum Beispiel können Sie eine Benachrichtigung 24 Stunden nach dem Verlassen eines Warenkorbs durch einen Benutzer auslösen oder wenn ein Benutzer eine bestimmte Scrolltiefe erreicht. Trigger werden über das Webpushr JavaScript SDK konfiguriert und erfordern benutzerdefinierte Entwicklungsarbeit über die Standardfähigkeiten des WordPress-Plugins hinaus.

A/B-Tests für Benachrichtigungstexte

Bei bezahlten Plänen unterstützt Webpushr Split-Tests für Benachrichtigungstitel und Textkörper über Abonnentensegmente hinweg. Führen Sie A/B-Tests durch, um zu bestimmen, welche Botschaft höhere Klickraten erzielt, bevor Sie eine vollständige Kampagne starten.

Schritt 8: Abonnentenanalysen überwachen

Das Webpushr-Dashboard bietet folgende Metriken:

• Gesamtabonnenten: Aktive, abgemeldete und abgelaufene Endpunktzählungen.
• Zustellungsrate: Prozentsatz der gesendeten Benachrichtigungen, die erfolgreich an den Browser-Push-Dienst geliefert wurden (FCM für Chrome/Edge, Mozilla Autopush für Firefox).
• Klickrate (CTR): Prozentsatz der zugestellten Benachrichtigungen, die zu einem Klick geführt haben.
• Abonnentenwachstum im Zeitverlauf: Tägliche und wöchentliche Trends bei der Abonnentengewinnung.

Wichtiger technischer Hinweis zu „zugestellt” vs. „empfangen”: Eine Benachrichtigung wird als zugestellt markiert, wenn der Browser-Push-Dienst (z. B. Googles FCM) die Payload akzeptiert. Wenn das Gerät des Benutzers offline ist, stellt FCM die Benachrichtigung in die Warteschlange und liefert sie, wenn das Gerät wieder verbunden ist — jedoch nur innerhalb des TTL-Fensters (Time to Live), das Sie konfigurieren. Der Standard-TTL beträgt 28 Tage. Für zeitkritische Benachrichtigungen setzen Sie einen kürzeren TTL, um die Lieferung veralteter Inhalte zu vermeiden.

Plattform- und Browser-Kompatibilitätsmatrix

„Vollständige Unterstützung” bedeutet, dass das Web Push Protocol, Service Worker und Benachrichtigungsaktionen alle unterstützt werden. iOS-Benutzer in Standard-Browser-Sitzungen bleiben außerhalb der Reichweite von Web Push, was eine bedeutende Zielgruppenlücke für mobilintensive Websites darstellt.

Überlegungen zur Hosting-Infrastruktur

Die Zustellung von Web-Push-Benachrichtigungen wird größtenteils von Drittanbieter-Push-Diensten (FCM, Mozilla Autopush) übernommen, sodass der rohe Durchsatz Ihres Servers kein Engpass für die Zustellung ist. Ihre Hosting-Umgebung beeinflusst jedoch:

• Bereitstellungsgeschwindigkeit des Service Workers: Die webpushr-sw.js-Datei muss bei jedem Seitenaufruf schnell abgerufen werden, damit Browser überprüfen können, ob der Service Worker aktuell ist. Ein langsamer Server erhöht die Time to First Byte (TTFB) für diese Datei.
• API-Antwortzeit: Wenn ein neuer Beitrag veröffentlicht wird, führt das Plugin einen synchronen API-Aufruf an Webpushr durch. Bei Shared Hosting mit restriktiven Limits für ausgehende Verbindungen kann dieser Aufruf eine Zeitüberschreitung haben und still scheitern.
• Webhook-Zuverlässigkeit: Wenn Sie Webpushr-Webhooks konfigurieren, um Ihren Server über Abonnementereignisse zu benachrichtigen, muss Ihr Server zuverlässig eingehende POST-Anfragen akzeptieren.

Der Betrieb von WordPress auf einem VPS mit cPanel gibt Ihnen die Kontrolle, PHP-Ausführungstimeouts anzupassen, ausgehende Firewall-Regeln zu konfigurieren und die Service-Worker-Zustellung zu überwachen, ohne die Einschränkungen von Shared-Hosting-Umgebungen. Für stark frequentierte Websites, bei denen Push-Benachrichtigungskampagnen erhebliche gleichzeitige Traffic-Spitzen verursachen, stellt ein Dedizierter Server sicher, dass Ihr Ursprungsserver die resultierende Klick-Last ohne Drosselung bewältigen kann.

Für Teams, die mehrere WordPress-Websites verwalten, schafft E-Mail-Hosting in Kombination mit Webpushr eine Zwei-Kanal-Re-Engagement-Strategie — Push für Unmittelbarkeit, E-Mail für Tiefe.

Technische Entscheidungsmatrix: Wann Webpushr vs. Alternativen verwenden

Der kostenlose Tarif von Webpushr ist eingeschränkter als der von OneSignal, aber seine Service-Worker-Implementierung ist deutlich sauberer und weniger anfällig für Konflikte mit anderen WordPress-Plugins — ein praktischer Vorteil bei komplexen WordPress-Installationen.

Praktische Checkliste vor dem Live-Gang

• HTTPS ist aktiv und das SSL-Zertifikat ist gültig und nicht selbstsigniert.
• Service Worker webpushr-sw.js ist unter https://yourdomain.com/webpushr-sw.js zugänglich und gibt einen 200-Status zurück.
• Die Service-Worker-Datei ist von den Cache-Regeln Ihres Caching-Plugins ausgeschlossen.
• Die Opt-In-Aufforderungsverzögerung ist auf mindestens 5 Sekunden oder einen Seitenaufruf eingestellt.
• Auto-Push ist deaktiviert, wenn Sie geplante Massenimporte oder Inhaltsmigrationen durchführen.
• Eine Testbenachrichtigung wurde in einer sauberen Browser-Sitzung End-to-End empfangen.
• Die Benachrichtigungssymbol-Abmessungen sind 192×192 px und die URL ist absolutes HTTPS.
• TTL ist entsprechend der Zeitkritikalität Ihrer Inhalte konfiguriert.
• Eine Analytics-Baseline wird vor Ihrer ersten Kampagne aufgezeichnet, damit Sie einen aussagekräftigen Vergleichspunkt haben.
• Datenschutzrichtlinie/DSGVO-Richtlinie wurde aktualisiert, um die Datenerfassung für Push-Benachrichtigungen offenzulegen.

FAQ

Funktioniert Webpushr ohne HTTPS?

Nein. Die Web Push API und Service Worker sind durch die Browser-Spezifikation auf sichere Ursprünge beschränkt. Jede Website, die auf HTTP läuft, kann keinen Service Worker registrieren und daher keine Web-Push-Benachrichtigungen senden oder empfangen. Ein SSL-Zertifikat ist eine harte technische Anforderung, keine optionale Best Practice.

Warum werden meine Push-Benachrichtigungen nicht an einige Abonnenten zugestellt?

Die häufigsten Ursachen sind: Das Gerät des Abonnenten war offline und überschritt das TTL-Fenster der Benachrichtigung; der Benutzer hat die Benachrichtigungsberechtigungen auf Browser- oder Betriebssystemebene widerrufen; oder der Browser-Push-Dienst-Endpunkt (FCM, Mozilla Autopush) hat eine abgelaufene oder ungültige Registrierung zurückgegeben. Das Webpushr-Dashboard markiert diese als „fehlgeschlagene” Zustellungen und entfernt automatisch Endpunkte, die eine 410 Gone-Antwort zurückgeben, was das korrekte Verhalten gemäß der Web Push Protocol-Spezifikation ist.

Kann ich Push-Benachrichtigungen an iOS-Benutzer senden?

Ab iOS 16.4 wird Web Push nur für Progressive Web Apps (PWAs) unterstützt, die dem Home-Screen hinzugefügt wurden. Benutzer, die Ihre Website in Safari oder einem anderen iOS-Browser durchsuchen, ohne sie zum Home-Screen hinzuzufügen, erhalten keine Web-Push-Benachrichtigungen. Dies ist eine plattformseitige Einschränkung von Apple, keine Webpushr-Einschränkung.

Wird der Webpushr Service Worker mit meiner bestehenden PWA oder meinem Caching-Plugin in Konflikt geraten?

Das kann passieren. Nur ein Service Worker kann einen bestimmten Bereich zu einem Zeitpunkt kontrollieren. Wenn ein PWA-Plugin (z. B. Super PWA) oder ein anderer Push-Dienst bereits einen Service Worker im Root-Bereich registriert hat, wird der Service Worker von Webpushr in einem „wartenden” Zustand in die Warteschlange gestellt und nie aktiviert. Die Lösung besteht darin, einen Service Worker zu verwenden, der beide Skripte importiert, oder einen einzigen Push-Anbieter zu wählen und die anderen zu deaktivieren. Überprüfen Sie chrome://serviceworker-internals/, um alle registrierten Worker auf Ihrer Domain zu prüfen.

Werden meine bestehenden Abonnenten abgemeldet, wenn ich das Webpushr-Plugin deaktiviere?

Nein. Die Deaktivierung des Plugins entfernt das JavaScript SDK von Ihrem Frontend, was neue Abonnements verhindert und automatische Benachrichtigungen stoppt. Bestehende Push-Endpunkt-Registrierungen bleiben jedoch im Browser gültig, bis der Benutzer die Berechtigung explizit widerruft oder der Endpunkt abläuft. Wenn Sie das Plugin mit demselben API Key erneut aktivieren, sind diese Abonnenten sofort wieder erreichbar.