Wenn ein dringendes Support-Ticket reinkommt, möchte man am liebsten sofort loslegen und das Problem so schnell wie möglich beheben. Auf einer aktiven WordPress-Website kann diese Art von Geschwindigkeit jedoch nach hinten losgehen.
Ein fehlgeschlagenes Plugin-Update, eine schnelle Konfigurationsänderung oder ein überstürzter Eingriff in die Datenbank – und schon ist eine Website nicht mehr nur leicht beschädigt, sondern komplett offline. Ohne ein aktuelles Backup gibt es keinen sauberen Weg zurück.
In diesem Leitfaden erfährst du, wie du diesen Schritt automatisieren kannst. Durch die Verbindung von Zendesk mit der Kinsta-API kann jedes dringende WordPress-Ticket automatisch ein Backup auslösen, noch bevor ein Techniker es öffnet. Das Ergebnis ist ein sicherer, konsistenter Prozess zur Reaktion auf Vorfälle mit einem bereits vorhandenen Wiederherstellungspunkt.
Warum Agenturen Backups erstellen sollten, bevor sie etwas reparieren
Ein Plugin-Konflikt, eine fehlgeschlagene Datenbankabfrage oder ein unvollständiges Update auf einer aktiven WordPress-Website ohne Backup lässt sich nur schwer wiederherstellen. Jede Änderung, die du vor der Erstellung eines Backups vornimmst, bedeutet, dass es keinen sauberen Rückkehrpunkt gibt, wenn etwas schief geht.
Wenn du mehrere Kunden-Websites verwaltest, musst du dich darauf verlassen, dass derjenige, der das Ticket abholt, ein Backup erstellt, bevor er anfängt. Die Abhängigkeit von diesem manuellen Schritt ist der Punkt, an dem die Dinge zusammenbrechen.
Für Pixeled Eggs steht viel auf dem Spiel, denn die Kunden von Pixeled Eggs helfen Menschen in Krisen. Jemand, der psychosoziale Unterstützung oder Notfallhilfe sucht, erwartet, dass die Website geladen wird. Ein fehlgeschlagener Wiederherstellungsversuch ist daher eine Katastrophe.
Die mühelose Lösung und die Zeit, die wir in unserem Entwicklungsteam eingespart haben, haben sich für uns gelohnt. Das bedeutet, dass wir uns auf das konzentrieren können, was wir am besten können: das Entwerfen und Entwickeln von leistungsstarken WordPress-Websites für zielgerichtete Kunden.
Was du brauchst, bevor du anfängst
Für dieses Tutorial brauchst du:
- Ein Kinsta-Konto mit mindestens einer WordPress-Website in einer Live-Umgebung.
- Ein Zendesk-Konto mit einem Suite Team Plan oder höher (oder einem Support Team, Professional oder Enterprise Plan). Webhooks und Trigger sind für alle diese Stufen verfügbar.
- Administratorenzugang in Zendesk, um Webhooks und Triggers zu erstellen.
- Node.js muss lokal installiert sein.
Um dich mit der Kinsta-API zu authentifizieren, gehe in MyKinsta zu [Unternehmensname] > Unternehmenseinstellungen > API-Schlüssel und klicke auf API-Schlüssel generieren.
Hier gibst du dem Schlüssel einen Namen, legst eine Gültigkeitsdauer fest und klickst auf Generieren. Der Schlüssel wird hier nur einmal angezeigt, also kopiere ihn, bevor du das Fenster schließt. Du brauchst auch eine Site-ID. Diese erscheint in der MyKinsta-URL, wenn du eine Seite öffnest, oder du kannst GET /sites abrufen, sobald du deinen Schlüssel erstellt hast.
In jedem Fall fügst du den API-Schlüssel in eine .env-Datei im Stammverzeichnis deines Projekts ein:
KINSTA_API_KEY=your_api_key_hereBeachte, dass die Site-ID und die Environment-ID zwei verschiedene Dinge sind: Der Agent gibt die Site-ID ein, und die Middleware ruft GET /sites/{siteId}/environments auf, um die Environment-ID zu holen. Außerdem entspricht die Zugriffsstufe eines API-Schlüssels der Rolle, die ihn erstellt hat: Entwicklerschlüssel haben engere Berechtigungen als die von Betreibern oder Administratoren. Wenn eine Anfrage einen Berechtigungsfehler zurückgibt, ist dies der erste Punkt, den es zu überprüfen gilt.
Weitere Entwicklungsvoraussetzungen
Für die lokale Entwicklung läuft die Middleware auf localhost, den Zendesk nicht direkt erreichen kann. Wenn du ein Tunneling-Tool wie ngrok verwendest, wird ein lokaler Port mit einer temporären öffentlichen URL für das Internet freigegeben, die du während der Entwicklung als Webhook-Endpunkt verwenden kannst. Sobald die Integration lokal durchgängig funktioniert, ersetzt du diese URL durch die Adresse der eingesetzten Middleware.
Außerdem brauchst du ein benutzerdefiniertes Ticketfeld in Zendesk, um die Kinsta-Site-ID aus einem Ticket in die Webhook-Nutzdaten zu übertragen. Navigiere im Zendesk-Optionsmenü auf der rechten Seite des Bildschirms zu Objekte und Regeln > Tickets > Felder und erstelle ein neues Textfeld.
Als Nächstes gibst du ihm einen erkennbaren Namen und notierst die numerische Feld-ID, die Zendesk ihm zuweist. Wenn ein Agent ein Ticket für einen WordPress-Vorfall öffnet, füllt er dieses Feld mit der Site-ID der betroffenen Website.
So integrierst du Zendesk mit Kinsta über die Kinsta-API
Die Node.js-Middleware empfängt Zendesk-Webhook-Aufrufe, um eine Datensicherung nach Erhalt eines relevanten Support-Tickets zu initiieren. Von dort aus löst sie eine Kinsta-Site-ID in eine Umgebungs-ID auf und löst dann ein gekennzeichnetes manuelles Backup aus.
Die Zendesk-Seite besteht aus zwei Objekten: einem Webhook, der auf den Endpunkt der Middleware verweist, und einem Trigger, der ausgelöst wird, wenn ein passendes Ticket eingeht.
1. Erstelle den Zendesk-Webhook
In Zendesk sind ein Webhook und ein Trigger zwei getrennte Objekte. Du erstellst zuerst den Webhook und verbindest ihn dann mit dem Trigger als Aktion, nicht umgekehrt. Du kannst die Verbindungsmethode eines Webhooks nach der Erstellung auch nicht mehr ändern, also ist die Reihenfolge wichtig.
Um den Webhook zu erstellen, öffnest du die Zendesk-Optionen und navigierst zu Apps und Integrationen > Webhooks > Webhooks und klickst dann auf Webhook erstellen.
Wähle für die Verbindungsmethode Trigger oder Automatisierung. Klicke auf Weiter und gib dann einen Namen ein. Für die Endpunkt-URL gibst du vorerst einen Platzhalter ein, denn du aktualisierst sie, sobald die Middleware implementiert ist. Du musst /backup an diese URL anhängen, die Anfragemethode auf POST und das Anfrageformat auf JSON setzen.
Als Authentifizierungsmethode bietet sich Bearer Token an, da du bei der Konfiguration der Middleware eine Überprüfung der eingehenden Anfrage einbaust. Zendesk enthält außerdem einen Signatur-Header (x-zendesk-webhook-signature), den du zur Überprüfung von Anfragen verwenden kannst. Sobald du den Webhook erstellt hast, listet Zendesk ihn im Webhook-Bedienfeld auf, bis du ihn mit einem Trigger verbindest.
2. Einrichten des Zendesk-Triggers
Wenn der Webhook eingerichtet ist, navigiere zu Objekte und Regeln > Geschäftsregeln > Auslöser und klicke auf Auslöser erstellen.
Benenne den Trigger und lege im Abschnitt Bedingungen fest, dass er ausgelöst wird, sobald ein Ticket erstellt wird, die Priorität auf „Dringend“ steht, das benutzerdefinierte Feld vorhanden ist und die Tags wordpress-emergency enthalten. Diese Kombination bedeutet, dass der Trigger nur bei neuen Tickets ausgelöst wird, die ein Supportmitarbeiter ausdrücklich als aktiven WordPress-Vorfall markiert hat.
Als Nächstes klickst du auf Aktionen > Aktion hinzufügen, wählst Benachrichtigen durch > Aktiver Webhook und wählst deinen Webhook aus. Daraufhin öffnet sich der Editor für die Nutzdaten der Anfrage, in dem du festlegst, was Zendesk an deine Middleware sendet. Der Payload ist standardmäßig JSON, und Zendesk unterstützt eine Platzhalter-Syntax, um Ticketdaten einzubinden, wenn der Webhook ausgelöst wird.
Das Format für benutzerdefinierte Felder ist {{ticket.custom_fields.FIELD_ID}}, wobei FIELD_ID die numerische ID des benutzerdefinierten Feldes ist, das du in den Voraussetzungen erstellt hast:
{
"ticket_id": "{{ticket.id}}",
"site_id": "{{ticket.custom_fields.12345678}}" // Replace the numeric placeholder with the Zendesk field ID value.
}Wenn du dies definierst, übergibt Zendesk die Kinsta-Site-ID automatisch vom Ticket an die Middleware.
3. Erstelle den Middleware-Endpunkt
Die Middleware sorgt dafür, dass Zendesk und die Kinsta-API miteinander kommunizieren können. Express.js ist ein minimales Node.js-Webframework, das für das Routing zuständig ist, die Anfragen parst und mit dem du den POST-/Backup-Endpunkt definieren kannst, den Zendesk aufruft. Sobald du ein neues Projektverzeichnis erstellst, installierst du beide Abhängigkeiten:
npm init -y
npm install express dotenvHier stellt express die Server- und Routing-Schicht bereit; dotenv lädt deine .env-Datei, damit dein API-Schlüssel zur Laufzeit verfügbar ist, ohne in deinem Quellcode zu erscheinen.
Das Erstellen einer app.js-Datei bedeutet, dass der Server Express startet, das eingehende JSON analysiert und eine POST /backup-Route definiert, die die Zendesk-Nutzdaten empfängt:
// app.js
const express = require('express');
require('dotenv').config();
const app = express();
app.use(express.json());
const KinstaAPIUrl = 'https://api.kinsta.com/v2';
const headers = {
'Content-Type': 'application/json',
Authorization: `Bearer ${process.env.KINSTA_API_KEY}`
};
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'Missing site ID' });
}
// Kinsta API calls placeholder
res.status(200).json({ message: 'Received' });
});
app.listen(3000, () => console.log('Server running on port 3000'));Für den produktiven Einsatz musst du außerdem sicherstellen, dass die Anfrage von Zendesk stammt. Bei jedem Aufruf werden die Header x-zendesk-webhook-signature und x-zendesk-webhook-signature-timestamp mitgeschickt, mit denen du die Payload mit deinem Webhook abgleichen kannst.
4. Authentifizierung mit der Kinsta-API
Alle Anfragen an die Kinsta-API verwenden die Bearer-Token-Authentifizierung: Der Authorization-Header enthält deinen API-Schlüssel, und die in app.js definierte Header-Konstante verwaltet ihn für jede Anfrage in der Anwendung.
Die require('dotenv').config()-Zeile am Anfang der Datei lädt .env, bevor irgendetwas anderes ausgeführt wird, sodass process.env.KINSTA_API_KEY zur Laufzeit in deinen tatsächlichen Schlüssel aufgelöst wird. Der Schlüssel erscheint nie im Quellcode.
Als Nächstes benötigt die Middleware die Umgebungs-ID für die Website, was den Kinsta-Backup-Endpunkt betrifft. Dazu fügst du eine Funktion unterhalb der Header-Konstante hinzu:
const getEnvironmentId = async (siteId) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/${siteId}/environments`,
{ method: 'GET', headers }
);
const data = await resp.json();
return data.site.environments[0].id;
};Diese Funktion ruft GET /sites/{siteId}/environments auf und gibt die ID der ersten Umgebung in der Antwort zurück, die der Live-Umgebung entspricht. Wenn deine Websites mehrere Umgebungen verwenden und du eine bestimmte Umgebung finden musst, kannst du den Umgebungsnamen abgleichen, anstatt das erste Ergebnis zu nehmen.
5. Auslösen des Backups über die Kinsta-API
Um das Backup zu erstellen, ruft die Middleware POST /sites/environments/{envId}/manual-backups auf und verwendet eine weitere Zusatzfunktion unterhalb von getEnvironmentId:
const triggerBackup = async (envId, tag) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/environments/${envId}/manual-backups`,
{
method: 'POST',
headers,
body: JSON.stringify({ tag })
}
);
const data = await resp.json();
return data;
};Der Tag-Parameter kennzeichnet das Backup, damit es in MyKinsta leicht zu identifizieren ist. Die Verwendung der Zendesk-Ticket-ID im Tag bedeutet, dass jeder, der sich die Backup-Liste ansieht, sie zu dem Vorfall zurückverfolgen kann, der sie ausgelöst hat.
Aktualisiere schließlich die POST /backup-Route, um beide Funktionen nacheinander aufzurufen:
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'Missing site ID' });
}
try {
const envId = await getEnvironmentId(site_id);
const tag = `pre-remediation-${ticket_id || 'manual'}`;
const result = await triggerBackup(envId, tag);
res.status(200).json(result);
} catch (err) {
console.error(err);
res.status(500).json({ message: 'Backup failed' });
}
});Eine erfolgreiche Anfrage an den Backup-Endpunkt liefert den Status 202 und einen Antwortkörper, der bestätigt, dass der Vorgang läuft:
{
"operation_id": "backups:add-manual-abc123",
"message": "Adding a manual backup to environment in progress.",
"status": 202
}Die Antwort 202 ist jedoch keine Bestätigung, dass das Backup abgeschlossen ist. Manuelle Backups sind asynchron, also rufst du den Endpunkt GET /operations/{operation_id} ab, bis der Status als abgeschlossen zurückkommt. Für die meisten Arbeitsabläufe reicht eine 202-Antwort aus, um ein Ticket zu eröffnen.
Sobald du node app.js ausführst und eine Testanfrage mit einer gültigen Site-ID und Ticket-ID im Body sendest, überprüfe, ob das Backup in MyKinsta mit dem richtigen Tag erscheint.
Kinsta kann dir helfen, die Websites deiner Kunden zu schützen, wenn etwas schief geht
Diese Integration bedeutet, dass dringende WordPress-Supporttickets in Zendesk sofort ein Backup auslösen. Die Middleware ruft die Kinsta-API auf, um einen getaggten Snapshot zu erstellen, noch bevor ein Techniker das Ticket öffnet.
Für die lokale Entwicklung übernimmt ngrok die Verbindung zwischen Zendesk und localhost. Sobald du bereit bist, die Middleware auf einen permanenten Endpunkt zu verlagern, ist Sevalla eine natürliche Lösung. Du verschiebst das Projekt zu einem Git-Provider, verbindest das Repo, fügst deine Umgebungsvariable in den Bereitstellungseinstellungen hinzu und aktualisierst die Webhook-Endpunkt-URL in Zendesk, damit sie auf die Live-Adresse zeigt.
Wenn du Kunden-Websites in großem Umfang verwaltest, passt das Add-on Automatische Updates von Kinsta perfekt zu diesem Workflow. Es hält Plugins und Themes auf dem neuesten Stand, führt nach jeder Aktualisierung automatische visuelle Tests durch und macht die Änderungen rückgängig, wenn etwas nicht funktioniert. Außerdem kannst du für jede Website einen eigenen Zeitplan einrichten.
Wenn du Fragen hast, kannst du dich jederzeit an das Support-Team wenden.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
