Hilfe mit WebBlocks Support erhalten

Verwenden Sie zunächst eine Testinstallation. Das Installieren und Aktivieren von Plugins erfordert Super admin. Support 0.3.6 verlangt CMS ^1.92.1 und PHP >=8.4; der Katalog nennt Laravel ^13.0. Prüfen Sie die Kompatibilität mit CMS und Host, bevor Sie das Paket aus dem WebBlocks-Plugin-Katalog installieren.

Sie benötigen außerdem einen Anbieter für WebBlocks Support Protocol 1.0, dessen HTTPS-Adresse und einen von ihm ausgegebenen einmaligen Einladungscode. Das kostenlose Plugin erstellt kein Anbieterkonto, aktiviert keinen Supportplan und garantiert keine Annahme von Anfragen. Bedingungen und Leistungsumfang legt der Anbieter fest.

CMS-Benutzer brauchen für diesen Ablauf keine separate Anmeldung beim Anbieter. Die Installation stellt die Verbindung her; das Plugin identifiziert den angemeldeten Melder. Eine gewöhnliche Helpdesk-URL genügt nicht: Der Server muss die kompatible Discovery-, Aktivierungs- und Ticket-API bereitstellen.

Support ist ein Supportclient für CMS-Benutzer. Es ergänzt weder ein öffentliches Kundenwidget noch ein Besucherformular oder eine Agentenkonsole beim Anbieter. Für Anfragen von Websitebesuchern verwenden Sie die separate Forms-Anleitung oder Kontaktformulare und Nachrichten.

1. Öffnen Sie als Super admin System → Plugins.
2. Wählen Sie Browse Plugin Catalog, suchen Sie WebBlocks Support und prüfen Sie Version, Kompatibilität und Versionshinweise.
3. Installieren Sie mit Install from Catalog, öffnen Sie danach die Plugindetails und wählen Sie Enable Plugin.
4. Wenn Ihr Administrator stattdessen das vertrauenswürdige veröffentlichte ZIP bereitstellt, wählen Sie es unter Plugin ZIP, klicken Sie auf Upload Plugin ZIP, prüfen Sie die Details und aktivieren Sie das Plugin.

Unser Beispiel nutzt das veröffentlichte ZIP. Die erste Ansicht zeigt Support installiert, aber noch deaktiviert, neben dem Formular zur manuellen Installation.

Die aktuelle CMS-Installation und Aktivierung wenden die Datenbankänderungen des Plugins an. Prüfen Sie vor der Nutzung Migrations- und Einrichtungshinweise. Umgehen Sie eine fehlgeschlagene Installation nicht durch Änderungen an Datenbankzeilen. Die Details sollten die erwartete Version, den Zustand Enabled und einsatzbereiten Speicher sowie Oberfläche anzeigen.

Der Pluginzustand prüft die lokale Einrichtung. Er belegt weder die Erreichbarkeit des externen Anbieters noch dessen Freigabe Ihrer Installation. Öffnen Sie zum Fortfahren den neuen Navigationseintrag Support.

Support bietet zwei Pluginberechtigungen:

Geben Sie dem Verbindungsverwalter neben der Verwaltungsberechtigung auch Zugriff auf Support. Die Supportansicht selbst benötigt die Zugriffsberechtigung. Lesen Sie vor Rollenänderungen Rollen und Berechtigungen.

Ein normaler Melder benötigt keine Berechtigung zum Anbieterwechsel. Ohne Verbindungsverwaltung sieht er keine Verbindungseinstellungen. Ist die Installation nicht verbunden, wird angezeigt, dass Supportanfragen nicht verfügbar sind.

Die Ticketliste gehört dem angemeldeten CMS-Benutzer. Support grenzt Anfragen nach Installation und Melder ab; es gibt keine gemeinsame Warteschlange aller Benutzer. Auch Super admin macht die Liste nicht zum Agentenposteingang des Anbieters. Ein anderes CMS-Konto kann fremde Tickets nicht allein durch Kenntnis ihrer Adresse im Plugin öffnen.

