Documentation Index

Fetch the complete documentation index at: https://docs.document360.com/llms.txt

Use this file to discover all available pages before exploring further.

Haftungsausschluss: Dieser Artikel wurde durch maschinelle Übersetzung erstellt.

Verwendung mehrerer Widgets innerhalb eines Projekts

Prev Next

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
  • Styling (Farbe, Symbol, Position, Willkommensnachricht, Widget ausblenden, die meisten gesuchten Artikel ausblenden)
  • Inhaltszugang (Arbeitsbereich, Sprache, Kategoriensichtbarkeit)
  • Benutzerdefinierte Links
  • Domänenbeschränkung
HINWEIS

Ä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.

WARNUNG

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.

FAQ

Ich habe Änderungen an meinem Test-Widget vorgenommen und mein Live-Widget ist kaputt gegangen. Warum?

Die meisten Widget-Einstellungen (Styling, Inhaltszugriff, Links, Domain-Beschrä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.