Man kann innerhalb eines einzigen Document360-Projekts mehr als ein Knowledge Base-Widget erstellen. Ein häufiger Anwendungsfall ist die Pflege eines separaten Test-Widgets neben einem Live-Produktions-Widget, sodass Sie sicher mit Konfigurationsänderungen experimentieren können, ohne die Leser zu beeinträchtigen.
Wann man mehrere Widgets verwenden sollte
- Du brauchst ein Staging-Widget, um Styling, URL-Mapping oder Änderungen am Inhaltszugriff zu testen, bevor du sie in der Produktion anwendest.
- Du bedienst verschiedene Zielgruppen (verschiedene Produkte, Regionen oder Zugriffsstufen) und möchtest für jede einzelne Widget-Konfiguration.
Einstellungen, die pro Widget isoliert bleiben
Jedes Widget hat seine eigene unabhängige Konfiguration für:
- Widget-Name
- Aussehen (Farbe, Symbol, Position, Willkommensnachricht, Widget ausblenden, die meisten gesuchten Artikel ausblenden)
- Inhaltszugang (Arbeitsbereich, Sprache, Kategoriensichtbarkeit)
- Benutzerdefinierte Links
- Domänenbeschränkung
Änderungen an einer der oben genannten Einstellungen eines Widgets beeinflussen kein anderes Widget im Projekt.
Einstellungen, die über Widgets geteilt werden
Wenn die JWT-Authentifizierung aktiviert ist, wird das Client-Geheimnis über alle JWT-fähigen Widgets und Chatbots im selben Projekt geteilt, unabhängig davon, von welchem Widget man es neu generiert.
Das Regenerieren des Client-Geheimnisses auf einem Widget – einschließlich eines Test-Widgets – unterbricht sofort die Authentifizierung bei allen anderen JWT-fähigen Widgets im Projekt, bis alle Backend-Integrationen mit dem neuen Geheimnis aktualisiert sind.
Wenn du ein Test-Widget verwendest, um JWT-bezogene Änderungen auszuprobieren, vermeide es, das Client-Secret neu zu generieren , es sei denn, du bist bereit, alle Backend-Integrationen gleichzeitig zu aktualisieren.
Für vollständige Details zur JWT-Einrichtung siehe JWT konfigurieren für das Knowledge Base-Widget.
Best Practices
- Verwenden Sie eine klare Benennungskonvention, um Test- und Produktionswidgets zu unterscheiden (z. B. "Widget — Produktion", "Widget — Test").
- Verwenden Sie die Domain-Einschränkung auf dem Produktions-Widget, um sicherzustellen, dass es nur auf Ihrer Live-Domain geladen wird, während das Test-Widget auf eine Staging-Domain beschränkt werden kann.
Testen Sie ohne Aktivierung von JWT für zusätzliche Isolierung
Wenn du ein neues Widget testest und sicherstellen möchtest, dass deine Produktions-Widgets und Backend-Integrationen völlig unbeeinflusst bleiben, kannst du das neue Widget konfigurieren und testen, ohne JWT zu aktivieren. Dieser Ansatz bietet eine zusätzliche Isolationsschicht jenseits von Namenskonventionen und Domänenbeschränkungen. Wenn JWT im Test-Widget nicht aktiviert ist, besteht kein Risiko, das gemeinsame Clientgeheimnis versehentlich neu zu generieren und die Produktionsauthentifizierung zu stören. Sobald das Testen abgeschlossen ist und du bereit bist, aktiviere JWT im Widget und aktualisiere deine Backend-Integration mit dem gemeinsamen Client-Geheimnis.
FAQ
Ich habe Änderungen an meinem Test-Widget vorgenommen und mein Live-Widget ist kaputt gegangen. Warum?
Die meisten Widget-Einstellungen (Aussehen, Inhaltszugriff, Links, Domainbeschränkung) sind pro Widget isoliert und beeinflussen andere Widgets nicht. Die einzige Ausnahme ist das JWT-Clientgeheimnis, das über alle JWT-fähigen Widgets und Chatbots im Projekt geteilt wird. Wenn das Client-Geheimnis auf deinem Test-Widget neu generiert wurde, wird auch die Authentifizierung auf deinem Live-Widget ungültig, bis das neue Geheimnis in der Backend-Integration aktualisiert wird.
Das Knowledge Base-Widget lädt nicht auf der Knowledge Base-Website. Wie kann ich das beheben?
Das Widget lädt möglicherweise nicht, wenn der API-Schlüssel im eingebetteten Skript veraltet ist. Kopiere das aktuelle Skript aus dem Connections > Knowledge Base-Widget > kopiere das Skript und ersetze das veraltete Skript auf deiner Website.