Öffnen Sie Support mit einem Konto, das beide Berechtigungen besitzt. Vor der Aktivierung enthält die Karte Support connection zwei Felder:

• Support provider address: die HTTPS-Adresse Ihres kompatiblen Anbieters.
• Support invitation code: die einmalige Einladung für diese Installation.

Geben Sie die tatsächliche Anbieteradresse ein, fügen Sie den Einladungscode ein und wählen Sie Connect support. Die Adresse muss per HTTPS auf einen öffentlichen Endpunkt auflösen. Localhost, private oder reservierte Netzwerkziele, eingebettete Zugangsdaten und ungeeignete URL-Bestandteile werden abgewiesen. Fügen Sie kein Administratorpasswort und keinen API-Token in das Einladungsfeld ein.

Das Absenden startet Discovery und Aktivierung. Der Anbieter erhält Installationskennung und Kontext, darunter CMS-Version, Website-URL und Umgebung. Das bloße Öffnen des Formulars sendet keine Aktivierungsanfrage. Verwenden Sie nur den Anbieter, mit dem Sie diese Installation verbinden möchten.

Einladungs- und Aktivierungscodes sind Verbindungsinformationen. Halten Sie sie aus Screenshots und geteilten Fehlernotizen heraus. Die Felder im Bild oben bleiben bewusst leer.

Nach einer gültigen Aktivierungsanfrage zeigt Support eine ausstehende Verbindung und verlangt die Freigabe des Anbieters. Außerdem stehen Check activation und Disconnect bereit. Der Anbieterbetreiber erteilt die Freigabe; Check activation fragt das aktuelle Ergebnis ab. Ein ausstehendes Ergebnis bedeutet keine fehlgeschlagene Plugininstallation.

1. Falls eine Freigabe nötig ist, kontaktieren Sie den Anbieter über den vereinbarten Onboardingprozess.
2. Kehren Sie zur Supportansicht im CMS zurück.
3. Wählen Sie nach der Freigabe Check activation.
4. Prüfen Sie Erfolgsmeldung und Verbindungsstatus active.
5. Prüfen Sie Anbietername und einen eventuell zurückgegebenen Supportplannamen.

Im Beispiel liefert der Anbieter Northstar Demo Support und Studio Support. Diese Namen sind fiktiv und kein mitgelieferter Tarif. Bei aktiver Verbindung wird New request verfügbar. Eine leere Ticketliste ist jetzt normal.

Eine Aktivierung kann ablaufen oder abgelehnt werden. Fragen Sie den Anbieter, ob die Einladung noch gültig, die Freigabe abgeschlossen oder eine neue Einladung nötig ist. Die Ansicht kann bei einer unbrauchbaren Verbindung weiterhin eine Trennaktion anbieten. Klären Sie den Anbieterstatus, bevor Sie trennen und neu beginnen; eine verbrauchte Einladung wiederholt abzusenden ist keine Wiederherstellungsstrategie.

Wählen Sie New request. Das Formular enthält Type, Subject und Details.

Wählen Sie den Typ passend zur Anfrage. Er ist keine Prioritätsauswahl, Antwortzeitgarantie oder automatische Beauftragung bezahlter Arbeit. Der Anbieter bestimmt die Bearbeitung.

Verwenden Sie pro Ticket einen klaren Betreff. Ein nützlicher Betreff beschreibt Aktion und Symptom, etwa Die Entwurfsvorschau zeigt den vorherigen Seitentitel. Ein Titel wie „Hilfe“ erschwert die spätere Zuordnung.

Beschreiben Sie unter Details Ihre Schritte, das erwartete Ergebnis und das tatsächliche Verhalten. Für das fiktive Northstar-Problem geben wir Folgendes ein:

