Ein eigenes Help-Center-Theme: der Teil von Zendesk, den du besitzt

Ein Unterschied zwischen dem Messaging-Widget und dem Help Center erklärt fast alles. Das Widget ist eine Blackbox: Du reichst über eine API Farben und ein paar Optionen hinein, der Code drin gehört Zendesk. Beim Help Center ist es umgekehrt. Du bekommst den Code selbst: Templates, CSS, JavaScript. Es ist der einzige Teil von Zendesk, den du besitzt.

Was ein Theme ist

Ein Guide-Theme ist kein Farbschema, sondern ein Paket. Darin: die Templates (home_page, category_page, article_page, requests_page …) als .hbs-Dateien, ein globales style.css, ein globales script.js, ein Ordner mit Assets, dazu eine manifest.json, die definiert, welche Knöpfe im Editor auftauchen.

Die Templates rendern server-seitig mit Curlybars, einer Handlebars-Teilmenge. Heisst: Die HTML-Struktur entsteht auf dem Server, bevor die Seite ankommt. Alles Dynamische, etwas nachladen oder auf die API zugreifen, läuft danach über dein script.js, das global auf allen HC-Seiten eingebunden ist. Diese Trennung muss man verstehen, sonst sucht man Fehler an der falschen Stelle.

Zwei Wege, es zu bauen

Im Browser: Customize design → Edit code öffnet den Theme-Editor direkt in Zendesk. Schnell für kleine Eingriffe. Voraussetzung ist Suite Growth oder höher (in den älteren Plänen: Guide/Knowledge Professional oder Enterprise). Suite Team hat keinen Code-Editor.

Lokal: Als Ausgangspunkt dient meist das quelloffene Standard-Theme Copenhagen statt der grünen Wiese. Es ist ein Node-Projekt: yarn install holt die Abhängigkeiten, yarn start kompiliert die Quellen aus src/ und styles/ zu den ausgelieferten style.css und script.js und öffnet eine lokale Vorschau. Die Falle dabei: Bearbeite die Quellen, nicht die generierten Dateien, sonst überschreibt der nächste Build deine Änderungen. Für die Vorschau an deiner Instanz meldest du dich mit yarn zcli login -i an. Hochgeladen wird per ZIP-Import oder über eine GitHub-Anbindung. So versionierst du das Theme in Git und hältst Änderungen nachvollziehbar, sobald mehr als eine Person mitbaut.

Einstellungen ohne Code

Der unterschätzte Teil ist die manifest.json. Was du dort als Setting deklarierst, kann später jemand im Editor ändern, ohne den Code anzufassen. Die Typen sind vorgegeben: text, list, checkbox, color, file und range. Zwei file-Variablen sind Pflicht, logo und favicon; fehlen sie, weist Zendesk das Theme beim Import ab. Gutes Theming heisst: Struktur in den Code, Konfiguration in die Settings. Wer jede Farbe hart verdrahtet, wird zur Engstelle für jede spätere Anpassung.

Der Preis: du besitzt auch die Wartung

Sobald du ein Standard-Theme im Code anfasst, wird es zum custom theme. Im Theme-Verwalter markiert ein </>-Icon diesen Zustand. Das hat eine Kehrseite: Zendesk-Feature-Updates am Standard-Theme spielen sich nicht mehr automatisch ein, und offiziellen Support fürs eigene Theme gibt es nicht. Eine Regel dazu: Fass das live geschaltete Theme nie direkt an. Arbeite an einer Kopie und schalte sie erst nach dem Test scharf. Für ein bisschen Umfärben lohnt sich das nicht. Für alles, was darüber hinausgeht, führt kein Weg daran vorbei.

Und dann wird es interessant

Das eigene Theme ist nicht das Ziel, sondern die Leinwand. Erst wenn du den Code besitzt, kannst du Custom Pages anlegen: eigene .hbs-Templates unter templates/custom_pages/, die Seiten ausserhalb der Standard-Struktur aus Home, Kategorie und Artikel erlauben. Dort entsteht eine «Meine Anfragen»-Seite, die den echten Stand zeigt, mit der eingeloggten Identität aus dem JWT-Login. Identität, Oberfläche, lebendige Daten: Das Theme ist das mittlere Stück, ohne das die anderen beiden nicht zusammenkommen.

Ein umgefärbtes Standard-Theme sieht nach dir aus. Ein eigenes Theme ist der einzige Ort, an dem du Zendesk nicht bedienst, sondern baust.