Dies ist ein Beispielbericht und keine Behauptung, dass das veröffentlichte CMS diesen Fehler hat. Tragen Sie Ihre tatsächliche Beobachtung ein: betroffene Seite oder Funktion, ungefähre Zeit, Wiederholbarkeit und Auswirkungen auf veröffentlichte Inhalte. Nennen Sie bei Bedarf Website und Sprache; Support verwendet eine Installationsverbindung statt einer Websiteauswahl.

Der Betreff erlaubt bis zu 255 Zeichen. Anfangsdetails und jede Antwort erlauben bis zu 20,000 Zeichen. Das gezeigte Formular hat keinen Anhang-Upload. Beschreiben Sie ein relevantes Bild im Text oder verwenden Sie einen ausdrücklich vereinbarten separaten Übertragungsweg. Fügen Sie keine Geheimnisse, personenbezogenen Datensätze, vollständigen Logs oder rohe Konfigurationen ein.

Prüfen Sie den Text und wählen Sie einmal Send request. Die Anfrage enthält Ihren CMS-Anzeigenamen, eine installationsgebundene Melderreferenz und Installationskontext. Die Referenz trennt Ihre Liste von anderen Benutzern und Installationen.

Nach erfolgreichem Absenden öffnet sich das Ticket mit Your request has been sent. Die Überschrift enthält Nummer und Betreff. Die ursprünglichen Details stehen in Conversation unter You und Reporter.

Unser Beispiel trägt #1001 und zeigt zunächst Waiting for support. Bewahren Sie die Nummer für Gespräche über dasselbe Problem auf. Mit Back to requests gelangen Sie zur Liste; über den Betreff öffnen Sie das Gespräch erneut.

Bei einem Sendefehler kehrt das Plugin mit erhaltenem Text und Dienstfehler zum Formular zurück. Prüfen Sie nach einem unklaren Verbindungsfehler vor dem erneuten Senden Ihre Liste. Die Anfrage könnte angekommen sein, obwohl die abschließende Antwort den Browser nicht erreicht hat. Vermeiden Sie mehrere Tickets zum selben Problem.

Die Ansicht bestätigt die Ticketerstellung beim Anbieter. Sie bestätigt weder das Lesen durch einen Agenten noch E-Mail-Zustellung oder eine vereinbarte Antwortfrist.

Öffnen Sie das Ticket erneut, um Aktualisierungen zu sehen. Im Beispiel ergänzt der simulierte Anbieter eine Rückfrage und setzt Waiting for your reply. Das Gespräch unterscheidet den ursprünglichen Melder von einer Nachricht des Support team und zeigt Zeitangaben.

Lesen Sie die Frage vor der Antwort. Wenn Support einen bestimmten Test verlangt, beschreiben Sie Ergebnis und verbleibende Abweichungen. Bleiben Sie im selben Ticket, damit der Kontext erhalten bleibt.

1. Suchen Sie unter dem Gespräch Add a reply.
2. Tragen Sie das Ergebnis der angeforderten Prüfung ein.
3. Prüfen Sie den Text auf vertrauliche Informationen.
4. Wählen Sie Send reply.
5. Prüfen Sie Your reply has been added. und das Erscheinen Ihrer Nachricht im Gespräch.

Eine Nachricht im Gespräch ist keine eigene Änderung des Ticketstatus. Den Ablauf steuert der Anbieter. Hier versetzt unsere Antwort die Anfrage wieder in einen auf Support wartenden Zustand; andere kompatible Anbieter können den Übergang anders behandeln.

Verlassen Sie sich nicht auf E-Mail oder Browsermeldungen, um Antworten zu bemerken. Der gezeigte Pluginablauf ist das erneute Öffnen von Liste oder Ticket. Zusätzliche Benachrichtigungen hängen vom Anbieter und seiner Integration ab.

Ein Anbieter kann für ein Ticket eine begrenzte Diagnoseaufnahme anfordern. Die Anfrage erscheint über Conversation unter Diagnostic access requested. Das bloße Anzeigen dieser Karte sammelt oder sendet keine Aufnahme.

Lesen Sie die auf der Karte genannten Kategorien genau. Das Plugin erkennt drei Kategorien:

Der Fehlercollector liest einen begrenzten Endabschnitt des Standardlogs und wählt passende Fehlerzeilen aus; er lädt nicht das ganze Log hoch. Die Grenzen sind 64 KiB am Dateiende, höchstens 40 passende Zeilen und 2,000 Zeichen pro ausgewählter Zeile. Maskiert werden typische Zugangsdatenmarker, Bearer-Werte und E-Mail-Adressen. Diese Filterung rechtfertigt keine beliebigen vertraulichen Daten in Logs oder Tickettexten.

Eine Diagnoseanforderung ist kein Fernzugriff. Der Collector bietet weder freie Dateiauswahl noch Upload von Umgebungsdateien, Shellbefehle oder vom Anbieter gesteuerte Codeausführung. Text- und Antwortfelder sind davon getrennt: Sie senden dort die von Ihnen eingegebenen Inhalte.

Sind die Kategorien angemessen und erlaubt Ihre Organisation die Weitergabe an diesen Anbieter, wählen Sie Approve and share. Das Plugin sammelt die erkannten Kategorien und übermittelt die Aufnahme für diese konkrete Anforderung.

Prüfen Sie The approved diagnostic snapshot was shared with support. Der Anbieter muss die Daten weiterhin auswerten. Die Erfolgsmeldung bedeutet keine Behebung des eigentlichen Problems.

Unser Beispiel genehmigt Systemversionen und Umgebung sowie installierte Pluginversionen und Aktivierungszustand. Aktuelle Anwendungsfehler werden hierbei nicht genehmigt. Die Freigabe gilt für die angezeigte Anforderung, nicht pauschal für künftige Anforderungen oder dauerhafte Überwachung. Lesen Sie jede neue Anforderung einzeln.

Die Freigabekarte zeigt Kategorien statt einer bearbeitbaren zeilenweisen Vorschau. Schließen Sie einen eventuell erforderlichen separaten Prüf- oder Freigabeprozess ab, bevor Sie Approve and share wählen.

Alternativ wählen Sie Decline. Im zweiten Beispiel verlangt der Anbieter aktuelle Anwendungsfehler. Wir lehnen diese Anforderung ab.

Prüfen Sie danach die Meldung The diagnostic request was declined. Die Ablehnungsantwort enthält keine erhobene Aufnahme. Ihr bestehendes Ticketgespräch bleibt verfügbar.

Ergänzen Sie bei Bedarf eine Antwort, dass Sie stattdessen Reproduktionsschritte oder andere freigegebene Informationen liefern können. Eine Diagnose abzulehnen ist etwas anderes, als das Ticket abzulehnen oder zu schließen. Der Anbieter entscheidet anhand der verfügbaren Informationen über das weitere Vorgehen.

Bei einem Dienstfehler nach Freigabe oder Ablehnung dürfen Sie den Empfang der Entscheidung nicht voraussetzen. Öffnen Sie das Ticket erneut, prüfen Sie den Zustand und kontaktieren Sie bei Unklarheit den Anbieter.

Wählen Sie Back to requests. Die Liste zeigt Nummer, Betreff, Typ, Status und Sendezeit. Unser Beispiel enthält ein geschlossenes Problem, eine Frage in Prüfung sowie einen angenommenen und einen abgelehnten Vorschlag.

Die Standardbezeichnungen der Liste sind:

Die Detailseite zeigt Waiting for support bei neuen und geprüften Anfragen und Waiting for your reply, wenn der Anbieter auf den Melder wartet. Anbieter können weitere Statuswerte liefern; fehlt eine Bezeichnung, zeigt das Plugin den Wert möglicherweise direkt. Statusformulierungen sind weder SLA noch Lieferzusage.

In unserem fiktiven Beispiel erscheint nach erneutem Öffnen von Preview der gespeicherte Titel. Wir teilen das Ergebnis mit; der simulierte Anbieter ergänzt eine Abschlussnachricht und setzt Closed.

Der gezeigte Client bietet dem Melder keine Statusauswahl und keine Schaltflächen zum Schließen oder Wiederöffnen. Bei einem geschlossenen Ticket kann ein Antwortfeld sichtbar bleiben; ob eine Antwort akzeptiert wird oder Arbeit wieder öffnet, entscheidet der Anbieter. Befolgen Sie dessen Hinweise, statt eine Statusänderung durch das bloße Antworten anzunehmen.

Die Supportverbindung kann active bleiben, während ein Netzwerk- oder Anbieterausfall die Ticketliste blockiert. Dann erscheint The support service could not be reached. Please try again in a moment.

Eine nicht verfügbare Liste beweist keine Löschung der Tickets. Warten Sie kurz, aktualisieren Sie und prüfen Sie erneut. Sichern Sie eine ungesendete Antwort vor dem Verlassen außerhalb des Browsers an einem angemessen geschützten Ort. Melden Sie Aktion und Zeitpunkt des Fehlers ohne Zugangsdaten oder vollständigen Logdump.

Auch ein direkter Ticketaufruf kann bei unerreichbarem Anbieter scheitern. Prüfen Sie Verfügbarkeit, Supportanspruch der Installation und den konfigurierten Ursprung. Eine Trennung repariert keinen vorübergehenden Ausfall und kann eine neue Einladung und Freigabe nötig machen.

Nur der Verbindungsverwalter sieht Disconnect. Ein Klick öffnet eine Bestätigung, dass die Installation bis zur erneuten Aktivierung den Ticketzugriff verliert.

Schließen Sie den Dialog, wenn Sie ihn nur prüfen. Wollen Sie die Verbindung entfernen, bestätigen Sie im Dialog Disconnect. Bei einer aktiven Verbindung fordert das Plugin den Anbieter zum Widerruf auf und entfernt danach den lokalen Verbindungsdatensatz. Scheitert der Widerruf, klären Sie den Anbieterfehler, statt die Trennung als abgeschlossen anzusehen.

Die Trennung löscht keine Tickets und ist kein Befehl zur Datenlöschung beim Anbieter. Sie entfernt diese CMS-Verbindung; Aufbewahrung und spätere Wiederherstellung regelt der Anbieter. Prüfen Sie laufende Arbeiten und den Umgang mit der Historie vor einem Anbieterwechsel oder Installationsumzug.

Trennen Sie für einen anderen Anbieter zuerst die alte Verbindung vollständig, beschaffen Sie Adresse und Einladung des neuen Anbieters und wiederholen Sie die Aktivierung. Gehen Sie nicht davon aus, dass alte Gespräche übernommen werden.

Prüfen Sie vor der Freigabe für CMS-Benutzer: veröffentlichtes Plugin aktiviert, Anbieter aktiv und Zielrolle zum Öffnen eigener Anfragen berechtigt. Erstellen Sie ein kontrolliertes Testticket, prüfen Sie die Liste des Melders und lassen Sie den Anbieter antworten. Senden Sie eine Rückmeldung aus dem CMS und bestätigen Sie deren Empfang.

Unterstützt der Anbieter Diagnosen, testen Sie die Einwilligung mit freigegebenen Testdaten einschließlich Teilen und Ablehnen. Vereinbaren Sie Verfügbarkeit, Benachrichtigungen, Antwortzeiten und zulässige Informationen separat. Diese Punkte regelt die Anbieterbeziehung; das Plugin garantiert sie nicht.

Damit haben Sie einen wiederholbaren Weg vom CMS-Problem zum Supportgespräch: klare Meldung, sichtbare Ticketnummer, Antwort im Kontext und bewusste Diagnoseentscheidung. Lesen Sie Rollen und Berechtigungen zur Delegation oder das Support-Protokoll zur Implementierung eines kompatiblen Anbieters.